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

Re: PROPOSAL: Extrafiles (was Re: Conffiles...)



Christian Schwarz <schwarz@monet.m.isar.de> 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. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>


--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: