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

debhelper: /usr/doc problems again

Package:  debhelper
Version:  N/A
Severity: wishlist

(I'm not sure, if this is the right form to handle this, but I
 didn't know better. Sorry, if this might not be okay)


 I'd like to mention some general problems with packages migrating
 from /usr/doc to /usr/share/doc. Some of these problems exist,
 although they are very hard to explain and/or to reproduce.
 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.
 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.
 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).

 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?
 'ln -snf' (no dereference) might help for wrong links.
 Currently, dh_installdocs does nothing with the link, if a file,
 directory or another (even wrong) link exists. Do we "support"
 user changes to directories in /usr/doc? If not, it should be safe
 to delete old directories in preinst or so.



Reply to: