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