On Sun, 2006-12-31 at 02:15 +0000, Ben Hutchings wrote: > Debian bug #404733 shows a case where installation of a package fails > because it contains a symbolic link with the same path as a directory > included in an installed package. I think this is the expected > behaviour. However, installation of this package worked for me in a > similar situation, and presumably has for other users. Has there been > any deliberate change in dpkg that would explain why this does work in > some cases or versions?
I've now found the following comment in processarc.c: * For each file, we check to see if it already exists. * There are several possibilities: * + We are trying to install a non-directory ... [...] * - It is a directory. In this case it depends on whether we're * trying to install a symlink or something else. [...] * = If we are trying to install a symlink we do nothing - ie, * dpkg will never replace a directory tree with a symlink. This * is to avoid embarrassing effects such as replacing a directory * tree with a link to a link to the original directory tree. I can't follow the logic of the following code, so I'll have to take this on trust. However, if someone who's worked on dpkg could confirm that symbolic links whose paths match existing directories are intentionally ignored, that would be very much appreciated. (Does it make any difference whether the symbolic link was in the previously installed package?) The comment is present in sarge and the current version, so it looks like we can rely on this working during an upgrade from sarge. The error message in the bug report is a translation of "trying to overwrite `%.250s', which is also in package %.250s" which appears to indicate that totem-mozilla installed something other than a directory (perhaps another symbolic link?) at /usr/lib/firefox. Is this the only possible reason for that message? Ben. -- Ben Hutchings A free society is one where it is safe to be unpopular. - Adlai Stevenson
signature.asc
Description: This is a digitally signed message part
