On 2008-10-12 16:19 +0200, Torsten Werner wrote:
> Package: dpkg
> Version: 1.14.22
> Followup-For: Bug #406715
>
> Hi,
>
> the same problem happens, when a directory is replaced by a symlink
> during the upgrade of a package. I am attaching 2 versions of the
> testpackage tp to illustrate the problem. Version 1 ships the file
> /usr/lib/tp/tp.cfg and the directory /usr/lib/tp/log. Version 2 moves
> tp.cfg to /etc and the directory to /var/log/tp and ships appropriate
> symlinks in /usr/lib/tp/. After the installation of version 1 we have:
>
> $ ls -l /usr/lib/tp
> insgesamt 4
> drwxr-xr-x 2 twerner twerner 4096 12. Okt 15:51 log
> -rw-r--r-- 1 twerner twerner 0 12. Okt 15:51 tp.cfg
>
> After the upgrade to version 2 we have:
>
> $ ls -l /usr/lib/tp
> insgesamt 4
> drwxr-xr-x 2 twerner twerner 4096 12. Okt 15:51 log
> lrwxrwxrwx 1 twerner twerner 11 12. Okt 16:00 tp.cfg -> /etc/tp.cfg
>
> After the installation of version 2 on a fresh system we have the
> correct symlink:
>
> $ ls -l /usr/lib/tp
> insgesamt 0
> lrwxrwxrwx 1 twerner twerner 11 12. Okt 16:00 log -> /var/log/tp
> lrwxrwxrwx 1 twerner twerner 11 12. Okt 16:00 tp.cfg -> /etc/tp.cfg
>
> The maintainer of tp can handle that problem via preinst
No, he can't. At least not in a sane way, i.e. without removing all
files under /usr/lib/tp and breaking the rollback that usually happens
if unpacking the new version of the package fails. This has to be done
in the postinst, when there should be no files left in the directory.
Only the inverse conversion (symlink -> directory) can be done (has to
be done, actually) in preinst scripts.
> but it is
> difficult to spot because dpkg does not fail during the upgrade (no
> warning either). Because I have seen RC bugs because of this (#468954) I
> will increase the severity of this bug to important. IMHO dpkg should
> fail is such cases with a useful error message.
And how are you going to turn a directory into a symlink, then? Also,
there are certainly systems where the local administrator has turned a
standard directory, say /usr/share, into a symlink for one reason or the
other. Certainly such setups should not suddenly break, should they?
I guess this bug is "wontfix"; however, the procedures how to convert a
directory into a symlink and vice versa should be better documented, as
I couldn't find anything about this topic in the Policy Manual,
Developer Reference or New Maintainer Guide.
Cheers,
Sven
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
