Compatibility between Debian amd64 and other distributions

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

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