On Wed, Jul 11, 2012 at 11:41:59PM +0200, Sven Joachim wrote: > On 2012-07-11 22:57 +0200, Bart Martens wrote: > > > Please have a look at this scenario : > > > > apt-get -y -t stable install tcl-dev > > apt-get -y -t stable install tk-tile > > apt-get -y -t unstable install tcl-dev > > > > The first and second commands succeed. The third command fails with this : > > > > Unpacking replacement tcl-dev ... > > dpkg: error processing /var/cache/apt/archives/tcl-dev_8.5.0-2_all.deb > > (--unpack): > > trying to overwrite '/usr/include/tcl', which is also in package tk-tile > > 0.8.2-2.1 > > Preparing to replace tcl 8.4.16-2 (using > > .../archives/tcl_8.5.0-2_all.deb) ... > > update-alternatives: using /usr/bin/tclsh8.4 to provide /usr/bin/tclsh > > (tclsh) in auto mode > > Unpacking replacement tcl ... > > Errors were encountered while processing: > > /var/cache/apt/archives/tcl-dev_8.5.0-2_all.deb > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > So dpkg has initially installed /usr/include/tcl as a symbolic link, next > > dpkg > > has tolerated the installation of tk-tile owning /usr/include/tcl as a > > directory, and finally dpkg fails to upgrade the symbolic link because > > tk-tile > > owns /usr/include/tcl as a directory. > > That's not actually an accurate description; dpkg has no way of knowing > which of the packages tcl-dev/stable and tk-tile, if any, ships > /usr/include/tcl as a directory. The dpkg database just includes a list > of files for each package, not their type.
This information is available at the time dpkg tries to install the packages. dpkg -c /var/cache/apt/archives/tcl-dev_8.5.0-2_all.deb | grep /usr/include/tcl dpkg -c /var/cache/apt/archives/tk-tile_0.8.2-2.2_amd64.deb | grep /usr/include/tcl/$ lrwxrwxrwx root/root 0 2011-02-06 14:30 ./usr/include/tcl -> tcl8.5 drwxr-xr-x root/root 0 2012-05-10 01:45 ./usr/include/tcl/ > > > Obviously dpkg should successfully upgrade the symbolic link. > > And break the packages co-owning it? This is not allowed unless you > specify --force-overwrite. While directories are a shared resource, > symlinks to directories are not, unless they all point to the _same_ > directory. And since tcl-dev/unstable wants to change the target of the > symlink, the file conflict arises. My point is that the real file conflict should be caught when dpkg tries to install tk-tile, not when dpkg tries to upgrade the symbolic link. > > > The solution is, in my opinion, that dpkg fails to install the package > > owning > > /usr/include/tcl as a directory when /usr/include/tcl is already installed > > as a > > symbolic link. Then there is no problem with upgrading the symbolic link. > > But it breaks if the symbolic link has been installed by the sysadmin > rather than by a package. I understand now about symbolic links added by the sysadmin as local changes, and about the choice made in the past that dpkg follows those symbolic links as mentioned in debian-policy. However, dpkg can see the difference between those locally added symbolic links and symbolic links owned by installed packages. The solution is, in my opinion, that dpkg fails to install the package owning /usr/include/tcl as a directory when /usr/include/tcl is already installed as a symbolic link owned by an already installed package. Then there is no problem with upgrading the symbolic link. > > > But I'm still interested to know more about "changing it would break quite a > > few things", see earlier on the bug report. > > Did you receive my earlier mail <[email protected]> ? I haven't saved the message-id's but I have now read all messages that are logged on the bug report. I think that I have fully understood everything written so far. The phrase "changing it would break quite a few things" was about the part from debian-policy you quoted. That is clear now. Do you see other things break when dpkg would be modified to fail to install a package owning a directory that is already a symbolic link owned by an already installed package ? Same question for the reverse scenario : do you see other things break when dpkg would be modified to fail to install a package owning a symbolic link that is already a directory owned by an already installed package ? Regards, Bart Martens -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
