Ulf Jaenicke-Roessler wrote: > Package: debhelper > Version: N/A > Severity: wishlist
> For example, I found that libpanel-applet0 leaves a single file > in its old doc directory (currently unexplainable and unreproducable > by the maintainer) preventing the compatibility link to be created. Seems like a per-package bug. > Another example is the latest 'time' package, which doesn't delete > the old doc directory on upgrade because of a .dhelp file, resulting > in no compatibility link too. Seems like a per-package or dhelp bug. > Some packages (bibtool, cpio, rxvt or even perl-5.005-*) on at least > two of the machines I maintain, had links to /usr/share/doc/package > (from /usr/doc/package), i.e. not to ../share/doc/package (absolute > instead of relative). None of these packages use debhelper to handle this. > The question is, should the migration, for packages which want to > do it at all, be enforced? I.e., should the old doc directory be > deleted (rm -rf) before dh_installdocs tries to create the link? I do not want debhelper to do this, because it can lead to data loss. If the admin has installed something there, I don't want to delete it. This exactly parallells dpkg's behavior if the last file it knows about is removed from a directory and yet other files still remain there. -- see shy jo
