Clint Adams <sch...@debian.org> writes: > On Wed, Mar 11, 2009 at 10:10:13PM -0700, Steve Langasek wrote: >> But moving the 32-bit libs to /usr/lib32 does not make us >> standards-conformant on amd64, because the FHS (yuckily) standardized on >> storing the *32-bit* libs in /usr/lib on this architecture, with 64-bit libs >> in /usr/lib64. > > That is true, which means that someone will undoubtedly file FHS-violation > bugs > on anything using /usr/lib32 after such a transition.
Exactly. You go from the wrong place to another wrong place. Nothing gained but bug reports. > On Thu, Mar 12, 2009 at 10:53:21AM +0100, Goswin von Brederlow wrote: >> NO NO NO NO NO NO NO NO. >> >> It is high time to change to the multiarch dir. For that gcc needs to >> be fixed first so compiling 32bit code does not break. Transitioning >> to /usr/lib32 will just needlessly break systems. > > The rest of this thread gives me the impression that > 1) there is precious little chance that multiarch will happen anytime > reasonably soon gcc-4.4 has a new multiarch patch included. It is still buggy but it makes me hopes the gcc maintainers care about it. > 2) there is no point in using multiarch directories instead of /usr/lib32 > prematurely > > Aurélien and I are talking about switching to /usr/lib32 somewhere around the > time > that (E)GLIBC hits sid. You do realize what that entails, right? /usr/lib32 is currently a link so you need a predepends on libc6 in every 32bit package. > Are we going to have multiarch soon so that project can be abandoned? Imho once the default gcc can link against libraries in /usr/lib/i486-linux-gnu with "gcc -m32" that directory can be populated. The libfoo i386 multiarch package will have to Conflicts: lib32foo in any case as far as I'm concerned to avoid two versions of the same lib to be available no matter where they are located. Having them both in /usr/lib/i486-linux-gnu just adds the need for "Replaces: lib32foo" which I don't consider a bad thing. On the road to true multiarch there is another step though that you (glibc maintainers) can work on. The split of libc6 into libc6 and libc6-bin. Policy requires that already but the last ftp-master did shut it down of fear of breaking things. Maybe time would be better spend implementing and extensively testing the split rather than a unneccessary transition to /usr/lib32. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org