On 2012-07-12 07:25 +0200, Bart Martens wrote:
> On Wed, Jul 11, 2012 at 11:41:59PM +0200, Sven Joachim wrote:
>>
>> 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.
But it is not stored in the database, so the information is only
available for the package dpkg currently tries to install.
> 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/
The second and third line should be transposed here, I suppose? Anyway,
at the time dpkg installs tcl-dev 8.5.0-2, it cannot know that tk-tile
had wanted to install /usr/include/tcl as a directory.
>> > 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.
As I said, this breaks existing systems, possibly up to the point where
they might not be able to unpack any package at all.
> 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.
No, it cannot. When the sysadmin creates a symlink (say, /foo) to a
directory and a package which ships /foo as an empty directory is
installed later, the outcome is identical to what it would have been if
said package had shipped /foo as a symlink in the first place.
> 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.
You would also have to forbid it if it's a symlink on the system not
owned by any package, otherwise your next sentence...
> Then there is no problem with upgrading the symbolic link.
...would not actually be true.
> 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 ?
I suppose the /run transition would have been quite a bit harder then,
since it would have involved Conflicts with every package that ships a
/var/run directory.
> 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 ?
Again the /var/run transition; plus it is potentially much harder to
work around in preinst scripts (you may have to rm -rf whole directory
trees rather than just a symlink).
Cheers,
Sven
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
