Bug 146718 (IT_72202)

Relocation for ia32 on ia64 is by directory.

That means that any directory that contains an elf32
binary will be relocated.

There is currently no control of the mechanism, mostly
becuae the intent was to *not* have to teach each i386
package about other platforms, like ia64, where the
package might be installed.

Your case is rather different, because it involves
file system helpers, and your elf64 "kows" that an
elf32 helper is to be invoked.

A symlink from %post is an OK solution (imho), but isn't
a check and exec from /emul/ia32-linux/sbin/mkfs.vxfs
a possible alternative means to deal with the situation?

I'm not sure whether the "old behavior" makes any sense
when talking about mixed elf32/elf64 on same system
(and on the same path). rpm packaging never had to deal
with that case before.

So why can't the /emul/ia32-linux prefixed executable be tested for
and invoked if present?

Thanks very much for your detailed comments, Jeff.

In the case of the 32-bit mkfs.vxfs, the invoking program,
64-bit /sbin/mkfs, is not ours, so we don't control what it does.
But this is just one example.  

Our situation is that we have a certain set of binaries, mostly
commands, that are available on all CPU architectures.  On x86, they
are all 32-bit.  On x86_64 and ia64, some are 32-bit and some are
64-bit.  We want this distinction to be largely invisible, of course,
so we want the commands in the same place on all architectures.  We
have an x86-built "common" rpm with 32-bit binaries, which is loaded
on all architectures.  This rpm says where the binaries should go, and
the rpm command used to put them there, but now it doesn't.

We understand the reason for the autorelocation.  It enables
someone to have both 32-bit and 64-bit versions of the same binary,
and have a reasonable way to access either one.  It's a fine
default, but it doesn't address our situation.

Our current workaround -- symlinking back into the expected
places in the %post scriptlet -- has some disadvantages, principally
that we have to name the files twice, once to itemize them,
and once to symlink them.  It also requires us to write a spec
file with some undesirable knowledge about where the package might be
installed.

This is not a serious problem; we filed the bugzilla partly
to be sure we weren't missing some keyword or flag that
would get us the old behavior.  But if you're looking for rpm
suggestions, ours would be to have some spec file syntax that
turns off autorelocation, so the files go where the spec file
says.  We're guessing that others would find this useful as well.

Peripherally related . . . just make to make you aware that RHEL4 on IA64 has no
ability to execute 32-bit code until the ia32el package is installed and the
service started (which happens automatically as part of installation.)

Intresting thing is that it does not relocate the binaries created on 
Redhat Advanced Server 2.1-32 bit.( because _autorelocate_path macro 
is not defined )
Is there is any way to avoid autorelocation ?

We have discovered that "AutoReqProv: no" will turn off this
relocation.  Is this a reasonable way to disable it?
I'm guessing not, but thought I would ask anyway.

AutoReqProv: no would preventing rpm marking the provides of binaries, on ia64
this would put binaries in / however they will not be able to execute as later
ia64 do not natively run x86 instructions.

For something like mkfs where you are plugging into an existing framework of
extensions on itanium you should provide ia64 binaries.

RPM relocation for x86 on ia64 is working as designed due to the need to have an
emulation layer.