On Thu, Aug 18, 2011 at 08:25:14PM +0200, Sven Joachim wrote: > >> > 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. Ahhh, ok. So it's by accident that this causes a problem for dpkg, because dpkg has moved its own .dpkg-new out from under itself. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature