[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg, symlinks, directories


Vincent Bernat has written on Saturday, 29 September, at 17:31:
> ❦ 29 septembre 2012 17:17 CEST, "Andrej N. Gritsenko" <andrej@rep.kiev.ua> :

>>>This is indeed intentional, that dpkg never replaces directories with
>>>symlinks if directory is present, see [1] and [2] (under 4.).
>>> [1]: http://bugs.debian.org/404850 
>>> [2]: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase

>>>Andreas Beckmann recently is filling many of these bugs discovered by
>>>piuparts runs (updating Squeeze -> Wheezy). Most common approach there
>>>is to do the substitution in postinst, in case the directory is there.
>>>See for example [3].

>>     I supposedly not much understand how dpkg does this but my question
>> is - isn't it simpler to delete directory in preinst? The install then
>> can install the symlink in the place. Right? Redo every symlink install
>> in postinst seems kinda dirty for me as it duplicates package creation
>> steps at the time of install and may create invalid symlinks sometime.

>In my case, this is quite complicated. I have done all this to allow a
>user to install its own plugin in /var/lib/roundcube/plugins but if he
>did install some plugins in /usr/share/roundcube/plugins because of the
>symlink problem, I would erase them. Moreover, there are another package
>that could install plugins in /usr/share/roundcube/plugins. This is
>really tricky. :(

    I have another case - the libfm 1.0.2 introduced a little versioning
of library so instead of /usr/include/libfm directory (in libfm <= 1.0.1)
there is a directory /usr/include/libfm-1.0 with relevant headers and a
symlink /usr/include/libfm -> libfm-1.0 which conflicts with directory
that is left empty after old package deletion. I've solved that in the
preinst script by 'rm -rf /usr/include/libfm' and I thought yet that was
a right step since upgrade 1.0.1 -> 1.0.2 went smooth.

    WBR, Andriy.

Reply to: