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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
