Bug#306677: libc6: /lib64 goes away on upgrade, breaks amd64

[Matt Taggart <taggart@debian.org>]

Package: libc6
Version: 2.3.2.ds1-21
Severity: critical
Justification: causes amd64 systems to become completely unusable
  upon dist-upgrade

A person I know ran into a critical bug on amd64 today. He was apt-get 
dist-upgrading his system things broke horribly,

...
Get:171 http://debian-amd64.alioth.debian.org sid/main telnet-ssl 
0.17.24+0.1-7.1 [88.1kB]
Fetched 105MB in 2m42s (649kB/s)                                               

Preconfiguring packages ...
(Reading database ... 24453 files and directories currently installed.)
Preparing to replace base-files 3.1.1.0.0.1.pure64 (using 
.../base-files_3.1.2-0.0.1_amd64.deb) ...
Unpacking replacement base-files ...
dpkg (subprocess): failed to exec rm for cleanup: No such file or directory
dpkg: error while cleaning up:
 subprocess rm cleanup returned error exit status 2
Could not exec dpkg!
E: Sub-process /usr/bin/dpkg returned an error code (100)

and after that the existing shell was still working, but nothing would run, 
always complaining "no such file or directory". dannf was able to figure out 
that the /lib64 -> /lib symlink got deleted. All debian binary-amd64 binaries 
have /lib64 in their hardcoded PI like this,

  $ strings /bin/ls |head -1
  /lib64/ld-linux-x86-64.so.2

So that's why everything was complaining "no such file or directory". We were 
able to replace the symlink using the PI directly,

   /lib/ld-linux-x86-64.so.2 ln -s /lib64 /lib

and then all things were back to normal.

I started looking around for how this could have happened. Both libc6 and 
lsb-core provide /lib64. Looking at the lsb-core changelog,

  lsb (2.0-2) experimental; urgency=low
  ...
    * Include /lib64 in the AMD64 package rather than running mkdir in the
        postinst.
  ...
   -- Chris Lawrence <lawrencc@debian.org>  Mon, 20 Sep 2004 21:38:36 -0500

So lsb-core's old mkdir method was ensuring that that symlink got created and 
stuck around. Once the package moved to delivering it as a normal file it can 
be missing during an upgrade. So....

I'm speculating that in this case all the packages that provide /lib64 were 
providing it as a package file and being upgraded in the same pass. This 
caused /lib64 to go away and everything to blow up. Does that sound correct?

I propose that libc6 is the correct package to ensure that /lib64 gets created 
and exists across upgrades. Even if we do move to multiarch, /lib64 is going 
to need to stick around for a very long time. If at some point in the distant 
future we can finally get rid of it, whatever libc package we're using at that 
point can check for it and remove it in a package script.

-- 
Matt Taggart
taggart@debian.org