Re: Storing additional metadata in the dpkg database [Re: possible mass bug filing for packages shipping stuff in /var/run, /var/lock, /run?]

[Guillem Jover <guillem@debian.org>]

Hi!

On Mon, 2012-10-08 at 22:02:57 +0200, Michael Biebl wrote:
> On 08.10.2012 20:15, Michael Gilbert wrote:
> > On Mon, Oct 8, 2012 at 6:33 AM, Thomas Goirand wrote:
> >> "Packages must not include files or directories under /run,
> >> or under the older /var/run and /var/lock paths."
> > 
> > The thing is that it really does no harm if a package actually does
> > this; although it is pretty pointless since those files will be gone
> 
> I actually find it pretty handy if I can use dpkg -S to find out which
> package a particular directory belongs to.
> So shipping the directory in the package does have some value (at least
> for me).

That applies as well to any path generated at maintainer script or
run time by the package (like state, cache, log files, etc), but I
don't think it's currently a good idea for these to belong in the
dpkg database, as either the files' md5sums might change over time,
or the paths might appear and disappear if they are on a ramfs, or
worse might cause security issues if they are world writable (like
/var/lock, as Jakub has pointed out).

> aba rightfully pointed out, that having a mechanism in dpkg which allows
> one to register such a directory in the dpkg database dynamically, might
> be an even better approach.
> 
> Such a mechanism could not only be used to register such volatile
> files/directories in (/var)/run or /lock but files that are generated by
> the maintainer scripts

Sure, and that's been on the dpkg TODO list for a while, but it needs
first for its database to be extended to track additional metadata. I
was planning on working on this for 1.17.x anyway.

> like ucf config files

This will be covered instead by extending the dpkg conffile support to
allow to register external configuration files.

> or even ressources like system users and groups.

I'm not entirely sure what you mean with this though, maybe something
like #685734?

thanks,
guillem