Christian Schwarz <[EMAIL PROTECTED]> writes: > On 17 Apr 1998, Adam P. Harris wrote: > No, that's not the point. (Please correct me if I'm wrong again.) If a > package does not provide a .dhelp file itself, doc-base will create this > file automatically. Only doc-base knows about that file, and if everything > is working correctly, doc-base will remove that file again if the package > is removed. > > However, if you purge doc-base now, it will not remove that file (at > least, the latest version of doc-base I wrote would behave that way). With > that, the user would end up with a /usr/doc/foo/.dhelp file of which noone > knows about. If the foo package is removed now, dpkg will complain about > /usr/doc/foo being not empty.
Christian, I believe your analysis is correct, although I can't say I've tested it very well. Furthermore, I believe that this behavior is extremely suboptimal. OTOH, I also believe that this problem in particular is the fault of a flaw in the design of dhelp (no fault on the dhelp designer; hopefully the new Debian Documentation policy will provide the data in such a way that such files are not necessary.) I guess I'm not sure what you're proposing, w.r.t. the extrafiles proposed policy. Say our scenario is that based on variables in the local system's state, some little file may be created somewhere. Futhermore, we would like this file to be cleaned up when the package is purged. So therefore, the extrafiles mechanism would come into play: at time of the extra file create, the file would be registered as an 'extrafile'; removing that file would be handled automatically by dpkg on 'purge' of the owning package. Is this how the extrafiles mechanism as proposed is meant for and how it would work? Are we stipulating that a file cannot appear as an extrafile in more than one package's extrafiles list? Is there any method, or reason for, a local sysadmin to override this behavior? .....A. P. [EMAIL PROTECTED]<URL:http://www.onShore.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
