[Rpm-maint] Multiple ABI architectures (parallel installation, detection, handling)

[Panu Matilainen]

On 09/16/2011 05:31 PM, James Antill wrote:
> On Fri, 2011-09-16 at 12:02 +0300, Panu Matilainen wrote:
>> On 09/15/2011 01:55 PM, Jon Masters wrote:
>
>> 1) Location of libraries and the like: the libraries for different ABI's
>> need to go to separate paths. Currently the non-debian world knows /lib
>> and /lib64, and while it's of course possible to add /libx32 and
>> whatnot, that gets *extremely* ugly real soon and simply does not scale
>> to things like cross-toolchains. The debian multiarch spec seems rather
>> nice in this regard: "simply" stuff it all into separate libraries in
>> $(prefix)/lib/$(arch)-$(abi) style distinct paths, without
>> differentiating between "native" and other archs/abis.
>
>   Yeh, if everything used it it'd be a bit nicer, but good luck getting
> Fedora/RHEL to sign off on moving everything to the Debian model :).

I'm just hoping somebody else is going to step up to drive such a change 
if/when the time comes ;)

But if x32 (or anything similar) is to be introduced to the mix... 
AFAICT x32 is just a userland ABI that runs as a personality of regular 
x86_64 kernel, so it supports x86_64 binaries and "legacy" ix86/ia32 
binaries also. Which means the x32 libraries need to go to some other 
path than /lib or /lib64, so the choices come down to either a big 
overhaul or living with some /libx32 style creature.

>
>> For manually added dependencies %{_isa} goes a long way, but probably
>> not sufficient in its current form for a full-scale multiarch, multiabi
>> system.
>
>   I'd assume that's a simple fix though, no? At least compared with all
> the other stuff that needs to be done :).

Indeed :)

>> 3) Package naming&  resolution: when in "multilib" mode (in rpm jargon,
>> "colored transaction"), packages with identical name but different
>> architecture can co-exist relatively peacefully. However the use of
>> "arch" alone is limiting from multiabi perspective, it'd require every
>> single different arch/abi combination to have arch of their own. Other
>> possibility is differentiating in the package name, but its klunky too.
>> I didn't (yet) see what debian is planning wrt this.
>
>   Why would you want i686 and x32 to have arch as "i686" ... that just
> seems insane.
>   Also the embed the arch in the package name thing seems like a pretty
> big hack for x86_64 adding some 32bit packages (rpms need to be built
> twice, pkg. management needs to "know" about the special naming rules
> etc.) ... for i686 vs. x32 it seems much worse (AIUI, you'll have pretty
> much 100% x32 packages and no multilib).

Heh. I'm not quite sure what my point was with the above rambling, other 
than "arch as we know it might have to cease to exist", or at least 
pushed down to a "legacy compatibility" item by whatever it is replaced 
with. As it is now, arch in rpm is a rather fuzzy and overloaded term. 
But I dunno...

>
>>> Thanks for your time. I'm attaching Dennis' original patch. Just so you
>>> can see what it does, not so that you can directly consider that as the
>>> solution that will be necessarily eventually in upstream if you can
>>> figure out a preferred means to generically handle multiABI.
>>
>> FWIW, I'm going to have a stab at converting the existing arch-detection
>> (on linux) to use the auxiliary vector AT_* data. If that goes in, doing
>> the same for ARM should be a no-brainer (and well, can be of course be
>> done regardless of what other archs do)
>
>   If we are going to change a bunch of the arch handling for this, it
> might be worth trying to merge the rpm/yum needs ... so we can just call
> into rpm for what we need, instead of duplicating 75% of the problem.

Absolutely. The current situation is just plain ridiculous :)

	- Panu -