Joey Hess wrote: > > 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. > > Seems like a per-package or dhelp bug.
Yes, I also think that these are not debhelper bugs (hence the severity wishlist for this report). I supposed a more general problem behind these things because some kinds of the same problems happen every now and then. > > 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. Again "Yes". These were just some examples I found. I thought, that debhelper might be changed to remedy such problems. Besides, the bugs can be very subtle, see e.g. http://bugs.debian.org/46576 install-docs -r was run correctly, but a forgotten reference in the NEW menu file kept .dhelp. > > 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. So maybe, just like dpkg, debhelper could output a warning if it doesn't/ cannot create the link? At least for a certain period of time, till the migration is finished. I think this would even help package maintainers to find the bug when they test their packages. Ulf
