Re: debhelper: /usr/doc problems again
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
Reply to: