Debian Bug report logs - #387446
amd64 system not compliant with FHS

Package: general; Maintainer for general is debian-devel@lists.debian.org;

Reported by: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>

Date: Thu, 14 Sep 2006 12:33:25 UTC

Severity: normal

Done: Goswin von Brederlow <goswin-v-b@web.de>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#387446; Package glibc. Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>:
New Bug report received and forwarded. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Date: Thu, 14 Sep 2006 14:05:01 +0200
[Message part 1 (text/plain, inline)]
Package: glibc
Version: 2.3.6.ds1-4
Severity: serious
Tags: patch

Hi,

the standard location for libraries on amd64 is (/usr)/lib64 but glibc
is build for (/usr)/lib. In most cases this makes no difference but
there are some:

1) Compatibility with other linux

When you copy debians libc6 or static binaries to other linux systems
then the location of plugins changes from /usr/lib to /usr/lib64
(/usr/lib/gconv/ becomes /usr/lib64/gconv/).


2) automatic conversion for multiarch

The same thing happens here. The converter for multiarch deletes the
(/usr)/lib64 link and changes (/usr)/lib to (/usr)/lib64 so the
library does not conflict with its 32bit counterpart. Again
/usr/lib/gconv/ becomes /usr/lib64/gconv/ and so on.



The attached patch is a simple solution to the problem. Glibc on amd64
gets compiled for (/usr)/lib64 as the FHS/LSB specify for amd64 but
before packaging it gets renamed to (/usr)/lib and (later) the
lib64->lib links are put in place.

This way it works everywhere.

------------------------------------------------------------------------------
I set this to serious because it sort of violates a MUST directive in the FHS:

http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html

| /lib64 and /lib32 : 64/32-bit libraries (architecture dependent)
|
| The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place
| 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries
| in /lib.

It does not specificaly mention plugins but I hope you agree the same
rational applies there for libc6.
------------------------------------------------------------------------------

MfG
	Goswin

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-frosties-2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
[glibc-lib64.patch (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#387446; Package glibc. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #10 received at 387446@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>, 387446@bugs.debian.org
Subject: Re: Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Date: Thu, 14 Sep 2006 13:28:24 -0700
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:

This is a known deviation from the FHS on amd64, and not one that is
considered release-critical for etch.

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.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Severity set to `normal' from `serious' Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#387446; Package glibc. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #17 received at 387446@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Cc: Steve Langasek <vorlon@debian.org>, 387446@bugs.debian.org
Subject: Re: Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Date: Thu, 14 Sep 2006 23:26:39 +0200
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.

> 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.

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

> 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.

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



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#387446; Package glibc. Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #22 received at 387446@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
To: Steve Langasek <vorlon@debian.org>
Cc: 387446@bugs.debian.org
Subject: Re: Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Date: Sun, 17 Sep 2006 00:19:07 +0200
Steve Langasek <vorlon@debian.org> writes:

> 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:
>
> This is a known deviation from the FHS on amd64, and not one that is
> considered release-critical for etch.

It is an unneccessary one.

> 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.

The fiddling only changes the compiled in path. But the lib64 link
makes that irelevant for Debian. Both locations end in the same
file. The risk less than some user linking or bind mounting /usr/lib
to another location and that is already supported and deemed save.

MfG
        Goswin



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#387446; Package glibc. Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #27 received at 387446@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>, Steve Langasek <vorlon@debian.org>, 387446@bugs.debian.org
Subject: Re: Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Date: Sun, 17 Sep 2006 00:32:08 +0200
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



Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#387446; Package glibc. Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. Full text and rfc822 format available.

Message #32 received at 387446@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurelien@aurel32.net>
To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Cc: Steve Langasek <vorlon@debian.org>, 387446@bugs.debian.org, control@bugs.debian.org
Subject: Re: Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Date: Fri, 22 Sep 2006 17:11:03 +0200
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



Bug reassigned from package `glibc' to `general'. Request was from Aurelien Jarno <aurelien@aurel32.net> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug title. Request was from Aurelien Jarno <aurelien@aurel32.net> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, <debian-devel@lists.debian.org>:
Bug#387446; Package general. Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>:
Extra info received and forwarded to list. Copy sent to <debian-devel@lists.debian.org>. Full text and rfc822 format available.

Message #41 received at 387446@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
To: 387446@bugs.debian.org
Cc: debian-release@lists.debian.org, debian-devel@lists.debian.org
Subject: Compatibility between Debian amd64 and other distributions
Date: Sat, 23 Sep 2006 02:50:35 +0200
Dear release team and DDs,

I submitted a trivial patch for glibc in bug#387446 to increase the
compatibility between debian amd64 and other distributions. The
maintainer has reassign this to 'general' saying:

Aurelien Jarno <aurelien@aurel32.net> writes:
> 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.

So let me summarize the situation for the release team and DDs in
general so you know that there is a problem and what it is while we
can still do something about it. The issue is the following:

FHS says that 64bit libraries on amd64 go to [/usr]/lib64. All non
Debian distributions follow that line.

Debian compiles its glibc for [/usr]/lib and adds symlinks for
[/usr]/lib64 to [/usr]/lib so FHS compliant binaries run on Debian.

But running Debian binaries on other distributions remains a
problem. For example static binaries that use libnss* plugins will
fail to find those plugins on other systems. Copying the debian libc6
to your ~/lib/ dir on another distribution will break locale plugins.


The fix is really simple. Compile glibc with libc_[s]libdir =
[/usr]/lib64 but move [/usr]/lib64 to [/usr]/lib and add the
compatibility links after the build. That results in libc6 using the
FHS paths [/usr]/lib64 when looking for plugins, which means following
the [/usr]/lib64 link on Debian, just like every other distributions
glibc does on amd64. Nothing else changes.


Aurelien Jarno doesn't like the incoherents introduced by compiling
for [/usr]/lib64 but then still using [/usr]/lib. A fact that already
exists in part in glibc because 'libc_rtlddir = /lib64' is set to get
the /lib64/ld-linux-x86-64.so.2 compiled into binaries (every dynamic
amd64 binary on Debian has that path and file). This was introduced
after sarge was released. In sarge /lib/ld-linux-x86-64.so.2 is used
in glibc binaries.

Steve Langasek had concerns about side-effects:
> 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.

So far I have seen none.


Now I guess the release-team has to make a decision how important the
FHS and compatibility is to Debian.

MfG
        Goswin



Information forwarded to debian-bugs-dist@lists.debian.org, <debian-devel@lists.debian.org>:
Bug#387446; Package general. Full text and rfc822 format available.

Acknowledgement sent to Daniel Jacobowitz <dan@debian.org>:
Extra info received and forwarded to list. Copy sent to <debian-devel@lists.debian.org>. Full text and rfc822 format available.

Message #46 received at 387446@bugs.debian.org (full text, mbox):

From: Daniel Jacobowitz <dan@debian.org>
To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Cc: 387446@bugs.debian.org, debian-release@lists.debian.org, debian-devel@lists.debian.org
Subject: Re: Compatibility between Debian amd64 and other distributions
Date: Fri, 22 Sep 2006 23:50:05 -0400
On Sat, Sep 23, 2006 at 02:50:35AM +0200, Goswin von Brederlow wrote:
> But running Debian binaries on other distributions remains a
> problem. For example static binaries that use libnss* plugins will
> fail to find those plugins on other systems. Copying the debian libc6
> to your ~/lib/ dir on another distribution will break locale plugins.

Do you have any less contrived examples?  FWIW, I think in either of
these cases you deserve to keep both pieces.

> The fix is really simple. Compile glibc with libc_[s]libdir =
> [/usr]/lib64 but move [/usr]/lib64 to [/usr]/lib and add the
> compatibility links after the build. That results in libc6 using the
> FHS paths [/usr]/lib64 when looking for plugins, which means following
> the [/usr]/lib64 link on Debian, just like every other distributions
> glibc does on amd64. Nothing else changes.

I'm perfectly happy to do this.  After etch.

-- 
Daniel Jacobowitz
CodeSourcery



Information forwarded to debian-bugs-dist@lists.debian.org, <debian-devel@lists.debian.org>:
Bug#387446; Package general. Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>:
Extra info received and forwarded to list. Copy sent to <debian-devel@lists.debian.org>. Full text and rfc822 format available.

Message #51 received at 387446@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Cc: 387446@bugs.debian.org, debian-release@lists.debian.org, debian-devel@lists.debian.org
Subject: Re: Compatibility between Debian amd64 and other distributions
Date: Sat, 23 Sep 2006 10:29:37 +0200
Daniel Jacobowitz <dan@debian.org> writes:

> On Sat, Sep 23, 2006 at 02:50:35AM +0200, Goswin von Brederlow wrote:
>> But running Debian binaries on other distributions remains a
>> problem. For example static binaries that use libnss* plugins will
>> fail to find those plugins on other systems. Copying the debian libc6
>> to your ~/lib/ dir on another distribution will break locale plugins.
>
> Do you have any less contrived examples?  FWIW, I think in either of
> these cases you deserve to keep both pieces.

How do you keep both pieces if you are not root?

MfG
        Goswin



Information forwarded to debian-bugs-dist@lists.debian.org, <debian-devel@lists.debian.org>:
Bug#387446; Package general. Full text and rfc822 format available.

Acknowledgement sent to Daniel Jacobowitz <dan@debian.org>:
Extra info received and forwarded to list. Copy sent to <debian-devel@lists.debian.org>. Full text and rfc822 format available.

Message #56 received at 387446@bugs.debian.org (full text, mbox):

From: Daniel Jacobowitz <dan@debian.org>
To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Cc: 387446@bugs.debian.org, debian-release@lists.debian.org, debian-devel@lists.debian.org
Subject: Re: Compatibility between Debian amd64 and other distributions
Date: Sat, 23 Sep 2006 10:09:43 -0400
On Sat, Sep 23, 2006 at 10:29:37AM +0200, Goswin von Brederlow wrote:
> Daniel Jacobowitz <dan@debian.org> writes:
> 
> > On Sat, Sep 23, 2006 at 02:50:35AM +0200, Goswin von Brederlow wrote:
> >> But running Debian binaries on other distributions remains a
> >> problem. For example static binaries that use libnss* plugins will
> >> fail to find those plugins on other systems. Copying the debian libc6
> >> to your ~/lib/ dir on another distribution will break locale plugins.
> >
> > Do you have any less contrived examples?  FWIW, I think in either of
> > these cases you deserve to keep both pieces.
> 
> How do you keep both pieces if you are not root?

That has nothing to do with it.  Copying libc.so.6 to something other
than its configured location breaks in plenty of other ways.  Static
binaries using nss are a long-standing and known source of problems,
and if you copy them to any other version of glibc - configured
differently or not - you're liable to crash.

-- 
Daniel Jacobowitz
CodeSourcery



Information forwarded to debian-bugs-dist@lists.debian.org, <debian-devel@lists.debian.org>:
Bug#387446; Package general. Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>:
Extra info received and forwarded to list. Copy sent to <debian-devel@lists.debian.org>. Full text and rfc822 format available.

Message #61 received at 387446@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Cc: 387446@bugs.debian.org, debian-release@lists.debian.org, debian-devel@lists.debian.org
Subject: Re: Compatibility between Debian amd64 and other distributions
Date: Sat, 23 Sep 2006 17:40:42 +0200
Daniel Jacobowitz <dan@debian.org> writes:

> On Sat, Sep 23, 2006 at 10:29:37AM +0200, Goswin von Brederlow wrote:
>> Daniel Jacobowitz <dan@debian.org> writes:
>> 
>> > On Sat, Sep 23, 2006 at 02:50:35AM +0200, Goswin von Brederlow wrote:
>> >> But running Debian binaries on other distributions remains a
>> >> problem. For example static binaries that use libnss* plugins will
>> >> fail to find those plugins on other systems. Copying the debian libc6
>> >> to your ~/lib/ dir on another distribution will break locale plugins.
>> >
>> > Do you have any less contrived examples?  FWIW, I think in either of
>> > these cases you deserve to keep both pieces.
>> 
>> How do you keep both pieces if you are not root?
>
> That has nothing to do with it.  Copying libc.so.6 to something other
> than its configured location breaks in plenty of other ways.  Static
> binaries using nss are a long-standing and known source of problems,
> and if you copy them to any other version of glibc - configured
> differently or not - you're liable to crash.

So what you seem to say is: If you copy the libc6 or static libraries
between distributions you deserve to fail. Thats fine if you say it
straight out.

Does the same apply to libX11. Or can we do the compile for lib64, use
lib trick there as it is not frozen?


As for after etch I hope binutils will add the multiarch patch and
then we can finaly start moving stuff there as was planed for after
sarge.

MfG
        Goswin

PS: Should the bug be retitled "Note FHS exception/deviation for amd64
in release notes"?



Information forwarded to debian-bugs-dist@lists.debian.org, <debian-devel@lists.debian.org>:
Bug#387446; Package general. Full text and rfc822 format available.

Acknowledgement sent to Daniel Jacobowitz <dan@debian.org>:
Extra info received and forwarded to list. Copy sent to <debian-devel@lists.debian.org>. Full text and rfc822 format available.

Message #66 received at 387446@bugs.debian.org (full text, mbox):

From: Daniel Jacobowitz <dan@debian.org>
To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Cc: 387446@bugs.debian.org, debian-release@lists.debian.org, debian-devel@lists.debian.org
Subject: Re: Compatibility between Debian amd64 and other distributions
Date: Sat, 23 Sep 2006 21:05:23 -0400
On Sat, Sep 23, 2006 at 05:40:42PM +0200, Goswin von Brederlow wrote:
> So what you seem to say is: If you copy the libc6 or static libraries
> between distributions you deserve to fail. Thats fine if you say it
> straight out.

That's what I was trying to do!

> Does the same apply to libX11. Or can we do the compile for lib64, use
> lib trick there as it is not frozen?

I don't think it matters, but it's up to the X maintainers.

-- 
Daniel Jacobowitz
CodeSourcery



Information forwarded to debian-bugs-dist@lists.debian.org, <debian-devel@lists.debian.org>:
Bug#387446; Package general. Full text and rfc822 format available.

Acknowledgement sent to David Nusinow <dnusinow@speakeasy.net>:
Extra info received and forwarded to list. Copy sent to <debian-devel@lists.debian.org>. Full text and rfc822 format available.

Message #71 received at 387446@bugs.debian.org (full text, mbox):

From: David Nusinow <dnusinow@speakeasy.net>
To: debian-devel@lists.debian.org, debian-release@lists.debian.org
Cc: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>, 387446@bugs.debian.org
Subject: Re: Compatibility between Debian amd64 and other distributions
Date: Sun, 24 Sep 2006 11:49:22 -0400
On Sat, Sep 23, 2006 at 09:05:23PM -0400, Daniel Jacobowitz wrote:
> On Sat, Sep 23, 2006 at 05:40:42PM +0200, Goswin von Brederlow wrote:
> > So what you seem to say is: If you copy the libc6 or static libraries
> > between distributions you deserve to fail. Thats fine if you say it
> > straight out.
> 
> That's what I was trying to do!
> 
> > Does the same apply to libX11. Or can we do the compile for lib64, use
> > lib trick there as it is not frozen?
> 
> I don't think it matters, but it's up to the X maintainers.

We'll probably end up following the same pattern as is decided for libc.
I'd rather not diverge, especially if the solution used for libc is the
correct one.

 - David Nusinow



Information forwarded to debian-bugs-dist@lists.debian.org, <debian-devel@lists.debian.org>:
Bug#387446; Package general. Full text and rfc822 format available.

Acknowledgement sent to Andreas Jochens <aj@andaco.de>:
Extra info received and forwarded to list. Copy sent to <debian-devel@lists.debian.org>. Full text and rfc822 format available.

Message #76 received at 387446@bugs.debian.org (full text, mbox):

From: Andreas Jochens <aj@andaco.de>
To: 387446@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Compatibility between Debian amd64 and other distributions
Date: Mon, 25 Sep 2006 09:39:23 +0200
Hello,

On 06-Sep-23 02:50, Goswin von Brederlow wrote:
> FHS says that 64bit libraries on amd64 go to [/usr]/lib64. All non
> Debian distributions follow that line.

Gentoo uses basically the same setup as Debian, i.e. it installs 64-bit 
libraries in /usr/lib and it has a symlink from /usr/lib64 to /usr/lib.

> Steve Langasek had concerns about side-effects:
> > 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.
>
> So far I have seen none.

The proposed glibc patch will break the installer. The installer does not 
have the symlink from /usr/lib64 to /usr/lib. (This is not by accident. 
It has been decided following some discussion.) 

The proposed patch changes the 64-bit library access paths used by glibc, 
i.e. (s)libdir, from (/usr)/lib to (/usr)/lib64. With this change, the 
/usr/lib64 symlink would become a necessary requirement for things to work
properly. Currently, the distribution works even without the /usr/lib64
symlink.

> Now I guess the release-team has to make a decision how important the
> FHS and compatibility is to Debian.

The proposed patch may improve compatibility with Redhat or Novell
but it does not improve compliance with the FHS.

The relevant parts of the FHS 2.3 are:

A) "/lib : Essential shared libraries and kernel modules
    Purpose: The /lib directory contains those shared library images 
    needed to boot the system and run the commands in the root filesystem,
    ie. by binaries in /bin and /sbin.

B) "/lib<qual> : Alternate format essential shared libraries (optional)
    Purpose: There may be one or more variants of the /lib directory on 
    systems which support more than one binary format requiring separate 
    libraries. [Footnote:] This is commonly used for 64-bit or 32-bit 
    support on systems which support multiple binary formats, but require 
    libraries of the same name. In this case, /lib32 and /lib64 might be 
    the library directories, and /lib a symlink to one of them."

C) "/lib64 and /lib32 : 64/32-bit libraries (architecture dependent)
    The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 
    64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries 
    in /lib. The 64-bit architecture IA64 must place 64-bit libraries in 
    /lib.
    Rationale: This is a refinement of the general rules for /lib<qual> 
    and /usr/lib<qual>. The architectures PPC64, s390x, sparc64 and 
    AMD64 support support [sic!] both 32-bit (for s390 more precise 31-bit) 
    and 64-bit programs. Using lib for 32-bit binaries allows existing 
    binaries from the 32-bit systems to work without any changes: 
    such binaries are expected to be numerous. IA-64 uses a different
    scheme, reflecting the deprecation of 32-bit binaries (and hence 
    libraries) on that architecture."

Summarized, Debian and Gentoo comply with A) and B) but not with C) 
while Redhat and Novell comply with B) and C) but not with A). 

It could be argued that the special rule C) overrides the general rule A).
On the other hand, the "Rationale" of C) shows that C) was designed 
specifically for i386/amd64 biarch distributions with a strong i386 
32-bit part. But Debian amd64 is a full native 64-bit distribution. 
The 32-bit part is purely optional and many people will not install 
any 32-bit binaries at all on their amd64 machines. 

The status quo for 64-bit and 32-bit libraries on Debian amd64
is as follows:

1) (/usr/)/lib64 is a symlink to (/usr)/lib

2) The dynamic linker name is /lib64/ld-linux-x86-64.so.2 (as per LSB).

3) 64-bit libraries are installed in /usr/lib and accessed via /usr/lib.

4) 32-bit libraries are installed in /emul/ia32-linux/(usr/)lib and
   there are symlinks from (/usr)/lib32 to /emul/ia32-linux(/usr)/lib.

1), 2) and 3) are consistent with the FHS 2.3 as long as no 32-bit 
libraries are installed on the system. Only 4) is a deviation from C)
with respect to the location of the 32-bit libraries. 

The FHS 2.3 rule C) mandates that 32-bit libraries have to be stored in 
(/usr)/lib on amd64. To implement this in Debian would be difficult 
because almost every library package would have to be changed to install
the native library files in a separate /usr/lib64 directory instead 
of the usual /usr/lib.

The other Debian ports have their native libraries installed in /usr/lib. 
Many packages rely on this fact. Many things, especially during the build
process, will break if the native libraries are not in /usr/lib. 

It would be a _lot_ of work to change the whole distribution to use 
/usr/lib64 instead of /usr/lib as the location of the native libraries.

Regards
Andreas Jochens



Tags removed: patch Request was from Holger Levsen <holger@layer-acht.org> to control@bugs.debian.org. (Wed, 03 Sep 2008 15:09:11 GMT) Full text and rfc822 format available.

Bug closed, send any further explanations to Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> Request was from Goswin von Brederlow <goswin-v-b@web.de> to control@bugs.debian.org. (Thu, 04 Sep 2008 11:36:07 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 03 Oct 2008 07:28:01 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 00:38:52 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.