Ulf Jaenicke-Roessler <[EMAIL PROTECTED]> wrote: > 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.
Well the solution in both of these cases is to file a bug. Download the source file, modify it so that it works, removing .dhelp files, and moving all files to the /usr/share/doc/<package> directory. Then produce a patch from your modified version, include it as a patch in the bug report. Offer to do a NMU if the maintainer is not avaliable. > 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). Download the source, fix the problem, file a patch as a bug report. > 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? No, there is no reason to do this. If the package is written properly it is unneeded. > 'ln -snf' (no dereference) might help for wrong links. Why make wrong links? Surely if the package is correct there is no need for this. > 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. If a system adminitrator has put a file in the /usr/doc/<package> do we have any right to remove it? I do not think we do. When you start including rm -rf commands in package postinst that run as root, then you are just asking for trouble. -- I consume, therefore I am
