[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



reassign 387446 general
retitle 387446: amd64 system not compliant with FHS
thanks

Goswin von Brederlow wrote:
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

Which is really bad. At least the current way of doing that is coherent.

With your proposal the libraries are compiled for /lib64 and are put in /lib. You are still violating the FHS the same way because the libraries are at the same exact location. But this is also totally incoherent.

With the current situation the libraries are compiled for /lib and are put in /lib. This violates the FHS, but it is coherent.

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?

No, because that would remove us the possibility to make fixes in testing. We are planning to do another upload with documentation fixes.

Also packages that go into testing are build against the glibc in sid. This could lead to broken package going to testing.

Actually there is nothing wrong with the glibc, it is perfectly coherent with the other packages on amd64, even if it violates the FHS. If you want to change it we have to stay coherent and also change all the others packages. I am therefore reassigning this bug to general. A global decision as to be taken.

--
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net



Reply to: