Debian Bug report logs - #632682
we should probably remove /lib64 -> lib symlink (with care)

version graph

Package: libc6; Maintainer for libc6 is GNU Libc Maintainers <debian-glibc@lists.debian.org>; Source for libc6 is src:eglibc.

Reported by: Aurelien Jarno <aurel32@debian.org>

Date: Mon, 4 Jul 2011 20:21:01 UTC

Severity: wishlist

Fixed in version eglibc/2.13-17

Done: Aurelien Jarno <aurel32@debian.org>

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, Santiago Vila <sanvila@debian.org>:
Bug#632682; Package base-files. (Mon, 04 Jul 2011 20:21:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurel32@debian.org>:
New Bug report received and forwarded. Copy sent to Santiago Vila <sanvila@debian.org>. (Mon, 04 Jul 2011 20:21:04 GMT) Full text and rfc822 format available.

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

From: Aurelien Jarno <aurel32@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Mon, 04 Jul 2011 22:18:25 +0200
Package: base-files
Version: 6.4
Severity: wishlist

Up to know libc6 is providing a /lib64 -> /lib symlink on amd64, 
kfreebsd-amd64, ppc64 and sparc64. With multiarch it's not possible for 
libc6 to provide such a symlink anymore as the package can be installed
(using multiarch) on a 32-bit system. See bug#632176 for more details.

It looks like the best place to place such a symbolic link is in 
base-files. Could you please provide it in base-files for the above
architectures? For that you need to add a Replace: libc6 (<< 2.13-10)
(to be adjusted to the current libc6 version). When done, I'll remove
the symlink from libc6 and add the necessary dependencies.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages base-files depends on:
ii  gawk [awk]                1:3.1.7.dfsg-5 GNU awk, a pattern scanning and pr
ii  mawk [awk]                1.3.3-15       a pattern scanning and text proces
ii  original-awk [awk]        2011-05-06-1   The original awk described in "The

base-files recommends no packages.

base-files suggests no packages.

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Santiago Vila <sanvila@debian.org>:
Bug#632682; Package base-files. (Tue, 05 Jul 2011 09:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Santiago Vila <sanvila@debian.org>. (Tue, 05 Jul 2011 09:09:04 GMT) Full text and rfc822 format available.

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

From: Santiago Vila <sanvila@unex.es>
To: Aurelien Jarno <aurel32@debian.org>, 632682@bugs.debian.org
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Tue, 5 Jul 2011 11:06:26 +0200 (CEST)
On Mon, 4 Jul 2011, Aurelien Jarno wrote:

> Package: base-files
> Version: 6.4
> Severity: wishlist
> 
> Up to know libc6 is providing a /lib64 -> /lib symlink on amd64, 
> kfreebsd-amd64, ppc64 and sparc64. With multiarch it's not possible for 
> libc6 to provide such a symlink anymore as the package can be installed
> (using multiarch) on a 32-bit system. See bug#632176 for more details.
> 
> It looks like the best place to place such a symbolic link is in 
> base-files. Could you please provide it in base-files for the above
> architectures? For that you need to add a Replace: libc6 (<< 2.13-10)
> (to be adjusted to the current libc6 version). When done, I'll remove
> the symlink from libc6 and add the necessary dependencies.

Ok. Do you mean both /lib64 and /usr/lib64, or just /lib64?




Information forwarded to debian-bugs-dist@lists.debian.org, Santiago Vila <sanvila@debian.org>:
Bug#632682; Package base-files. (Tue, 05 Jul 2011 09:42:18 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to Santiago Vila <sanvila@debian.org>. (Tue, 05 Jul 2011 09:42:25 GMT) Full text and rfc822 format available.

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

From: Sven Joachim <svenjoac@gmx.de>
To: Aurelien Jarno <aurel32@debian.org>
Cc: 632682@bugs.debian.org
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Tue, 05 Jul 2011 11:38:02 +0200
On 2011-07-04 22:18 +0200, Aurelien Jarno wrote:

> Package: base-files
> Version: 6.4
> Severity: wishlist
>
> Up to know libc6 is providing a /lib64 -> /lib symlink on amd64, 
> kfreebsd-amd64, ppc64 and sparc64. With multiarch it's not possible for 
> libc6 to provide such a symlink anymore as the package can be installed
> (using multiarch) on a 32-bit system. See bug#632176 for more details.
>
> It looks like the best place to place such a symbolic link is in 
> base-files. Could you please provide it in base-files for the above
> architectures? For that you need to add a Replace: libc6 (<< 2.13-10)
> (to be adjusted to the current libc6 version). When done, I'll remove
> the symlink from libc6 and add the necessary dependencies.

Note that base-files must also be marked "Multi-Arch: foreign" then,
otherwise libc6 is not installable on foreign architectures.

Cheers,
       Sven




Information forwarded to debian-bugs-dist@lists.debian.org, Santiago Vila <sanvila@debian.org>:
Bug#632682; Package base-files. (Tue, 05 Jul 2011 10:22:36 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to Santiago Vila <sanvila@debian.org>. (Tue, 05 Jul 2011 10:22:47 GMT) Full text and rfc822 format available.

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

From: Sven Joachim <svenjoac@gmx.de>
To: Aurelien Jarno <aurel32@debian.org>
Cc: 632682@bugs.debian.org
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Tue, 05 Jul 2011 12:15:59 +0200
On 2011-07-04 22:18 +0200, Aurelien Jarno wrote:

> Up to know libc6 is providing a /lib64 -> /lib symlink on amd64, 
> kfreebsd-amd64, ppc64 and sparc64. With multiarch it's not possible for 
> libc6 to provide such a symlink anymore as the package can be installed
> (using multiarch) on a 32-bit system. See bug#632176 for more details.
>
> It looks like the best place to place such a symbolic link is in 
> base-files. Could you please provide it in base-files for the above
> architectures? For that you need to add a Replace: libc6 (<< 2.13-10)
> (to be adjusted to the current libc6 version). When done, I'll remove
> the symlink from libc6 and add the necessary dependencies.

The more I think about this, the more it confuses me.  Even if libc6
Pre-Depends on base-files, does that guarantee that libc6 is unpacked
after base-files while bootstrapping a system?  That would be necessary
if you want to put ld-linux-x86-64.so.2 into /lib64.

If that is not your plan, how are amd64 binaries supposed to work when
all you have is /lib/ld-linux-x86-64.so.2 and no /lib64 symlink to it
(on foreign architectures)?

Regards,
        Sven




Information forwarded to debian-bugs-dist@lists.debian.org, Santiago Vila <sanvila@debian.org>:
Bug#632682; Package base-files. (Tue, 05 Jul 2011 17:51:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurel32@debian.org>:
Extra info received and forwarded to list. Copy sent to Santiago Vila <sanvila@debian.org>. (Tue, 05 Jul 2011 17:51:05 GMT) Full text and rfc822 format available.

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

From: Aurelien Jarno <aurel32@debian.org>
To: Santiago Vila <sanvila@unex.es>
Cc: 632682@bugs.debian.org
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Tue, 5 Jul 2011 19:47:56 +0200
On Tue, Jul 05, 2011 at 11:06:26AM +0200, Santiago Vila wrote:
> On Mon, 4 Jul 2011, Aurelien Jarno wrote:
> 
> > Package: base-files
> > Version: 6.4
> > Severity: wishlist
> > 
> > Up to know libc6 is providing a /lib64 -> /lib symlink on amd64, 
> > kfreebsd-amd64, ppc64 and sparc64. With multiarch it's not possible for 
> > libc6 to provide such a symlink anymore as the package can be installed
> > (using multiarch) on a 32-bit system. See bug#632176 for more details.
> > 
> > It looks like the best place to place such a symbolic link is in 
> > base-files. Could you please provide it in base-files for the above
> > architectures? For that you need to add a Replace: libc6 (<< 2.13-10)
> > (to be adjusted to the current libc6 version). When done, I'll remove
> > the symlink from libc6 and add the necessary dependencies.
> 
> Ok. Do you mean both /lib64 and /usr/lib64, or just /lib64?
> 

Good catch, we should do this for both /lib64 and /usr/lib64

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, Santiago Vila <sanvila@debian.org>:
Bug#632682; Package base-files. (Tue, 05 Jul 2011 17:54:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurel32@debian.org>:
Extra info received and forwarded to list. Copy sent to Santiago Vila <sanvila@debian.org>. (Tue, 05 Jul 2011 17:54:06 GMT) Full text and rfc822 format available.

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

From: Aurelien Jarno <aurel32@debian.org>
To: Sven Joachim <svenjoac@gmx.de>
Cc: 632682@bugs.debian.org
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Tue, 5 Jul 2011 19:51:15 +0200
On Tue, Jul 05, 2011 at 11:38:02AM +0200, Sven Joachim wrote:
> On 2011-07-04 22:18 +0200, Aurelien Jarno wrote:
> 
> > Package: base-files
> > Version: 6.4
> > Severity: wishlist
> >
> > Up to know libc6 is providing a /lib64 -> /lib symlink on amd64, 
> > kfreebsd-amd64, ppc64 and sparc64. With multiarch it's not possible for 
> > libc6 to provide such a symlink anymore as the package can be installed
> > (using multiarch) on a 32-bit system. See bug#632176 for more details.
> >
> > It looks like the best place to place such a symbolic link is in 
> > base-files. Could you please provide it in base-files for the above
> > architectures? For that you need to add a Replace: libc6 (<< 2.13-10)
> > (to be adjusted to the current libc6 version). When done, I'll remove
> > the symlink from libc6 and add the necessary dependencies.
> 
> Note that base-files must also be marked "Multi-Arch: foreign" then,
> otherwise libc6 is not installable on foreign architectures.
> 

True, but it worries me a bit. If it is marked Multi-Arch: foreign, it
means that the i386 version of base-files is enough to satisfy the
pre-depends on libc6. And the i386 version doesn't provide the symlink
that is needed to make the amd64 system working.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, Santiago Vila <sanvila@debian.org>:
Bug#632682; Package base-files. (Tue, 05 Jul 2011 17:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurel32@debian.org>:
Extra info received and forwarded to list. Copy sent to Santiago Vila <sanvila@debian.org>. (Tue, 05 Jul 2011 17:57:03 GMT) Full text and rfc822 format available.

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

From: Aurelien Jarno <aurel32@debian.org>
To: Sven Joachim <svenjoac@gmx.de>
Cc: 632682@bugs.debian.org
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Tue, 5 Jul 2011 19:54:04 +0200
On Tue, Jul 05, 2011 at 12:15:59PM +0200, Sven Joachim wrote:
> On 2011-07-04 22:18 +0200, Aurelien Jarno wrote:
> 
> > Up to know libc6 is providing a /lib64 -> /lib symlink on amd64, 
> > kfreebsd-amd64, ppc64 and sparc64. With multiarch it's not possible for 
> > libc6 to provide such a symlink anymore as the package can be installed
> > (using multiarch) on a 32-bit system. See bug#632176 for more details.
> >
> > It looks like the best place to place such a symbolic link is in 
> > base-files. Could you please provide it in base-files for the above
> > architectures? For that you need to add a Replace: libc6 (<< 2.13-10)
> > (to be adjusted to the current libc6 version). When done, I'll remove
> > the symlink from libc6 and add the necessary dependencies.
> 
> The more I think about this, the more it confuses me.  Even if libc6
> Pre-Depends on base-files, does that guarantee that libc6 is unpacked
> after base-files while bootstrapping a system?  That would be necessary
> if you want to put ld-linux-x86-64.so.2 into /lib64.

ld-linux-x86-64.so.2 is currently in /lib and there is no plan to change
that. During bootstrapping, all the packages are first unpacked, and
then installed using dpkg. This last step will already have the correct
/lib64 -> /lib symlink.

> If that is not your plan, how are amd64 binaries supposed to work when
> all you have is /lib/ld-linux-x86-64.so.2 and no /lib64 symlink to it
> (on foreign architectures)?
> 

That's a good plan, it looks like we definitely have to move
ld-linux-x86-64.so.2 from /lib to /lib64. Looks like a complex
transition.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, Santiago Vila <sanvila@debian.org>:
Bug#632682; Package base-files. (Tue, 05 Jul 2011 20:39:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to Santiago Vila <sanvila@debian.org>. (Tue, 05 Jul 2011 20:39:03 GMT) Full text and rfc822 format available.

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

From: Sven Joachim <svenjoac@gmx.de>
To: Aurelien Jarno <aurel32@debian.org>
Cc: 632682@bugs.debian.org
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Tue, 05 Jul 2011 22:37:38 +0200
On 2011-07-05 19:54 +0200, Aurelien Jarno wrote:

> On Tue, Jul 05, 2011 at 12:15:59PM +0200, Sven Joachim wrote:
>> On 2011-07-04 22:18 +0200, Aurelien Jarno wrote:
>> 
>> > Up to know libc6 is providing a /lib64 -> /lib symlink on amd64, 
>> > kfreebsd-amd64, ppc64 and sparc64. With multiarch it's not possible for 
>> > libc6 to provide such a symlink anymore as the package can be installed
>> > (using multiarch) on a 32-bit system. See bug#632176 for more details.
>> >
>> > It looks like the best place to place such a symbolic link is in 
>> > base-files. Could you please provide it in base-files for the above
>> > architectures? For that you need to add a Replace: libc6 (<< 2.13-10)
>> > (to be adjusted to the current libc6 version). When done, I'll remove
>> > the symlink from libc6 and add the necessary dependencies.
>> 
>> The more I think about this, the more it confuses me.  Even if libc6
>> Pre-Depends on base-files, does that guarantee that libc6 is unpacked
>> after base-files while bootstrapping a system?  That would be necessary
>> if you want to put ld-linux-x86-64.so.2 into /lib64.
>
> ld-linux-x86-64.so.2 is currently in /lib and there is no plan to change
> that. During bootstrapping, all the packages are first unpacked, and
> then installed using dpkg. This last step will already have the correct
> /lib64 -> /lib symlink.

Well, this and the proposed base-files dependency mean that libc6:amd64
is not usable on foreign architectures.

>> If that is not your plan, how are amd64 binaries supposed to work when
>> all you have is /lib/ld-linux-x86-64.so.2 and no /lib64 symlink to it
>> (on foreign architectures)?
>> 
>
> That's a good plan, it looks like we definitely have to move
> ld-linux-x86-64.so.2 from /lib to /lib64. Looks like a complex
> transition.

I think this is the only way to ensure peaceful coexistence of
libc6:amd64 with i386 biarch packages.  But for that, /lib64 actually
must not be a symlink to /lib, as I have demonstrated in #632176.

Cheers,
       Sven




Information forwarded to debian-bugs-dist@lists.debian.org, Santiago Vila <sanvila@debian.org>:
Bug#632682; Package base-files. (Mon, 25 Jul 2011 12:51:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Santiago Vila <sanvila@debian.org>. (Mon, 25 Jul 2011 12:51:10 GMT) Full text and rfc822 format available.

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

From: Santiago Vila <sanvila@unex.es>
To: Aurelien Jarno <aurel32@debian.org>, 632682@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Mon, 25 Jul 2011 14:50:11 +0200 (CEST)
reassign 632682 libc6
retitle 632682 we should probably remove /lib64 -> lib symlink (with care)
thanks

Hi. After discussing about this today, it seems what we really need
for multiarch to work is to remove those symlinks, hence this reassign.

Thanks.




Bug reassigned from package 'base-files' to 'libc6'. Request was from Santiago Vila <sanvila@unex.es> to control@bugs.debian.org. (Mon, 25 Jul 2011 12:51:19 GMT) Full text and rfc822 format available.

Bug No longer marked as found in versions base-files/6.4. Request was from Santiago Vila <sanvila@unex.es> to control@bugs.debian.org. (Mon, 25 Jul 2011 12:51:23 GMT) Full text and rfc822 format available.

Changed Bug title to 'we should probably remove /lib64 -> lib symlink (with care)' from 'base-files: please provide a /lib64 -> /lib symlink on 64-bit systems' Request was from Santiago Vila <sanvila@unex.es> to control@bugs.debian.org. (Mon, 25 Jul 2011 12:51:24 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Wed, 10 Aug 2011 17:18:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Wed, 10 Aug 2011 17:18:05 GMT) Full text and rfc822 format available.

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

From: Sven Joachim <svenjoac@gmx.de>
To: 632682@bugs.debian.org, Santiago Vila <sanvila@unex.es>, Aurelien Jarno <aurel32@debian.org>
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Wed, 10 Aug 2011 19:14:57 +0200
On 2011-07-25 14:50 +0200, Santiago Vila wrote:

> reassign 632682 libc6
> retitle 632682 we should probably remove /lib64 -> lib symlink (with care)
> thanks
>
> Hi. After discussing about this today, it seems what we really need
> for multiarch to work is to remove those symlinks, hence this reassign.

Has anyone started working on this yet?

Cheers,
       Sven




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Wed, 10 Aug 2011 17:51:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurel32@debian.org>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Wed, 10 Aug 2011 17:51:05 GMT) Full text and rfc822 format available.

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

From: Aurelien Jarno <aurel32@debian.org>
To: Sven Joachim <svenjoac@gmx.de>, 632682@bugs.debian.org
Cc: Santiago Vila <sanvila@unex.es>
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Wed, 10 Aug 2011 19:48:58 +0200
On Wed, Aug 10, 2011 at 07:14:57PM +0200, Sven Joachim wrote:
> On 2011-07-25 14:50 +0200, Santiago Vila wrote:
> 
> > reassign 632682 libc6
> > retitle 632682 we should probably remove /lib64 -> lib symlink (with care)
> > thanks
> >
> > Hi. After discussing about this today, it seems what we really need
> > for multiarch to work is to remove those symlinks, hence this reassign.
> 
> Has anyone started working on this yet?
> 

We got some ideas, but AFAIK nobody has started to work on that.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Wed, 10 Aug 2011 18:39:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Wed, 10 Aug 2011 18:39:10 GMT) Full text and rfc822 format available.

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

From: Sven Joachim <svenjoac@gmx.de>
To: Aurelien Jarno <aurel32@debian.org>
Cc: 632682@bugs.debian.org, Santiago Vila <sanvila@unex.es>
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Wed, 10 Aug 2011 20:35:39 +0200
On 2011-08-10 19:48 +0200, Aurelien Jarno wrote:

> On Wed, Aug 10, 2011 at 07:14:57PM +0200, Sven Joachim wrote:
>> On 2011-07-25 14:50 +0200, Santiago Vila wrote:
>> 
>> > reassign 632682 libc6
>> > retitle 632682 we should probably remove /lib64 -> lib symlink (with care)
>> > thanks
>> >
>> > Hi. After discussing about this today, it seems what we really need
>> > for multiarch to work is to remove those symlinks, hence this reassign.
>> 
>> Has anyone started working on this yet?
>> 
>
> We got some ideas, but AFAIK nobody has started to work on that.

I'll have a look at it in the next few days if nobody beats me to it.
Just to confirm that my ideas were the same as yours, AFAICS the
following needs to be done in the preinst (on amd64), if /lib64 is a
symlink:

1) remove /lib64
2) create /lib64 directory
3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to /lib64/ld-linux-x86-64.so.2

2) and 3) are a bit difficult after the path to the ELF interpreter has
just disappeared.  I guess you still want to stick to shell nonetheless
(as opposed to doing these steps in perl, say) ?

Cheers,
       Sven




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Wed, 10 Aug 2011 18:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Wed, 10 Aug 2011 18:51:06 GMT) Full text and rfc822 format available.

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

From: Jonathan Nieder <jrnieder@gmail.com>
To: Sven Joachim <svenjoac@gmx.de>
Cc: 632682@bugs.debian.org, Aurelien Jarno <aurel32@debian.org>, Santiago Vila <sanvila@unex.es>
Subject: Re: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Wed, 10 Aug 2011 13:47:27 -0500
Sven Joachim wrote:

> 1) remove /lib64
> 2) create /lib64 directory
> 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to /lib64/ld-linux-x86-64.so.2
>
> 2) and 3) are a bit difficult after the path to the ELF interpreter has
> just disappeared.  I guess you still want to stick to shell nonetheless
> (as opposed to doing these steps in perl, say) ?

I wonder if the following would make sense:

 1) mkdir /lib64.real
 2) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to
    /lib64.real/ld-linux-x64-64.so.2
 3) ln -s lib64.real /lib64.eglibc-tmp
 4) mv -f /lib64.eglibc-tmp /lib64
 5) clean up on next reboot




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Wed, 10 Aug 2011 19:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Wed, 10 Aug 2011 19:42:03 GMT) Full text and rfc822 format available.

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

From: Sven Joachim <svenjoac@gmx.de>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 632682@bugs.debian.org, Aurelien Jarno <aurel32@debian.org>, Santiago Vila <sanvila@unex.es>
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Wed, 10 Aug 2011 21:38:56 +0200
On 2011-08-10 20:47 +0200, Jonathan Nieder wrote:

> Sven Joachim wrote:
>
>> 1) remove /lib64
>> 2) create /lib64 directory
>> 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to /lib64/ld-linux-x86-64.so.2
>>
>> 2) and 3) are a bit difficult after the path to the ELF interpreter has
>> just disappeared.  I guess you still want to stick to shell nonetheless
>> (as opposed to doing these steps in perl, say) ?
>
> I wonder if the following would make sense:
>
>  1) mkdir /lib64.real
>  2) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to
>     /lib64.real/ld-linux-x64-64.so.2
                          ^^^^^

Should be -x86-, but otherwise this makes some sense to me.  But with
the following you've lost me:

>  3) ln -s lib64.real /lib64.eglibc-tmp
>  4) mv -f /lib64.eglibc-tmp /lib64

Now you have a broken lib/lib64.eglibc.tmp symlink which is not quite
what you want. ;-)  It would make more sense to use /lib64.eglibc-tmp/
as source, but this seems to fail with ENOTDIR.

>  5) clean up on next reboot

Not sure what you mean with that.  Could you elaborate?

Cheers,
       Sven




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Wed, 10 Aug 2011 19:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Wed, 10 Aug 2011 19:54:03 GMT) Full text and rfc822 format available.

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

From: Jonathan Nieder <jrnieder@gmail.com>
To: Sven Joachim <svenjoac@gmx.de>
Cc: 632682@bugs.debian.org, Aurelien Jarno <aurel32@debian.org>, Santiago Vila <sanvila@unex.es>
Subject: Re: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Wed, 10 Aug 2011 14:50:46 -0500
Hi again,

Sorry for the lack of clarity.

Sven Joachim wrote:
> On 2011-08-10 20:47 +0200, Jonathan Nieder wrote:

>>  3) ln -s lib64.real /lib64.eglibc-tmp
>>  4) mv -f /lib64.eglibc-tmp /lib64
>
> Now you have a broken lib/lib64.eglibc.tmp symlink which is not quite
> what you want. ;-)  It would make more sense to use /lib64.eglibc-tmp/
> as source, but this seems to fail with ENOTDIR.

Yes, this is what I get for thinking in terms of system calls instead
of reading the manpage.

  mv -fT /lib64.eglibc-tmp /lib64

should work.

>>  5) clean up on next reboot
>
> Not sure what you mean with that.  Could you elaborate?

Well, I handwaved it, but the problem is that there is no way to
atomically replace a symlink by a directory, and it would be best if
this is atomic to avoid disrupting applications running concurrently.
How to address that?  Well, just do the hard part:

	rm /lib64
	mv /lib64.real /lib64

when nothing is running concurrently, in early boot.

Well, that is what I just wrote, but there is a little handwaving
involved: which initscript, exactly?  (The initramfs would be the
easy place to do that kind of thing, but not everyone uses an
initramfs.)  And how to prevent this from running concurrently with
another script?  I don't have a good answer for that.

One answer would be to make a script for the sysadmin to run to
take care of it and just leave a /lib64 -> /lib64.real symlink until
that's done.




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Wed, 10 Aug 2011 20:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurel32@debian.org>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Wed, 10 Aug 2011 20:03:03 GMT) Full text and rfc822 format available.

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

From: Aurelien Jarno <aurel32@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Sven Joachim <svenjoac@gmx.de>, 632682@bugs.debian.org, Santiago Vila <sanvila@unex.es>
Subject: Re: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Wed, 10 Aug 2011 21:59:48 +0200
On Wed, Aug 10, 2011 at 02:50:46PM -0500, Jonathan Nieder wrote:
> Hi again,
> 
> Sorry for the lack of clarity.
> 
> Sven Joachim wrote:
> > On 2011-08-10 20:47 +0200, Jonathan Nieder wrote:
> 
> >>  3) ln -s lib64.real /lib64.eglibc-tmp
> >>  4) mv -f /lib64.eglibc-tmp /lib64
> >
> > Now you have a broken lib/lib64.eglibc.tmp symlink which is not quite
> > what you want. ;-)  It would make more sense to use /lib64.eglibc-tmp/
> > as source, but this seems to fail with ENOTDIR.
> 
> Yes, this is what I get for thinking in terms of system calls instead
> of reading the manpage.
> 
>   mv -fT /lib64.eglibc-tmp /lib64
> 
> should work.

No it doesn't work for symlinks.

> >>  5) clean up on next reboot
> >
> > Not sure what you mean with that.  Could you elaborate?
> 
> Well, I handwaved it, but the problem is that there is no way to
> atomically replace a symlink by a directory, and it would be best if
> this is atomic to avoid disrupting applications running concurrently.
> How to address that?  Well, just do the hard part:
> 
> 	rm /lib64
> 	mv /lib64.real /lib64
> 
> when nothing is running concurrently, in early boot.

The problem is that your never reboot chroots.
 
> Well, that is what I just wrote, but there is a little handwaving
> involved: which initscript, exactly?  (The initramfs would be the
> easy place to do that kind of thing, but not everyone uses an
> initramfs.)  And how to prevent this from running concurrently with
> another script?  I don't have a good answer for that.
> 
> One answer would be to make a script for the sysadmin to run to
> take care of it and just leave a /lib64 -> /lib64.real symlink until
> that's done.
> 

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Wed, 10 Aug 2011 20:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurel32@debian.org>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Wed, 10 Aug 2011 20:06:03 GMT) Full text and rfc822 format available.

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

From: Aurelien Jarno <aurel32@debian.org>
To: Sven Joachim <svenjoac@gmx.de>
Cc: 632682@bugs.debian.org, Santiago Vila <sanvila@unex.es>
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Wed, 10 Aug 2011 22:03:07 +0200
On Wed, Aug 10, 2011 at 08:35:39PM +0200, Sven Joachim wrote:
> On 2011-08-10 19:48 +0200, Aurelien Jarno wrote:
> 
> > On Wed, Aug 10, 2011 at 07:14:57PM +0200, Sven Joachim wrote:
> >> On 2011-07-25 14:50 +0200, Santiago Vila wrote:
> >> 
> >> > reassign 632682 libc6
> >> > retitle 632682 we should probably remove /lib64 -> lib symlink (with care)
> >> > thanks
> >> >
> >> > Hi. After discussing about this today, it seems what we really need
> >> > for multiarch to work is to remove those symlinks, hence this reassign.
> >> 
> >> Has anyone started working on this yet?
> >> 
> >
> > We got some ideas, but AFAIK nobody has started to work on that.
> 
> I'll have a look at it in the next few days if nobody beats me to it.
> Just to confirm that my ideas were the same as yours, AFAICS the
> following needs to be done in the preinst (on amd64), if /lib64 is a
> symlink:
> 
> 1) remove /lib64
> 2) create /lib64 directory
> 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to /lib64/ld-linux-x86-64.so.2
> 
> 2) and 3) are a bit difficult after the path to the ELF interpreter has
> just disappeared.  I guess you still want to stick to shell nonetheless
> (as opposed to doing these steps in perl, say) ?
> 

This is basically what we have in mind, though it has not been tested.
For step 2 and 3, you can call the ELF interpreter directly, that is 
"/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64".

The whole operation is still not atomic, but so far it's the best way to
do it. We might want to insert a call to sync as steps 0 and 4, to
minimize the possible time with ELF interpreter, and to make sure the
data is written to the disk as soon as possible (otherwise if the
machine crashes, the system can't boot).

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Wed, 10 Aug 2011 20:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Wed, 10 Aug 2011 20:09:03 GMT) Full text and rfc822 format available.

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

From: Jonathan Nieder <jrnieder@gmail.com>
To: Aurelien Jarno <aurel32@debian.org>
Cc: Sven Joachim <svenjoac@gmx.de>, 632682@bugs.debian.org, Santiago Vila <sanvila@unex.es>
Subject: Re: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Wed, 10 Aug 2011 15:05:19 -0500
Aug 10, 2011 at 09:59:48PM +0200, Aurelien Jarno wrote:
> On Wed, Aug 10, 2011 at 02:50:46PM -0500, Jonathan Nieder wrote:

>>   mv -fT /lib64.eglibc-tmp /lib64
>> 
>> should work.
>
> No it doesn't work for symlinks.

Could you elaborate?  Running

	ln -s a b
	ln -s c d
	strace mv -fT b d
	ls -l d

seems to suggest replacing one symlink by another works on Linux.
Further, rename(2) is documented to allow this, and I am not aware of
any special-case logic in coreutils that would affect it.

[...]
>> 	rm /lib64
>> 	mv /lib64.real /lib64
>> 
>> when nothing is running concurrently, in early boot.
>
> The problem is that your never reboot chroots.

Sure, hence the need for the admin to intervene at a quiet time (or
it can be left alone --- is a symlink /lib64 -> lib64.real really
harmful?).

Alternatively, why can't we keep the /lib64 -> /lib symlink?  Getting
rid of it is not my itch.  Lack of breakage in the squeeze -> wheezy
upgrade is.




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Wed, 10 Aug 2011 20:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurel32@debian.org>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Wed, 10 Aug 2011 20:21:03 GMT) Full text and rfc822 format available.

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

From: Aurelien Jarno <aurel32@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Sven Joachim <svenjoac@gmx.de>, 632682@bugs.debian.org, Santiago Vila <sanvila@unex.es>
Subject: Re: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Wed, 10 Aug 2011 22:19:56 +0200
On Wed, Aug 10, 2011 at 03:05:19PM -0500, Jonathan Nieder wrote:
> Aug 10, 2011 at 09:59:48PM +0200, Aurelien Jarno wrote:
> > On Wed, Aug 10, 2011 at 02:50:46PM -0500, Jonathan Nieder wrote:
> 
> >>   mv -fT /lib64.eglibc-tmp /lib64
> >> 
> >> should work.
> >
> > No it doesn't work for symlinks.
> 
> Could you elaborate?  Running
> 
> 	ln -s a b
> 	ln -s c d
> 	strace mv -fT b d
> 	ls -l d
> 
> seems to suggest replacing one symlink by another works on Linux.
> Further, rename(2) is documented to allow this, and I am not aware of
> any special-case logic in coreutils that would affect it.

Ah ok, I thought you were trying to replace a symlink by a directory.

> [...]
> >> 	rm /lib64
> >> 	mv /lib64.real /lib64
> >> 
> >> when nothing is running concurrently, in early boot.
> >
> > The problem is that your never reboot chroots.
> 
> Sure, hence the need for the admin to intervene at a quiet time (or
> it can be left alone --- is a symlink /lib64 -> lib64.real really
> harmful?).

I don't think we want any manual intervention for this transition. For
the symlink I would prefer not having /lib64 left, as a lot of configure
scripts are actually looking to /lib64 to determine random things. Also
we have just seen that leaving leftover that are not handled by dpkg can
be a pain years after.

> Alternatively, why can't we keep the /lib64 -> /lib symlink?  Getting
> rid of it is not my itch.  Lack of breakage in the squeeze -> wheezy
> upgrade is.

Because install libc6:amd64 on a 32-bit system means that /lib64 points
to a directory with 32-bit libraries. People can break their systems
that way (see for example #632176).

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Wed, 10 Aug 2011 20:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Wed, 10 Aug 2011 20:36:03 GMT) Full text and rfc822 format available.

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

From: Sven Joachim <svenjoac@gmx.de>
To: Aurelien Jarno <aurel32@debian.org>
Cc: 632682@bugs.debian.org, Santiago Vila <sanvila@unex.es>
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Wed, 10 Aug 2011 22:32:27 +0200
On 2011-08-10 22:03 +0200, Aurelien Jarno wrote:

> On Wed, Aug 10, 2011 at 08:35:39PM +0200, Sven Joachim wrote:
>> 
>> I'll have a look at it in the next few days if nobody beats me to it.
>> Just to confirm that my ideas were the same as yours, AFAICS the
>> following needs to be done in the preinst (on amd64), if /lib64 is a
>> symlink:
>> 
>> 1) remove /lib64
>> 2) create /lib64 directory
>> 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to /lib64/ld-linux-x86-64.so.2
>> 
>> 2) and 3) are a bit difficult after the path to the ELF interpreter has
>> just disappeared.  I guess you still want to stick to shell nonetheless
>> (as opposed to doing these steps in perl, say) ?
>> 
>
> This is basically what we have in mind, though it has not been tested.
> For step 2 and 3, you can call the ELF interpreter directly, that is 
> "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64".

Except for the case where you install the libc on a foreign
architecture.  Then this might not work.

> The whole operation is still not atomic, but so far it's the best way to
> do it. We might want to insert a call to sync as steps 0 and 4, to
> minimize the possible time with ELF interpreter, and to make sure the
> data is written to the disk as soon as possible (otherwise if the
> machine crashes, the system can't boot).

Good idea.

Cheers,
       Sven




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Wed, 10 Aug 2011 20:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurel32@debian.org>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Wed, 10 Aug 2011 20:48:03 GMT) Full text and rfc822 format available.

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

From: Aurelien Jarno <aurel32@debian.org>
To: Sven Joachim <svenjoac@gmx.de>
Cc: 632682@bugs.debian.org, Santiago Vila <sanvila@unex.es>
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Wed, 10 Aug 2011 22:44:23 +0200
On Wed, Aug 10, 2011 at 10:32:27PM +0200, Sven Joachim wrote:
> On 2011-08-10 22:03 +0200, Aurelien Jarno wrote:
> 
> > On Wed, Aug 10, 2011 at 08:35:39PM +0200, Sven Joachim wrote:
> >> 
> >> I'll have a look at it in the next few days if nobody beats me to it.
> >> Just to confirm that my ideas were the same as yours, AFAICS the
> >> following needs to be done in the preinst (on amd64), if /lib64 is a
> >> symlink:
> >> 
> >> 1) remove /lib64
> >> 2) create /lib64 directory
> >> 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to /lib64/ld-linux-x86-64.so.2
> >> 
> >> 2) and 3) are a bit difficult after the path to the ELF interpreter has
> >> just disappeared.  I guess you still want to stick to shell nonetheless
> >> (as opposed to doing these steps in perl, say) ?
> >> 
> >
> > This is basically what we have in mind, though it has not been tested.
> > For step 2 and 3, you can call the ELF interpreter directly, that is 
> > "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64".
> 
> Except for the case where you install the libc on a foreign
> architecture.  Then this might not work.
> 

The goal is to do that only in the preinst of libc0.1/6 (we can't do
that in the postinst as it would means the files on the filesystem and
in dpkg are not consistent), and only if /lib64 is a symlink. Given we
have removed the "Multiarch: same" tag in the libc6 packages of 
architectures having a /lib64 symlink, these systems can't have a 
foreign coreutils as it would depends on a foreign libc which is not 
installable.

That's only valid if we ignore the 2 or 3 versions that have been in sid
with this "Multiarch: same" tag.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Wed, 10 Aug 2011 21:13:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Wed, 10 Aug 2011 21:14:35 GMT) Full text and rfc822 format available.

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

From: Sven Joachim <svenjoac@gmx.de>
To: Aurelien Jarno <aurel32@debian.org>
Cc: 632682@bugs.debian.org, Santiago Vila <sanvila@unex.es>
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Wed, 10 Aug 2011 23:08:56 +0200
On 2011-08-10 22:44 +0200, Aurelien Jarno wrote:

> On Wed, Aug 10, 2011 at 10:32:27PM +0200, Sven Joachim wrote:
>> On 2011-08-10 22:03 +0200, Aurelien Jarno wrote:
>> >
>> > This is basically what we have in mind, though it has not been tested.
>> > For step 2 and 3, you can call the ELF interpreter directly, that is 
>> > "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64".
>> 
>> Except for the case where you install the libc on a foreign
>> architecture.  Then this might not work.
>> 
>
> The goal is to do that only in the preinst of libc0.1/6 (we can't do
> that in the postinst as it would means the files on the filesystem and
> in dpkg are not consistent), and only if /lib64 is a symlink. Given we
> have removed the "Multiarch: same" tag in the libc6 packages of 
> architectures having a /lib64 symlink,

You have removed them, but people still might have older libc versions
installed that are Multiarch:same.  Like myself in my multiarch
adventure chroot were libc6 is stalled at 2.13-10.

> these systems can't have a foreign coreutils as it would depends on a
> foreign libc which is not installable.

Even if libc6 is no longer Multiarch:same, that does not prevent
installing libc6:amd64 and libc0.1:kfreebsd-amd64 simultaneously,
AFAICS.  Now when upgrading you have a 50% chance that the native libc
is unpacked first.

> That's only valid if we ignore the 2 or 3 versions that have been in sid
> with this "Multiarch: same" tag.

Ubuntu has many more versions, and a dpkg that actually supports
multiarch.  But for them this may not be such a big problem since only
amd64 and i386 are supported, and people who have enabled multiarch
almost surely run a 64-bit kernel.

Cheers,
       Sven




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Wed, 10 Aug 2011 21:25:17 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Wed, 10 Aug 2011 21:25:18 GMT) Full text and rfc822 format available.

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

From: Jonathan Nieder <jrnieder@gmail.com>
To: Aurelien Jarno <aurel32@debian.org>
Cc: Sven Joachim <svenjoac@gmx.de>, 632682@bugs.debian.org, Santiago Vila <sanvila@unex.es>
Subject: Re: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Wed, 10 Aug 2011 16:13:15 -0500
Aurelien Jarno wrote:

> I don't think we want any manual intervention for this transition. For
> the symlink I would prefer not having /lib64 left, as a lot of configure
> scripts are actually looking to /lib64 to determine random things. Also
> we have just seen that leaving leftover that are not handled by dpkg can
> be a pain years after.

Ok, that's convincing enough.  I'm tempted to suggest (*)

	mkdir /lib64.real
	symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to
		/lib64.real/ld-linux-x86-64.so.2

	if this is a chroot:
		sync
		unlink /lib64
		rename /lib64.real to /lib64
		sync
	else:
		ln -s lib64.real /lib64.eglibc-tmp
		rename lib64.eglibc-tmp to /lib64

and replacing the /lib64 symlink with a directory on startup in the
non-chroot case, hoping that

 (1) in chroots, hopefully not too much is happening concurrently
 (2) in non-chroots, people reboot from time to time to get security
     updates

But for now, why not always take the "if this is a chroot" branch.
The atomicity part can happen later (when it is reported as a bug or
someone implements it).  If we're lucky, the syncs will stall other
processes long enough to avoid trouble. :)




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Sat, 13 Aug 2011 19:27:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Sat, 13 Aug 2011 19:27:11 GMT) Full text and rfc822 format available.

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

From: Sven Joachim <svenjoac@gmx.de>
To: Aurelien Jarno <aurel32@debian.org>
Cc: 632682@bugs.debian.org, Santiago Vila <sanvila@unex.es>
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Sat, 13 Aug 2011 21:25:46 +0200
[Message part 1 (text/plain, inline)]
On 2011-08-10 22:03 +0200, Aurelien Jarno wrote:

> On Wed, Aug 10, 2011 at 08:35:39PM +0200, Sven Joachim wrote:
>> 
>> I'll have a look at it in the next few days if nobody beats me to it.
>> Just to confirm that my ideas were the same as yours, AFAICS the
>> following needs to be done in the preinst (on amd64), if /lib64 is a
>> symlink:
>> 
>> 1) remove /lib64
>> 2) create /lib64 directory
>> 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to /lib64/ld-linux-x86-64.so.2
>> 
>> 2) and 3) are a bit difficult after the path to the ELF interpreter has
>> just disappeared.  I guess you still want to stick to shell nonetheless
>> (as opposed to doing these steps in perl, say) ?
>> 
>
> This is basically what we have in mind, though it has not been tested.
> For step 2 and 3, you can call the ELF interpreter directly, that is 
> "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64".

Almost right, you have use /bin/mkdir though since the interpreter knows
nothing about PATH:

,----
| # /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64
| mkdir: error while loading shared libraries: mkdir: cannot open shared object file
`----

> The whole operation is still not atomic, but so far it's the best way to
> do it. We might want to insert a call to sync as steps 0 and 4, to
> minimize the possible time with ELF interpreter, and to make sure the
> data is written to the disk as soon as possible (otherwise if the
> machine crashes, the system can't boot).

After getting the necessary minimal grasp of the packaging system, I
have come up with a first shot towards a solution, see the attached
patch set.

Upgrade from and downgrade to 2.13-16 has been tested in a minimal amd64
sid chroot.  Also, I have tested upgrades from and downgrades to 2.13-10
in an i386/amd64 chroot with a multiarch-capable dpkg and i386 as
primary architecture.  I haven't yet checked or analyzed the
consequences of unpacking failures during upgrade or downgrade.

Known problems:

- Multiarch systems with multiple libc6 versions shipping the /lib64
  symlink will be hosed if the native libc6 is not unpacked first.
  Since this involves at least one unofficial architecture and an 
  unofficial dpkg, it is probably ignorable.

- Installing packages that ship files under /lib64 and then downgrading
  to a libc6 that ships the symlink breaks those packages.  Should maybe
  give a warning on downgrades if any files beside the ELF interpreter
  are found in /lib64.

- The lsb-core package installs symlinks /lib64/ld-lsb-x86-64.so.[23] to
  /lib/ld-linux-x86-64.so.2 that get broken.  Nothing dramatic and
  solvable in a few ways.

Cheers,
       Sven

-- 
I still say "/lib64" is one of the nastiest pieces of shit I've ever
heard of.
-- Branden Robinson


[0001-Don-t-create-lib64-and-usr-lib64-symlinks.patch (text/plain, attachment)]
[0002-Install-the-dynamic-linker-into-RTLDDIR-rather-than-.patch (text/plain, attachment)]
[0003-Remove-the-lib64-symlink-on-upgrades.patch (text/plain, attachment)]
[0004-Restore-multiarch-support-on-all-architectures.patch (text/plain, attachment)]
[0005-Install-the-dynamic-linker-into-lib-as-well.patch (text/plain, attachment)]
[0006-Restore-the-lib64-symlink-on-downgrades.patch (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Sat, 13 Aug 2011 20:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Sat, 13 Aug 2011 20:18:03 GMT) Full text and rfc822 format available.

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

From: Jonathan Nieder <jrnieder@gmail.com>
To: Sven Joachim <svenjoac@gmx.de>, 632682@bugs.debian.org
Cc: Aurelien Jarno <aurel32@debian.org>, Santiago Vila <sanvila@unex.es>
Subject: Re: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Sat, 13 Aug 2011 15:14:19 -0500
Quick thoughts.

Sven Joachim wrote:

> +    ldfile=$(readlink -e RTLD_SO)
> +    # Test if libc is of the same architecture as coreutils
> +    # If not, they almost surely have a multiarch system and we can use
> +    # the native ELF interpreter
> +    if ! $ldfile /bin/true 2>/dev/null; then
> +	interpreter=
> +    else
> +	interpreter=$ldfile
> +    fi

Very neat.

[...]
> Subject: [PATCH 2/6] Install the dynamic linker into RTLDDIR rather than /lib
[...]
> --- a/debian/debhelper.in/libc.install
> +++ b/debian/debhelper.in/libc.install
> @@ -1,4 +1,4 @@
> -TMPDIR/lib/*.so* /lib
> +TMPDIR/RTLDDIR/*.so* /lib
>  TMPDIR/SLIBDIR/*.so* SLIBDIR
>  TMPDIR/LIBDIR/gconv/* LIBDIR/gconv
>
> diff --git a/debian/rules.d/build.mk b/debian/rules.d/build.mk
> index 18f1800..36d7ee7 100644
> --- a/debian/rules.d/build.mk
> +++ b/debian/rules.d/build.mk
[...]
> -         link_name="debian/tmp-$(curpass)/lib/$$rtld_so" ; \
> +         link_name="debian/tmp-$(curpass)/$(call xx,rtlddir)/$$rtld_so" ; \
>           target="$(call xx,slibdir)/$$(readlink debian/tmp-$(curpass)/$(call xx,slibdir)/$$rtld_so)" ; \
> +         mkdir -p debian/tmp-$(curpass)/$(call xx,rtlddir); \
>           ln -s $$target $$link_name ;  \

Do I understand correctly that this is this a no-op (to prepare for
patch 5)?

[...]
> @@ -384,6 +404,13 @@ fi
>  #DEBHELPER#
>  
>  if [ -n "$preversion" ]; then
> +    if test -L /lib64; then
> +	case ${DPKG_MAINTSCRIPT_ARCH:-$(dpkg --print-architecture)} in
> +	    amd64 | ppc64 | sparc64 | s390x)
> +		remove_lib64_symlink ;;
> +	esac
> +    fi

If DPKG_MAINTSCRIPT_ARCH isn't set for some reason, this gives the
wrong value.  Would it be possible to introduce a variable in
debian/rules.d/debhelper.mk so the right value can be cooked in at
build time?

> Subject: [PATCH 6/6] Restore the /lib64 symlink on downgrades
>
> It would be more prudent to prevent the downgrade from happening, but
> if we fail the prerm script, the one from the previous version kicks
> in and succeeds.

Fixed by dpkg commit 9d3ec0f5 (“dpkg: do not fallback to "new-prerm
failed-upgrade" for downgrades”).  Probably that's too new to count
on.

> +#Downgrading from a version with a /lib64 directory to a version with
> +# a /lib64 symlink is extremely dangerous.  We need to blow away the
> +# directory and restore the symlink, otherwise the dynamic linker gets
> +# lost after unpacking the replacing version.
> +
> +    ldfile=$(readlink -e RTLD_SO)
> +    # Test if libc is of the same architecture as coreutils
> +    # If not, they almost surely have a multiarch system and we can use
> +    # the native ELF interpreter
> +    if ! $ldfile /bin/true 2>/dev/null; then
> +	interpreter=
> +    else
> +	interpreter=$ldfile
> +    fi
> +
> +    # sync before and after the operation to reduce the danger of hosing
> +    # the system
> +    sync
> +    rm -rf /lib64
> +    $interpreter /bin/ln -s /lib /lib64

Maybe it would be possible to mv /lib64 somewhere and loudly let the
admin know about it if it contains anything more than the dynamic
linker.

Remaining problems:

 - disruption to anything running concurrently with the
   upgrade/downgrade.  In the general case, there's nothing one can do
   about this except warn about it.

 - what happens if someone (a) has been trying to load libraries by
   filename in /lib64 or (b) has been installing libraries to /lib64
   and expecting to find them there?

   Most likely, that's not a big deal --- I would expect people to have
   used /usr/local/lib64 or /usr/lib64, but not /lib64.

 - What happens to the /usr/lib64 symlink?

Except where mentioned above, it looks good to me (though I haven't
tested yet).  Thanks!




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Sat, 13 Aug 2011 21:24:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Sat, 13 Aug 2011 21:24:12 GMT) Full text and rfc822 format available.

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

From: Sven Joachim <svenjoac@gmx.de>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 632682@bugs.debian.org, Aurelien Jarno <aurel32@debian.org>, Santiago Vila <sanvila@unex.es>
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Sat, 13 Aug 2011 23:17:02 +0200
Thanks for the review, Jonathan.

On 2011-08-13 22:14 +0200, Jonathan Nieder wrote:

> Sven Joachim wrote:
>
>> -         link_name="debian/tmp-$(curpass)/lib/$$rtld_so" ; \
>> +         link_name="debian/tmp-$(curpass)/$(call xx,rtlddir)/$$rtld_so" ; \
>>           target="$(call xx,slibdir)/$$(readlink debian/tmp-$(curpass)/$(call xx,slibdir)/$$rtld_so)" ; \
>> +         mkdir -p debian/tmp-$(curpass)/$(call xx,rtlddir); \
>>           ln -s $$target $$link_name ;  \
>
> Do I understand correctly that this is this a no-op (to prepare for
> patch 5)?

Ouch.  It should not have been; I made a mistake while rebasing the
patches, because the target dir in libc.install needs to be set to
RTLDDIR, not to /lib.

> [...]
>> @@ -384,6 +404,13 @@ fi
>>  #DEBHELPER#
>>  
>>  if [ -n "$preversion" ]; then
>> +    if test -L /lib64; then
>> +	case ${DPKG_MAINTSCRIPT_ARCH:-$(dpkg --print-architecture)} in
>> +	    amd64 | ppc64 | sparc64 | s390x)
>> +		remove_lib64_symlink ;;
>> +	esac
>> +    fi
>
> If DPKG_MAINTSCRIPT_ARCH isn't set for some reason, this gives the
> wrong value.  Would it be possible to introduce a variable in
> debian/rules.d/debhelper.mk so the right value can be cooked in at
> build time?

Probably, but I guess it does not matter in practice.
DPKG_MAINTSCRIPT_ARCH is exported by dpkg since 1.15.4, and old dpkg
versions don't support multiarch so you have to do something totally
weird to install a foreign libc6.

>> It would be more prudent to prevent the downgrade from happening, but
>> if we fail the prerm script, the one from the previous version kicks
>> in and succeeds.
>
> Fixed by dpkg commit 9d3ec0f5 (“dpkg: do not fallback to "new-prerm
> failed-upgrade" for downgrades”).  Probably that's too new to count
> on.

Ah, I wasn't aware of that.  Still, adding a Pre-Depends on dpkg 1.16.1
on the affected arches is probably not a good idea.

>> +#Downgrading from a version with a /lib64 directory to a version with
>> +# a /lib64 symlink is extremely dangerous.  We need to blow away the
>> +# directory and restore the symlink, otherwise the dynamic linker gets
>> +# lost after unpacking the replacing version.
>> +
>> +    ldfile=$(readlink -e RTLD_SO)
>> +    # Test if libc is of the same architecture as coreutils
>> +    # If not, they almost surely have a multiarch system and we can use
>> +    # the native ELF interpreter
>> +    if ! $ldfile /bin/true 2>/dev/null; then
>> +	interpreter=
>> +    else
>> +	interpreter=$ldfile
>> +    fi
>> +
>> +    # sync before and after the operation to reduce the danger of hosing
>> +    # the system
>> +    sync
>> +    rm -rf /lib64
>> +    $interpreter /bin/ln -s /lib /lib64
>
> Maybe it would be possible to mv /lib64 somewhere and loudly let the
> admin know about it if it contains anything more than the dynamic
> linker.

Good idea.  Something like that:

  aside=$(mktemp -d /lib64-moved-by-libc6-prerm.XXXXXX)
  echo "Moving /lib64 aside to $aside"
  mv /lib64 $aside


I have some private undertakings tomorrow, will likely send a new patch
series on Monday, unless somebody beats me to it.

Cheers,
       Sven

-- 
I still say "/lib64" is one of the nastiest pieces of shit I've ever
heard of.
-- Branden Robinson





Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Mon, 15 Aug 2011 15:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Mon, 15 Aug 2011 15:57:03 GMT) Full text and rfc822 format available.

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

From: Sven Joachim <svenjoac@gmx.de>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 632682@bugs.debian.org, Aurelien Jarno <aurel32@debian.org>, Santiago Vila <sanvila@unex.es>
Subject: Re: Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
Date: Mon, 15 Aug 2011 17:53:42 +0200
[Message part 1 (text/plain, inline)]
On 2011-08-13 23:17 +0200, Sven Joachim wrote:

> On 2011-08-13 22:14 +0200, Jonathan Nieder wrote:
>
>> Sven Joachim wrote:
>>
>>> -         link_name="debian/tmp-$(curpass)/lib/$$rtld_so" ; \
>>> +         link_name="debian/tmp-$(curpass)/$(call xx,rtlddir)/$$rtld_so" ; \
>>>           target="$(call xx,slibdir)/$$(readlink debian/tmp-$(curpass)/$(call xx,slibdir)/$$rtld_so)" ; \
>>> +         mkdir -p debian/tmp-$(curpass)/$(call xx,rtlddir); \
>>>           ln -s $$target $$link_name ;  \

I have completely dropped this part.  Installing into
debian/tmp-$(curpass)/lib is fine at this stage, no matter what the
final destination is.

>> Do I understand correctly that this is this a no-op (to prepare for
>> patch 5)?
>
> Ouch.  It should not have been; I made a mistake while rebasing the
> patches, because the target dir in libc.install needs to be set to
> RTLDDIR, not to /lib.

So I install into both RTLDDIR and /lib, as in the old patch 5.

>> [...]
>>> @@ -384,6 +404,13 @@ fi
>>>  #DEBHELPER#
>>>  
>>>  if [ -n "$preversion" ]; then
>>> +    if test -L /lib64; then
>>> +	case ${DPKG_MAINTSCRIPT_ARCH:-$(dpkg --print-architecture)} in
>>> +	    amd64 | ppc64 | sparc64 | s390x)
>>> +		remove_lib64_symlink ;;
>>> +	esac
>>> +    fi
>>
>> If DPKG_MAINTSCRIPT_ARCH isn't set for some reason, this gives the
>> wrong value.  Would it be possible to introduce a variable in
>> debian/rules.d/debhelper.mk so the right value can be cooked in at
>> build time?
>
> Probably, but I guess it does not matter in practice.
> DPKG_MAINTSCRIPT_ARCH is exported by dpkg since 1.15.4, and old dpkg
> versions don't support multiarch so you have to do something totally
> weird to install a foreign libc6.

I don't feel the need to do anything about it and leave it to Aurelien
if he thinks this is necessary.

>> Maybe it would be possible to mv /lib64 somewhere and loudly let the
>> admin know about it if it contains anything more than the dynamic
>> linker.
>
> Good idea.  Something like that:
>
>   aside=$(mktemp -d /lib64-moved-by-libc6-prerm.XXXXXX)
>   echo "Moving /lib64 aside to $aside"
>   mv /lib64 $aside

See patches 5 and 6 in the new attached series.

> I have some private undertakings tomorrow, will likely send a new patch
> series on Monday, unless somebody beats me to it.

The biggest change compared to the previous one is the new patch 6 which
tries to check that there is at least one free inode.  Namely, if there
aren't any, the sequence

    rm -f /lib64
    $interpreter /bin/mkdir /lib64
    $interpreter /bin/ln -s $ldfile RTLD_SO

will fail in the third command which is rather embarrassing.  This is of
course far from perfect, if another process runs riot and creates files
rapidly, you can still lose.  Also, that part isn't really tested at all
(except that it works when there are no ENOSPC problems).

I have lightly tested unpack failures by introducing a file conflict
with another package, they do at least not lead to immediate disaster.
The only problem that I see is that if unpacking fails during upgrade
and you then downgrade to an older _major_ eglibc version,
/lib64/ld-linux-x86-64.so.2 becomes a dangling symlink.  I don't think
there is much which can be done about this.

Cheers,
       Sven


[0001-Don-t-create-lib64-and-usr-lib64-symlinks.patch (text/plain, attachment)]
[0002-Install-the-dynamic-linker-into-RTLDDIR-as-well-as-l.patch (text/plain, attachment)]
[0003-Remove-the-lib64-symlink-on-upgrades.patch (text/plain, attachment)]
[0004-Restore-multiarch-support-on-all-architectures.patch (text/plain, attachment)]
[0005-Restore-the-lib64-symlink-on-downgrades.patch (text/plain, attachment)]
[0006-Check-for-free-inode-before-lib64-symlink-conversion.patch (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Thu, 18 Aug 2011 00:36:03 GMT) 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>. (Thu, 18 Aug 2011 00:36:03 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: 623682@bugs.debian.org
Subject: Re: we should probably remove /lib64 -> lib symlink (with care)
Date: Wed, 17 Aug 2011 16:05:10 -0700
Hiya,

> The biggest change compared to the previous one is the new patch 6 which
> tries to check that there is at least one free inode.  Namely, if there
> aren't any, the sequence

>     rm -f /lib64
>     $interpreter /bin/mkdir /lib64
>     $interpreter /bin/ln -s $ldfile RTLD_SO

> will fail in the third command which is rather embarrassing.  This is of
> course far from perfect, if another process runs riot and creates files
> rapidly, you can still lose.  Also, that part isn't really tested at all
> (except that it works when there are no ENOSPC problems).

Nack on this.  The right way to handle it is to create the directory under a
separate name, populate the symlink, and only *then* rm /lib64 and invoke mv
/lib64.real /lib64 via $interpreter.  This minimizes the window when /lib64
is missing, and just happens to also remove the inode problem as a side
effect (because we create all the directory entries we need before we remove
any).

So basically what Jonathan suggested up-thread.

> Subject: [PATCH 2/6] Install the dynamic linker into RTLDDIR as well as /lib

> Installing into both locations makes it easier to support downgrades.
> It also means that dpkg will fail to unpack our package if
> RTLDDIR=/lib64 and /lib64 is a symlink to /lib.  Which is probably a
> good thing since that symlink has to go away.

I'm not keen on this.  Why would we want to install a second copy of
ld-linux-x86-64.so.2 to /lib?  Nothing will use it there.  Shouldn't we be
installing *only* to RTLDDIR, not to both?

And no, this won't cause dpkg to fail to unpack.  dpkg happily traverses
symlinks while unpacking and would never notice that the two files are being
installed to the same location.

Otherwise, this looks good.  I'll merge these up (with the above-mentioned
changes) and put it through its paces here.

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




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Thu, 18 Aug 2011 07:03:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Thu, 18 Aug 2011 07:03:07 GMT) Full text and rfc822 format available.

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

From: Sven Joachim <svenjoac@gmx.de>
To: Steve Langasek <vorlon@debian.org>
Cc: 632682@bugs.debian.org
Subject: Re: Bug#632682: we should probably remove /lib64 -> lib symlink (with care)
Date: Thu, 18 Aug 2011 09:00:52 +0200
On 2011-08-18 01:05 +0200, Steve Langasek wrote:

>> The biggest change compared to the previous one is the new patch 6 which
>> tries to check that there is at least one free inode.  Namely, if there
>> aren't any, the sequence
>
>>     rm -f /lib64
>>     $interpreter /bin/mkdir /lib64
>>     $interpreter /bin/ln -s $ldfile RTLD_SO
>
>> will fail in the third command which is rather embarrassing.  This is of
>> course far from perfect, if another process runs riot and creates files
>> rapidly, you can still lose.  Also, that part isn't really tested at all
>> (except that it works when there are no ENOSPC problems).
>
> Nack on this.  The right way to handle it is to create the directory under a
> separate name, populate the symlink, and only *then* rm /lib64 and invoke mv
> /lib64.real /lib64 via $interpreter.  This minimizes the window when /lib64
> is missing, and just happens to also remove the inode problem as a side
> effect (because we create all the directory entries we need before we remove
> any).

Yes, that's better.  Instead of hardcoding /lib64.real the directory
should be created with mktemp -d (I think that's what you meant to do).

>> Subject: [PATCH 2/6] Install the dynamic linker into RTLDDIR as well as /lib
>
>> Installing into both locations makes it easier to support downgrades.
>> It also means that dpkg will fail to unpack our package if
>> RTLDDIR=/lib64 and /lib64 is a symlink to /lib.  Which is probably a
>> good thing since that symlink has to go away.
>
> I'm not keen on this.  Why would we want to install a second copy of
> ld-linux-x86-64.so.2 to /lib?  Nothing will use it there.  Shouldn't we be
> installing *only* to RTLDDIR, not to both?

I don't have a strong opinion on this.  Make sure to copy
ld-linux-x86-64.so.2 to /lib in the prerm on downgrades then; if the
downgrade fails during unpack, /lib/ld-linux-x86-64.so.2 is unowned.

> And no, this won't cause dpkg to fail to unpack.  dpkg happily traverses
> symlinks while unpacking and would never notice that the two files are being
> installed to the same location.

It does if the files are contained in the same package, an example can
be found in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624724#10.

> Otherwise, this looks good.  I'll merge these up (with the above-mentioned
> changes) and put it through its paces here.

Thanks for stepping in.

Cheers,
       Sven




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Thu, 18 Aug 2011 16:24:03 GMT) 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>. (Thu, 18 Aug 2011 16:24:03 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: Sven Joachim <svenjoac@gmx.de>
Cc: 632682@bugs.debian.org
Subject: Re: Bug#632682: we should probably remove /lib64 -> lib symlink (with care)
Date: Thu, 18 Aug 2011 09:20:34 -0700
[Message part 1 (text/plain, inline)]
On Thu, Aug 18, 2011 at 09:00:52AM +0200, Sven Joachim wrote:
> > The right way to handle it is to create the directory under a separate
> > name, populate the symlink, and only *then* rm /lib64 and invoke mv
> > /lib64.real /lib64 via $interpreter.  This minimizes the window when /lib64
> > is missing, and just happens to also remove the inode problem as a side
> > effect (because we create all the directory entries we need before we remove
> > any).

> Yes, that's better.  Instead of hardcoding /lib64.real the directory
> should be created with mktemp -d (I think that's what you meant to do).

Hmm, no, I didn't see a need for mktemp here.  You're concerned about a
collision with an admin-created directory?  That seems improbable to me, but
certainly using mkdir doesn't hurt.

> >> Subject: [PATCH 2/6] Install the dynamic linker into RTLDDIR as well as /lib

> >> Installing into both locations makes it easier to support downgrades.
> >> It also means that dpkg will fail to unpack our package if
> >> RTLDDIR=/lib64 and /lib64 is a symlink to /lib.  Which is probably a
> >> good thing since that symlink has to go away.

> > I'm not keen on this.  Why would we want to install a second copy of
> > ld-linux-x86-64.so.2 to /lib?  Nothing will use it there.  Shouldn't we be
> > installing *only* to RTLDDIR, not to both?

> I don't have a strong opinion on this.  Make sure to copy
> ld-linux-x86-64.so.2 to /lib in the prerm on downgrades then; if the
> downgrade fails during unpack, /lib/ld-linux-x86-64.so.2 is unowned.

Sure.

> > And no, this won't cause dpkg to fail to unpack.  dpkg happily traverses
> > symlinks while unpacking and would never notice that the two files are being
> > installed to the same location.

> It does if the files are contained in the same package, an example can
> be found in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624724#10.

I don't think that's an accurate interpretation of what's happening in that
bug, but would need to see the filesystem to say what is happening.  But as
the error is "no such file or directory", it probably means it's managed to
get itself into a situation of trying to unpack a file for which the parent
directory doesn't exist.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Thu, 18 Aug 2011 18:27:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Thu, 18 Aug 2011 18:27:09 GMT) Full text and rfc822 format available.

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

From: Sven Joachim <svenjoac@gmx.de>
To: Steve Langasek <vorlon@debian.org>
Cc: 632682@bugs.debian.org
Subject: Re: Bug#632682: we should probably remove /lib64 -> lib symlink (with care)
Date: Thu, 18 Aug 2011 20:25:14 +0200
On 2011-08-18 18:20 +0200, Steve Langasek wrote:

> On Thu, Aug 18, 2011 at 09:00:52AM +0200, Sven Joachim wrote:
>> > The right way to handle it is to create the directory under a separate
>> > name, populate the symlink, and only *then* rm /lib64 and invoke mv
>> > /lib64.real /lib64 via $interpreter.  This minimizes the window when /lib64
>> > is missing, and just happens to also remove the inode problem as a side
>> > effect (because we create all the directory entries we need before we remove
>> > any).
>
>> Yes, that's better.  Instead of hardcoding /lib64.real the directory
>> should be created with mktemp -d (I think that's what you meant to do).
>
> Hmm, no, I didn't see a need for mktemp here.  You're concerned about a
> collision with an admin-created directory?  That seems improbable to me, but
> certainly using mkdir doesn't hurt.

That was my thought, exactly.

>> > And no, this won't cause dpkg to fail to unpack.  dpkg happily traverses
>> > symlinks while unpacking and would never notice that the two files are being
>> > installed to the same location.
>
>> It does if the files are contained in the same package, an example can
>> be found in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624724#10.
>
> I don't think that's an accurate interpretation of what's happening in that
> bug, but would need to see the filesystem to say what is happening.

You can reproduce it yourself in an i386 chroot.  Make sure you have no
/usr/lib64 directory, then "ln -s lib /usr/lib64; apt-get install fakeroot".

> But as the error is "no such file or directory", it probably means
> it's managed to get itself into a situation of trying to unpack a file
> for which the parent directory doesn't exist.

Not at all.  Here is what happens if you install a package that ships
both foo/x and bar/x while bar is a symlink to foo on the filesystem:
dpkg unpacks to files with temporary names, foo/x.dpkg-new and
bar/x.dpkg-new, still not noticing the file conflict and overwriting the
files with each other.  It then renames foo/x.dpkg-new to foo/x and
bar/x.dpkg-new to bar/x -- with the last step ENOENT failing, because it
had already renamed the file to foo/x.

Run "strace -erename dpkg -i …/fakeroot*.deb" in the above situation to
see for yourself.

Cheers,
       Sven




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Thu, 18 Aug 2011 18:42:02 GMT) 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>. (Thu, 18 Aug 2011 18:42:03 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: Sven Joachim <svenjoac@gmx.de>
Cc: 632682@bugs.debian.org
Subject: Re: Bug#632682: we should probably remove /lib64 -> lib symlink (with care)
Date: Thu, 18 Aug 2011 11:39:18 -0700
[Message part 1 (text/plain, inline)]
On Thu, Aug 18, 2011 at 08:25:14PM +0200, Sven Joachim wrote:
> >> > And no, this won't cause dpkg to fail to unpack.  dpkg happily traverses
> >> > symlinks while unpacking and would never notice that the two files are being
> >> > installed to the same location.

> >> It does if the files are contained in the same package, an example can
> >> be found in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624724#10.

> > I don't think that's an accurate interpretation of what's happening in that
> > bug, but would need to see the filesystem to say what is happening.

> You can reproduce it yourself in an i386 chroot.  Make sure you have no
> /usr/lib64 directory, then "ln -s lib /usr/lib64; apt-get install fakeroot".

> > But as the error is "no such file or directory", it probably means
> > it's managed to get itself into a situation of trying to unpack a file
> > for which the parent directory doesn't exist.

> Not at all.  Here is what happens if you install a package that ships
> both foo/x and bar/x while bar is a symlink to foo on the filesystem:
> dpkg unpacks to files with temporary names, foo/x.dpkg-new and
> bar/x.dpkg-new, still not noticing the file conflict and overwriting the
> files with each other.  It then renames foo/x.dpkg-new to foo/x and
> bar/x.dpkg-new to bar/x -- with the last step ENOENT failing, because it
> had already renamed the file to foo/x.

> Run "strace -erename dpkg -i …/fakeroot*.deb" in the above situation to
> see for yourself.

Ahhh, ok.  So it's by accident that this causes a problem for dpkg, because
dpkg has moved its own .dpkg-new out from under itself.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Fri, 19 Aug 2011 00:03:03 GMT) 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>. (Fri, 19 Aug 2011 00:03:03 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: Sven Joachim <svenjoac@gmx.de>
Cc: 632682@bugs.debian.org
Subject: Re: Bug#632682: we should probably remove /lib64 -> lib symlink (with care)
Date: Thu, 18 Aug 2011 17:01:55 -0700
[Message part 1 (text/plain, inline)]
On Thu, Aug 18, 2011 at 09:00:52AM +0200, Sven Joachim wrote:
> On 2011-08-18 01:05 +0200, Steve Langasek wrote:
> >  The right way to handle it is to create the directory under a separate
> > name, populate the symlink, and only *then* rm /lib64 and invoke mv
> > /lib64.real /lib64 via $interpreter.  This minimizes the window when /lib64
> > is missing, and just happens to also remove the inode problem as a side
> > effect (because we create all the directory entries we need before we remove
> > any).

> Yes, that's better.  Instead of hardcoding /lib64.real the directory
> should be created with mktemp -d (I think that's what you meant to do).

I've decided I really don't care for this; I plan to use /lib64.eglibc-old,
/lib64.eglibc-new instead.  If those collide with local directory names,
they can keep both pieces.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Added tag(s) pending. Request was from Steve Langasek <vorlon@alioth.debian.org> to control@bugs.debian.org. (Fri, 19 Aug 2011 05:51:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Fri, 19 Aug 2011 07:45:24 GMT) Full text and rfc822 format available.

Acknowledgement sent to Petr Salinger <Petr.Salinger@seznam.cz>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Fri, 19 Aug 2011 07:45:25 GMT) Full text and rfc822 format available.

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

From: Petr Salinger <Petr.Salinger@seznam.cz>
To: 632682@bugs.debian.org, Steve Langasek <vorlon@debian.org>
Subject: kfreebsd-amd64 and /lib64 -> lib symlink
Date: Fri, 19 Aug 2011 09:46:33 +0200 (CEST)
Hi,

I looked at just commited r4891, and it seems that it breaks 
kfreebsd-amd64 seriously.

On kfreebsd-amd64, the ELF interpreter is "/lib/ld-kfreebsd-x86-64.so.1", 
i.e. it is really in /lib, not in /lib64.

The "lib64 -> lib" symlinks in previous eglibc versions only have been
as defence against broken packages shipping their libs in lib64.

This part of libc.preinst seems to delete our ELF interpreter: 
remove_lib64_symlink() {
...
rm -f /lib/$(basename RTLD_SO)
}

On kfreebsd-amd64 the "lib64 -> lib" symlinks are optional,
but "/lib/ld-kfreebsd-x86-64.so.1" is not ;-)

Petr




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Fri, 19 Aug 2011 08:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Fri, 19 Aug 2011 08:15:03 GMT) Full text and rfc822 format available.

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

From: Sven Joachim <svenjoac@gmx.de>
To: Petr Salinger <Petr.Salinger@seznam.cz>
Cc: 632682@bugs.debian.org, Steve Langasek <vorlon@debian.org>
Subject: Re: Bug#632682: kfreebsd-amd64 and /lib64 -> lib symlink
Date: Fri, 19 Aug 2011 10:12:31 +0200
On 2011-08-19 09:46 +0200, Petr Salinger wrote:

> I looked at just commited r4891, and it seems that it breaks
> kfreebsd-amd64 seriously.
>
> On kfreebsd-amd64, the ELF interpreter is
> "/lib/ld-kfreebsd-x86-64.so.1", i.e. it is really in /lib, not in
> /lib64.
>
> The "lib64 -> lib" symlinks in previous eglibc versions only have been
> as defence against broken packages shipping their libs in lib64.
>
> This part of libc.preinst seems to delete our ELF interpreter:
> remove_lib64_symlink() {
> ...
> rm -f /lib/$(basename RTLD_SO)
> }
>
> On kfreebsd-amd64 the "lib64 -> lib" symlinks are optional,
> but "/lib/ld-kfreebsd-x86-64.so.1" is not ;-)

Right.  I deliberately omitted kfreebsd-amd64 from the list of
architectures where this code is run, but vorlon silently added it.

Cheers,
       Sven




Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Fri, 19 Aug 2011 08:42:07 GMT) 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>. (Fri, 19 Aug 2011 08:42:07 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: Sven Joachim <svenjoac@gmx.de>
Cc: Petr Salinger <Petr.Salinger@seznam.cz>, 632682@bugs.debian.org
Subject: Re: Bug#632682: kfreebsd-amd64 and /lib64 -> lib symlink
Date: Fri, 19 Aug 2011 01:40:03 -0700
[Message part 1 (text/plain, inline)]
On Fri, Aug 19, 2011 at 10:12:31AM +0200, Sven Joachim wrote:
> > I looked at just commited r4891, and it seems that it breaks
> > kfreebsd-amd64 seriously.

> > On kfreebsd-amd64, the ELF interpreter is
> > "/lib/ld-kfreebsd-x86-64.so.1", i.e. it is really in /lib, not in
> > /lib64.

> > The "lib64 -> lib" symlinks in previous eglibc versions only have been
> > as defence against broken packages shipping their libs in lib64.

> > This part of libc.preinst seems to delete our ELF interpreter:
> > remove_lib64_symlink() {
> > ...
> > rm -f /lib/$(basename RTLD_SO)
> > }

> > On kfreebsd-amd64 the "lib64 -> lib" symlinks are optional,
> > but "/lib/ld-kfreebsd-x86-64.so.1" is not ;-)

> Right.  I deliberately omitted kfreebsd-amd64 from the list of
> architectures where this code is run, but vorlon silently added it.

Ah, I had assumed this was an oversight in your patch since it was part of
the bug thread but not included in your patch... i.e., you had silently
dropped it ;)

So we don't want to remove the symlink from /lib or add it to /lib64 on
kfreebsd-amd64, but we do still want to get rid of the symlink itself.  But
since libc won't ship any files in /lib64 on kfreebsd-amd64, we don't need
to do any special symlink handling, dpkg will drop it for us on upgrade.

Fix committed - thanks for catching.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Added indication that bug 632682 blocks 638450 Request was from Sven Joachim <svenjoac@gmx.de> to control@bugs.debian.org. (Fri, 19 Aug 2011 12:20:37 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, GNU Libc Maintainers <debian-glibc@lists.debian.org>:
Bug#632682; Package libc6. (Fri, 19 Aug 2011 12:21:21 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sven Joachim <svenjoac@gmx.de>:
Extra info received and forwarded to list. Copy sent to GNU Libc Maintainers <debian-glibc@lists.debian.org>. (Fri, 19 Aug 2011 12:21:35 GMT) Full text and rfc822 format available.

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

From: Sven Joachim <svenjoac@gmx.de>
To: 632682@bugs.debian.org
Subject: libc6 should have Breaks against lsb-core
Date: Fri, 19 Aug 2011 14:19:24 +0200
On 2011-08-13 21:25 +0200, Sven Joachim wrote:

> - The lsb-core package installs symlinks /lib64/ld-lsb-x86-64.so.[23] to
>   /lib/ld-linux-x86-64.so.2 that get broken.  Nothing dramatic and
>   solvable in a few ways.

Since it has been decided that /lib/ld-linux-x86-64.so.2 goes away, the
lsb-core needs to adjust its postinst and correct the links.  I have
filed a bug (#638450) on lsb-core for that.

As for eglibc, the next upload should add a
"Breaks: lsb-core (<= 3.2-27)" to reflect this, I think.

Cheers,
       Sven




Reply sent to Aurelien Jarno <aurel32@debian.org>:
You have taken responsibility. (Tue, 23 Aug 2011 05:21:08 GMT) Full text and rfc822 format available.

Notification sent to Aurelien Jarno <aurel32@debian.org>:
Bug acknowledged by developer. (Tue, 23 Aug 2011 05:21:08 GMT) Full text and rfc822 format available.

Message #200 received at 632682-close@bugs.debian.org (full text, mbox):

From: Aurelien Jarno <aurel32@debian.org>
To: 632682-close@bugs.debian.org
Subject: Bug#632682: fixed in eglibc 2.13-17
Date: Tue, 23 Aug 2011 05:18:23 +0000
Source: eglibc
Source-Version: 2.13-17

We believe that the bug you reported is fixed in the latest version of
eglibc, which is due to be installed in the Debian FTP archive:

eglibc-source_2.13-17_all.deb
  to main/e/eglibc/eglibc-source_2.13-17_all.deb
eglibc_2.13-17.diff.gz
  to main/e/eglibc/eglibc_2.13-17.diff.gz
eglibc_2.13-17.dsc
  to main/e/eglibc/eglibc_2.13-17.dsc
glibc-doc_2.13-17_all.deb
  to main/e/eglibc/glibc-doc_2.13-17_all.deb
libc-bin_2.13-17_amd64.deb
  to main/e/eglibc/libc-bin_2.13-17_amd64.deb
libc-dev-bin_2.13-17_amd64.deb
  to main/e/eglibc/libc-dev-bin_2.13-17_amd64.deb
libc6-dbg_2.13-17_amd64.deb
  to main/e/eglibc/libc6-dbg_2.13-17_amd64.deb
libc6-dev-i386_2.13-17_amd64.deb
  to main/e/eglibc/libc6-dev-i386_2.13-17_amd64.deb
libc6-dev_2.13-17_amd64.deb
  to main/e/eglibc/libc6-dev_2.13-17_amd64.deb
libc6-i386_2.13-17_amd64.deb
  to main/e/eglibc/libc6-i386_2.13-17_amd64.deb
libc6-pic_2.13-17_amd64.deb
  to main/e/eglibc/libc6-pic_2.13-17_amd64.deb
libc6-prof_2.13-17_amd64.deb
  to main/e/eglibc/libc6-prof_2.13-17_amd64.deb
libc6-udeb_2.13-17_amd64.udeb
  to main/e/eglibc/libc6-udeb_2.13-17_amd64.udeb
libc6_2.13-17_amd64.deb
  to main/e/eglibc/libc6_2.13-17_amd64.deb
libnss-dns-udeb_2.13-17_amd64.udeb
  to main/e/eglibc/libnss-dns-udeb_2.13-17_amd64.udeb
libnss-files-udeb_2.13-17_amd64.udeb
  to main/e/eglibc/libnss-files-udeb_2.13-17_amd64.udeb
locales-all_2.13-17_amd64.deb
  to main/e/eglibc/locales-all_2.13-17_amd64.deb
locales_2.13-17_all.deb
  to main/e/eglibc/locales_2.13-17_all.deb
multiarch-support_2.13-17_amd64.deb
  to main/e/eglibc/multiarch-support_2.13-17_amd64.deb
nscd_2.13-17_amd64.deb
  to main/e/eglibc/nscd_2.13-17_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 632682@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Aurelien Jarno <aurel32@debian.org> (supplier of updated eglibc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Mon, 22 Aug 2011 21:51:07 +0200
Source: eglibc
Binary: libc-bin libc-dev-bin glibc-doc eglibc-source locales locales-all nscd multiarch-support libc6 libc6-dev libc6-dbg libc6-prof libc6-pic libc6-udeb libc6.1 libc6.1-dev libc6.1-dbg libc6.1-prof libc6.1-pic libc6.1-udeb libc0.3 libc0.3-dev libc0.3-dbg libc0.3-prof libc0.3-pic libc0.3-udeb libc0.1 libc0.1-dev libc0.1-dbg libc0.1-prof libc0.1-pic libc0.1-udeb libc6-i386 libc6-dev-i386 libc6-sparc64 libc6-dev-sparc64 libc6-s390 libc6-dev-s390 libc6-s390x libc6-dev-s390x libc6-amd64 libc6-dev-amd64 libc6-powerpc libc6-dev-powerpc libc6-ppc64 libc6-dev-ppc64 libc6-mipsn32 libc6-dev-mipsn32 libc6-mips64 libc6-dev-mips64 libc0.1-i386 libc0.1-dev-i386 libc6-i686 libc6-xen libc0.1-i686 libc0.3-i686 libc0.3-xen libc6.1-alphaev67 libc6-loongson2f libnss-dns-udeb libnss-files-udeb
Architecture: source all amd64
Version: 2.13-17
Distribution: unstable
Urgency: low
Maintainer: Aurelien Jarno <aurel32@debian.org>
Changed-By: Aurelien Jarno <aurel32@debian.org>
Description: 
 eglibc-source - Embedded GNU C Library: sources
 glibc-doc  - Embedded GNU C Library: Documentation
 libc-bin   - Embedded GNU C Library: Binaries
 libc-dev-bin - Embedded GNU C Library: Development binaries
 libc0.1    - Embedded GNU C Library: Shared libraries
 libc0.1-dbg - Embedded GNU C Library: detached debugging symbols
 libc0.1-dev - Embedded GNU C Library: Development Libraries and Header Files
 libc0.1-dev-i386 - Embedded GNU C Library: 32bit development libraries for AMD64
 libc0.1-i386 - Embedded GNU C Library: 32bit shared libraries for AMD64
 libc0.1-i686 - Embedded GNU C Library: Shared libraries [i686 optimized]
 libc0.1-pic - Embedded GNU C Library: PIC archive library
 libc0.1-prof - Embedded GNU C Library: Profiling Libraries
 libc0.1-udeb - Embedded GNU C Library: Shared libraries - udeb (udeb)
 libc0.3    - Embedded GNU C Library: Shared libraries
 libc0.3-dbg - Embedded GNU C Library: detached debugging symbols
 libc0.3-dev - Embedded GNU C Library: Development Libraries and Header Files
 libc0.3-i686 - Embedded GNU C Library: Shared libraries [i686 optimized]
 libc0.3-pic - Embedded GNU C Library: PIC archive library
 libc0.3-prof - Embedded GNU C Library: Profiling Libraries
 libc0.3-udeb - Embedded GNU C Library: Shared libraries - udeb (udeb)
 libc0.3-xen - Embedded GNU C Library: Shared libraries [Xen version]
 libc6      - Embedded GNU C Library: Shared libraries
 libc6-amd64 - Embedded GNU C Library: 64bit Shared libraries for AMD64
 libc6-dbg  - Embedded GNU C Library: detached debugging symbols
 libc6-dev  - Embedded GNU C Library: Development Libraries and Header Files
 libc6-dev-amd64 - Embedded GNU C Library: 64bit Development Libraries for AMD64
 libc6-dev-i386 - Embedded GNU C Library: 32-bit development libraries for AMD64
 libc6-dev-mips64 - Embedded GNU C Library: 64bit Development Libraries for MIPS64
 libc6-dev-mipsn32 - Embedded GNU C Library: n32 Development Libraries for MIPS64
 libc6-dev-powerpc - Embedded GNU C Library: 32bit powerpc development libraries for p
 libc6-dev-ppc64 - Embedded GNU C Library: 64bit Development Libraries for PowerPC64
 libc6-dev-s390 - Embedded GNU C Library: 32bit Development Libraries for IBM zSeri
 libc6-dev-s390x - Embedded GNU C Library: 64bit Development Libraries for IBM zSeri
 libc6-dev-sparc64 - Embedded GNU C Library: 64bit Development Libraries for UltraSPAR
 libc6-i386 - Embedded GNU C Library: 32-bit shared libraries for AMD64
 libc6-i686 - Embedded GNU C Library: Shared libraries [i686 optimized]
 libc6-loongson2f - Embedded GNU C Library: Shared libraries (Loongson 2F optimized)
 libc6-mips64 - Embedded GNU C Library: 64bit Shared libraries for MIPS64
 libc6-mipsn32 - Embedded GNU C Library: n32 Shared libraries for MIPS64
 libc6-pic  - Embedded GNU C Library: PIC archive library
 libc6-powerpc - Embedded GNU C Library: 32bit powerpc shared libraries for ppc64
 libc6-ppc64 - Embedded GNU C Library: 64bit Shared libraries for PowerPC64
 libc6-prof - Embedded GNU C Library: Profiling Libraries
 libc6-s390 - Embedded GNU C Library: 32bit Shared libraries for IBM zSeries
 libc6-s390x - Embedded GNU C Library: 64bit Shared libraries for IBM zSeries
 libc6-sparc64 - Embedded GNU C Library: 64bit Shared libraries for UltraSPARC
 libc6-udeb - Embedded GNU C Library: Shared libraries - udeb (udeb)
 libc6-xen  - Embedded GNU C Library: Shared libraries [Xen version]
 libc6.1    - Embedded GNU C Library: Shared libraries
 libc6.1-alphaev67 - Embedded GNU C Library: Shared libraries (EV67 optimized)
 libc6.1-dbg - Embedded GNU C Library: detached debugging symbols
 libc6.1-dev - Embedded GNU C Library: Development Libraries and Header Files
 libc6.1-pic - Embedded GNU C Library: PIC archive library
 libc6.1-prof - Embedded GNU C Library: Profiling Libraries
 libc6.1-udeb - Embedded GNU C Library: Shared libraries - udeb (udeb)
 libnss-dns-udeb - Embedded GNU C Library: NSS helper for DNS - udeb (udeb)
 libnss-files-udeb - Embedded GNU C Library: NSS helper for files - udeb (udeb)
 locales    - Embedded GNU C Library: National Language (locale) data [support]
 locales-all - Embedded GNU C Library: Precompiled locale data
 multiarch-support - Transitional package to ensure multiarch compatibility
 nscd       - Embedded GNU C Library: Name Service Cache Daemon
Closes: 537743 617759 632682 636694 637239 637767 638173
Changes: 
 eglibc (2.13-17) unstable; urgency=low
 .
   [ Aurelien Jarno ]
   * Improve libc.NEWS to also include headers.
   * Add debian/patches/cvs-dlopen-tls.diff to fix handling of static TLS in
     dlopen'ed objects.  Closes: #637239.
   * Provide locales in locales-all as separated files instead of adding them
     to locale-archive. Use symlinks between identical files to limit the
     unpacked size.  Closes: #537743, #636694, #638173.
   * Compress libc*-dbg and locales-all to using xz.
   * Add patches/localedata/cvs-rupee.diff from upstream to add support for
     Rupee symbol (U20B9).
   * Add patches/sparc/cvs-rlimits.diff from upstream to fix issues with
     rlimits on sparc.  Closes: #637767.
   * Add patches/amd64/cvs-pthread-stack-alignment.diff from upstream to fix
     stack alignment issues on amd64.
   * Add patches/s390/cvs-vsyscalls.diff from upstream to fix wrong register
     usage in the INTERNAL_VSYSCALL_NCS macro.
   * Add patches/arm/cvs-clone-cantunwind.diff from upstream to fix unwinding
     issues with openjdk on armhf.
   * Add patches arm/cvs-align-constant-pool.diff from upstream to fix
     alignement issues on armhf.
   * debian/control.in/libc: add Breaks: lsb-core (<= 3.2-27) to make sure the
     lsb symlink is still valid.
   * Remove patches/any/cvs-dl-missing-deps.diff, the original problem has
     been solved through other ways, so it is not needed any more. Fixes
     symbols resolution with issues with icedove/iceweasel/iceape.  Closes:
     #617759.
 .
   [ Samuel Thibault ]
   * debian/patches/hurd-i386/submitted-ioctl-unsigned-size_t.diff: Add
     u?int{8,16,32,64} ioctl types.
   * debian/patches/hurd-i386/submitted-init-first.diff: Fix stack switching
     compilation with newer gcc.
 .
   [ Steve Langasek ]
   * Install ld*.so to RTLDDIR (/lib64 or /lib), as appropriate, and convert
     /lib64 from a symlink to a directory on upgrade (with appropriate
     downgrade and error-unwind handling), so that multiarch and biarch
     packages will play nicely together on the filesystem..  Thanks to
     Sven Joachim <svenjoac@gmx.de> for preliminary patches.  Closes: #632682.
   * Restore multiarch support on all architectures.
   * Bump the multiarch-support minimum dependency for armhf, which settled
     its triplet only at the time i386 did.
 .
   [ Petr Salinger ]
   * kfreebsd/local-sysdeps.diff: update to revision 3689 (from glibc-bsd).
Checksums-Sha1: 
 c4a1d8992d9e385a8e44e76c7ea58fb8ab961d31 2637 eglibc_2.13-17.dsc
 2db91f7ff108357cf1ed8a7088389c953940ac16 930177 eglibc_2.13-17.diff.gz
 451c6abbcc470003128f4d935b0cc1f18974b305 1886882 glibc-doc_2.13-17_all.deb
 df799f1242bedf8477e95e1d36df1974cb2de4d1 12221666 eglibc-source_2.13-17_all.deb
 e0ecaca8fe7321b394c1a6bc220e42a1bdcc1542 4857284 locales_2.13-17_all.deb
 556162bb516245e4427e3cfa7e6f35a4c0a1b587 4323692 libc6_2.13-17_amd64.deb
 4267c57ec96ad6a8fcfc8e708fe61e56b1f4f638 2636686 libc6-dev_2.13-17_amd64.deb
 685cf8c3c9e4706874d4b2f11048f83854119a6c 2077956 libc6-prof_2.13-17_amd64.deb
 3c8b0d3b48396b4786d4685d59499e406ac69f17 1584092 libc6-pic_2.13-17_amd64.deb
 4c4f96eac93c355283210f9371711348f102bf08 1085010 libc-bin_2.13-17_amd64.deb
 7a6a44e548938fad307086798a92bdd72d896ab3 216680 libc-dev-bin_2.13-17_amd64.deb
 be3b4b1b98b7d7a269b15cc287eb8d16f88ecc47 3273952 locales-all_2.13-17_amd64.deb
 3b5ddf303779b2bb0786e65c026a140346b90166 140478 multiarch-support_2.13-17_amd64.deb
 553c47da473c4cf04df7d6c563c83a420b34785a 3845754 libc6-i386_2.13-17_amd64.deb
 00e7f40df13dd8110d8fd8a06edb5ce158be08bb 1561580 libc6-dev-i386_2.13-17_amd64.deb
 1f9d8b2a3c68ca43a88d86244c9a123d69709b9f 203798 nscd_2.13-17_amd64.deb
 45dc4d7137efe2f67b90d027ddf712a96dcba18a 5685714 libc6-dbg_2.13-17_amd64.deb
 270a724ea0c5262e80ce6cedee7047d2d7c244ab 1179704 libc6-udeb_2.13-17_amd64.udeb
 fa42d6da5b18caa1bfed046cf0babf034c4bb00e 11144 libnss-dns-udeb_2.13-17_amd64.udeb
 75698b85d1d38d7805f9d156cc628c2cf219c7f9 19318 libnss-files-udeb_2.13-17_amd64.udeb
Checksums-Sha256: 
 08d82a115eae9a77e5dd0b454e0a246503294868271251fb1735c67ff90a42d1 2637 eglibc_2.13-17.dsc
 1e1ba3af4267b67cc9f476f3431e134da68dc0ae0170684112be5817a3bceb7c 930177 eglibc_2.13-17.diff.gz
 c0cd43e0d13ec95607d0fc41d0e02d6c8714fa1d9e5d1510b03b7afe036ac872 1886882 glibc-doc_2.13-17_all.deb
 629c8ca8aa40777355ad8d0df183c631ee97cb9da842a2cfd286890c3f7c2c04 12221666 eglibc-source_2.13-17_all.deb
 ea910bbace6e8a6c28f1e92b5d1a4e64c16f7101d5e6770aa269a3257828f8fa 4857284 locales_2.13-17_all.deb
 b2629d4d4f834eac9ef282754e1b93e6c5d2749d9fc49f001fe6f89140928875 4323692 libc6_2.13-17_amd64.deb
 0fcffd1b0ac020a1f51452f7aa646cc3e8151aba3fa9971f4924c376a1d0d24d 2636686 libc6-dev_2.13-17_amd64.deb
 ad35ff902edb17f12ae01f79252dce836da97e8672a9c1bd775bce094a227fcc 2077956 libc6-prof_2.13-17_amd64.deb
 54b164b0ed896cf593bf794f4a4eb9b55d346a63b510291f909165df1244343f 1584092 libc6-pic_2.13-17_amd64.deb
 da6ce577f7f3d8d290b47de1c7290deccfb322e7c4a0dc993a4b3905818c870a 1085010 libc-bin_2.13-17_amd64.deb
 b0b0419a0f421bb74c7231b96f240f4109796c596792214b2f6193024c60b495 216680 libc-dev-bin_2.13-17_amd64.deb
 80bf72ed28f83767bb9c6dcb998114e97162e88a4becf874f289327c9915ae1e 3273952 locales-all_2.13-17_amd64.deb
 2b803f896a5a9db62310e4d7142b19a8f2e1e4647c0a60afad8fd5612f09fa68 140478 multiarch-support_2.13-17_amd64.deb
 3c4b93843a015ad0c0ae923629f649b3473da56e07c0c9dcf458e4ae93de3a8b 3845754 libc6-i386_2.13-17_amd64.deb
 80f18cef14451e36fc895d1c607f15b911a824ecd320e8ddfe98b52b854ea7a8 1561580 libc6-dev-i386_2.13-17_amd64.deb
 c3e93de0863115091afeeebc8c708425afa56e2ec4b7b45deed7e7cb82e886d1 203798 nscd_2.13-17_amd64.deb
 4934685aab6c9642e15119ee813353d4024bc5d3de91793029b73b48990261cd 5685714 libc6-dbg_2.13-17_amd64.deb
 61254f98f632d4cbf63535285103cec23733a367f25c02e97658b4ea070859ae 1179704 libc6-udeb_2.13-17_amd64.udeb
 907170bca35c4bafbff0b09cc7d7e65e697862a30146ce4a19ade721361d2c5f 11144 libnss-dns-udeb_2.13-17_amd64.udeb
 da12b514afce054c70e2cbbc0a328fe6d369efd3a2ab3b567e758e7b459fa254 19318 libnss-files-udeb_2.13-17_amd64.udeb
Files: 
 256b7845041050bf616bae3f217ff2df 2637 libs required eglibc_2.13-17.dsc
 b3420807e5f9f6bd909f514191477048 930177 libs required eglibc_2.13-17.diff.gz
 36331a70d3e98eb1604632ccf702a677 1886882 doc optional glibc-doc_2.13-17_all.deb
 65a2bfdc8d21eef7af3db4f911a6ef0f 12221666 devel optional eglibc-source_2.13-17_all.deb
 7053b6a953fadae6ec4febf9c02c571d 4857284 localization standard locales_2.13-17_all.deb
 1e364b076f9f8fee01beb8a74788e61f 4323692 libs required libc6_2.13-17_amd64.deb
 334f299f9c835643f38549e99ff3227f 2636686 libdevel optional libc6-dev_2.13-17_amd64.deb
 c542c42dba51cc0bc5c4a8b2a70cf936 2077956 libdevel extra libc6-prof_2.13-17_amd64.deb
 ab48be1ace945c53e1ea3b1f87224338 1584092 libdevel optional libc6-pic_2.13-17_amd64.deb
 ddb862660d9eeb4b3ce5700e858c80ea 1085010 libs required libc-bin_2.13-17_amd64.deb
 6ec273eb9424e5b85ae1e8159efb12eb 216680 libdevel optional libc-dev-bin_2.13-17_amd64.deb
 eefb90caefad51ccb3066a2f957887fe 3273952 localization extra locales-all_2.13-17_amd64.deb
 15807ec10ca9b2af29be86c46fc2289b 140478 libs standard multiarch-support_2.13-17_amd64.deb
 203673141ce646ec3d05b40cffe1cddd 3845754 libs optional libc6-i386_2.13-17_amd64.deb
 b61fc0e31bf13c8770fda33aad598905 1561580 libdevel optional libc6-dev-i386_2.13-17_amd64.deb
 9a914a3fb18630924f83d4d3dd406fdc 203798 admin optional nscd_2.13-17_amd64.deb
 2e72c06006c5a97622df800f7aac5aca 5685714 debug extra libc6-dbg_2.13-17_amd64.deb
 835b23efad2d98950195e6697ae4867a 1179704 debian-installer extra libc6-udeb_2.13-17_amd64.udeb
 4d4a65dc15ae67c82e66cf915adaaf88 11144 debian-installer extra libnss-dns-udeb_2.13-17_amd64.udeb
 b356020210086a767b771c4ccbcf6c91 19318 debian-installer extra libnss-files-udeb_2.13-17_amd64.udeb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iD8DBQFOUy5Uw3ao2vG823MRAp8xAJwIRspeFnn59ddd3dHKQqj9v8zIpwCeIyvq
l3kceuwoyABjZIudYge1RRM=
=+vUx
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Wed, 21 Sep 2011 07:36:19 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: Thu Apr 17 07:34:47 2014; Machine Name: beach.debian.org

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