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