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 -
_______________________________________________
Rpm-maint mailing list
[email protected]
http://lists.rpm.org/mailman/listinfo/rpm-maint
