Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Aurelien Jarno <aurelien@aurel32.net> writes:

> On Thu, Sep 14, 2006 at 01:28:24PM -0700, Steve Langasek wrote:
>> severity 387446 normal
>> thanks
>> 
>> On Thu, Sep 14, 2006 at 02:05:01PM +0200, Goswin von Brederlow wrote:
>> 
>> > I set this to serious because it sort of violates a MUST directive in the
>> > FHS:
>
> Your changes also violate the FHS, as the system libraries should be in
> /lib.

Two things. First it doesn't move the libc6 out of /lib. Secondly not
for amd64. That is a special case made so i386 binaries can stay the
same on amd64. Only Debian has deviated from that setup as vorlon said
in his next sentence:

>> This is a known deviation from the FHS on amd64, and not one that is
>> considered release-critical for etch.
>
> There is currently no way to do a plain amd64 distribution without
> violating the FHS. So I don't really want to make changes that probably
> have side effects just for violating the FHS another way.

The FHS sees amd64 as a 64bit extension of i386, just like ppc, sparc,
mips, s390 have their 64bit extensions. In that sense a plain amd64
distribution would mean that you have no libraries in /lib or /usr/lib
since you have no 32bit libs at all. If that violates something in the
FHS then too bad. But does that mean we should just violate more?

> My opinion is that the FHS should be changed. Unfortunately nobody seems
> to read the FHS mailing list...

Multiarch dirs will not happen for etch. Maybe some day the proposal
will be adopted. But Debian not implementing it doesn't really help
the case.

>> That probably means that a change for this would not be accepted into etch,
>> since fiddling library paths may have unexpected side-effects and glibc is
>> already frozen.
>> 
>
> Agreed.

Can we at least put it into sid so you can see that nothing changes?

MfG
        Goswin