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

Re: "register" files in dpkg database programmatically? (was Re: How Debian Deals with Data)

On Sat, Jul 16, 2011 at 08:32:46PM +0100, Christopher Baines wrote:
> On Sat, 2011-07-16 at 17:12 +0200, Paul Wise wrote:
> > On Sat, Jul 16, 2011 at 4:48 PM, Peter Samuelson wrote:
> > 
> > > It would be useful in any number of situations to be able
> > > to "register" a file with dpkg: tell dpkg that a given package owns a
> > > given file, so that it is automatically removed when the package is
> > > removed or upgraded.  I can see this being used in many postinst
> > > scripts, so as to simplify or eliminate the corresponding postrm.
> > 
> > I have wanted this for a long time and would use it in
> > clamav-unofficial-sigs if it were available. I'd want both registering
> > and unregistering, since clamav-unofficial-sigs might need to remove
> > some files. It would be used at both runtime and in maintainer
> > scripts.
> So a control file would do for this, I think packages should only be
> able to register/unregister files from there own package, packages they
> Replace, or files that are do not belong to any package. Otherwise this
> feature could be abused. 

If you have a control file, then this feature is not needed.  Before
a file is registered, it doesn't belong to any package, so I'm not
sure what your point is there.

This concept fills a gap which the current facilities do not cater
for.  It could be abused of course, but that's not really a reason
not to provide it.  All our tools can be used incorrectly in the
wrong hands.

If my package e.g. generates some files in its postinst, these won't
belong to the package manifest.  This means I'll have to remember to
remove them in the postrm.  But this is really error prone and
dangerous: I might stop generating it in a future version, but I
still need to retain the logic.  It might be provided by another
package, which could cause the postrm to break unrelated software.
By registering the file as I create it, I completely avoid the
breakage potential of complex and poorly-tested postrm logic--it's
completely removed.  It also means that other packages can't
arbitrarily overwrite it.  It would certainly be very useful for
e.g. generated files in /var which currently require special
handling in postrm.

Obvious this could cause problems if not coordinated between packages,
but it certainly serves a needed purpose and has the potential to
improve our maintainer scripts greatly.


  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment: signature.asc
Description: Digital signature

Reply to: