Bug#632682: we should probably remove /lib64 -> lib symlink (with care)
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
Reply to: