Re: Bug#36972: dpkg: dpkg can remoev vital files/symlinks without warning adminitrator
Steve Lamb writes:
> Package: dpkg
> Version: 184.108.40.206
> Severity: Critical
> While updating listar from .118a to .121a dpkg removed symlinks which
> were vital for listar to operate. This is because the maintainer had
> changed how his configuration worked and did not warn the administrator in
> the upgrade that a major change was forthcoming.
Must this be rehashed AGAIN... For those that don't know, Lamb has
been bugging me about this for some time.
Let me explain the situation and why dpkg is NOT at fault.
In Listar 0.119a, the upstream package acquired new capabilities for
specifying pathnames for files in its configuration files. This means
that the mess of symlinks previously required were no longer
necessary. A small change in /etc/listar/listar.cfg (a listed
conffile) makes those symlinks unnecessary.
Steve ignored dpkg's prompts about /etc/listar/listar.cfg when he
upgraded his listar package. He then claimed that the symlinks should
not have disappeared; that I ought to keep them in the .deb ad
naseum. He complained that the symlink disappearance caused his
server to break. However, others upgraded the package successfully,
and despite removing the symlinks in the .deb, managed to make it work
by properly updating their config files as dpkg asked.
Therefore, I believe that this is not a bug in dpkg, much less a
critical one, and can be summarily closed. dpkg did exactly what it
was supposed to. Furthermore, if the admin is prompted everytime a
file moves, is renamed, or disappears, people will never be able to
get their upgrades done.
I did not change how the configuration worked; there was a minor
change to listar.cfg. dpkg did warn the administrator about the
change; there was no need for me to duplicate that. He simply ignored
the warnings. Those symlinks were not "vital for listar to operate"
after the upgrade.
The assumption that the maintainer is not using the
files/links/directories is correct if they are no longer present in
the .deb. If they were present before, and no longer are, then
obviously they are not to be used any longer and *should* be unlinked.