Steve Langasek a écrit :
On Thu, Feb 23, 2006 at 10:58:15PM +0100, Aurelien Jarno wrote:
Some update on this, as we have evolved a lot since the last mail.
Bdale Garbee a écrit :
On Tue, 2006-02-21 at 07:10 +0100, Aurelien Jarno wrote:
Moving 32-bit libraries to (/usr)/lib32 won't make the amd64 port
compliant with the FHS, which is almost impossible given the current
setup, ie 64-bit libraries in /lib. However, it would make it compliant
with the part of the FHS which says that alternative libraries have to
be in (/usr)/lib<qual>. And it would make us compatible with other
distributions like Gentoo or Ubuntu that have choosen to use (/usr)/lib32.
What sort of value should we assign to achieving that level of
"compatibility" with other distributions before multiarch, where I
expect us to be in the lead and others to be trying to figure out if/how
to be compatible with Debian?
Part of the reason I'm unhappy about the current FHS situation is that
<qual> seems generally to get defined as "32" or "64" and the definition
of what belongs in the unqualified version of the directories feels
inconsistent across architectures. Part of what I like about our
multiarch strategy is generalizing this to handle more "interesting"
cases like emulated execution environments, etc. The world just isn't
as simple as 32 vs 64 implies...
I'm inclined to make as few "structural changes" to ia32-libs as
possible pending multiarch implementation. The reason is that anything
we change is going to make work for people, including work we can't
anticipate or judge the scale of, like users who have laboriously worked
to manually install additional libraries on their systems. If we're
going to put people through a transition process, I'd prefer it be the
transition to multiarch!
You have been heard! The glibc currently in incoming has a preliminary
multiarch support. It currently looks to librairies in both (/usr)/lib
and (/usr)/lib/$(host-triplet)/. It support additional libraries (like
the current one in multilib), via ldconfig, with /lib/ldconfig/ being
the configuration directory.
Using this it will be possible to add a link from (/usr)/lib64 to the
multiarch directories to be compliant with the FHS. And that let time to
discuss if we want a (/usr)/lib32 or not on amd64 :).
Currently those directories are supported on all architectures, but only
amd64 has files in them, a libc6 for i386. It will be used as a test
architecture before doing the same on other 32/64 bit architectures, as
there are very few packages to changes.
I'm concerned that putting files in /usr/lib/i486-linux-gnu/ may be
premature. Has thought been given to what this means for the upgrade path
when (...if) dpkg is extended to support installing Arch: i386 multiarch
debs directly on amd64? I suppose it should just be a Replaces:, but it
still seems like it will be an extra unnecessary transition.
After a discussion on IRC, it seems there is no consensus about how
multiarch should be done. Therefore I stop working on that (patches are
still welcome for glibc).
The only change planned is to make libc6-dev-i386 and libc6-i386 provide
a glibc on amd64 instead of ia32-libs. It will be in /emul/ia32-linux (I
still have to find how to do that cleanly in the debhelper files).
Bdale, do you agree with such a change?
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian GNU/Linux developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`- people.debian.org/~aurel32 | www.aurel32.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
