Aurelien Jarno <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]