Re: Breaking /emul/ia32-linux for squeeze
Clint Adams <schizo@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
Reply to: