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]
