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 :).
> 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 :).
> 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).
> > 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.
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
