Package: dhelp Version: 0.3.13 Adam Heath wrote: > Setting up libapache-mod-jserv (1.0-2) ... > ln: /usr/doc//libapache-mod-jserv: cannot overwrite directory > dpkg: error processing libapache-mod-jserv (--configure): > # ls /usr/doc//libapache-mod-jserv -a > . .. .dhelp > > Maybe these files should NOT be created in /usr/doc, but in a cache/lib > dir of some kind. With this dynamic .dhelp file in place, dpkg didn't remove > > the dir, so creating the symlink fails. > > Or, pkgs doing the symlink thing need to deregister themselves in the preinst.
Hm, packages that use doc-base are supposed to call install-docs -r in their prerm. Presumably, this will de-register them from dhelp and remove the .dhelp file. Similarly, dhelp's own docs say: In <tt>prerm</tt> you should use:<P> <BLOCKQUOTE><PRE> if [ -f /usr/sbin/dhelp_parse ]; then /usr/sbin/dhelp_parse -d /usr/share/doc/directory fi </PRE></BLOCKQUOTE><P> But it looks like libapache-mod-jserv does this -- so why are the .dhelp files still left behind? Bug in dhelp? Some experimentation: [EMAIL PROTECTED]:/usr/doc>dhelp_parse -d /usr/sbin/dhelp_parse -d /usr/doc/apt/dhelp dhelp_parse: You can add only directories under /usr/share/doc! [EMAIL PROTECTED]:/usr/doc>ls -l apt/.dhelp -rw-r--r-- 1 root root 549 Feb 15 1999 apt/.dhelp Well well. So if you had an old prrm that followed what dhelp said to do and tried to remove the .dhelp files, and you use the current dhelp, it'll just fail like that. If dhelp were halfway intelligent, it would continue to let you at lease remove .dhelp files in /usr/doc. I think this is bug against dhelp. -- see shy jo
