Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian dpkg (http://www.linux-archive.org/debian-dpkg/)
-   -   Storing additional metadata in the dpkg database (http://www.linux-archive.org/debian-dpkg/710625-storing-additional-metadata-dpkg-database.html)

Michael Biebl 10-08-2012 08:02 PM

Storing additional metadata in the dpkg database
 
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).

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 like ucf config files or even ressources like
system users and groups.



Cheers,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Michael Biebl 10-08-2012 08:02 PM

Storing additional metadata in the dpkg database
 
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).

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 like ucf config files or even ressources like
system users and groups.



Cheers,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Guillem Jover 10-08-2012 08:53 PM

Storing additional metadata in the dpkg database
 
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


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121008205332.GA13558@gaara.hadrons.org">http://lists.debian.org/20121008205332.GA13558@gaara.hadrons.org

Guillem Jover 10-08-2012 08:53 PM

Storing additional metadata in the dpkg database
 
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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121008205332.GA13558@gaara.hadrons.org">http://lists.debian.org/20121008205332.GA13558@gaara.hadrons.org

Michael Biebl 10-10-2012 03:44 AM

Storing additional metadata in the dpkg database
 
Hi guillem!

On 08.10.2012 22:53, Guillem Jover wrote:
>
> On Mon, 2012-10-08 at 22:02:57 +0200, Michael Biebl wrote:
>> On 08.10.2012 20:15, Michael Gilbert wrote:

>> 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

Interesting question regarding generated files and md5sums. Maybe it
would be best to simply not store md5sums for such externally registered
files/directories.

> worse might cause security issues if they are world writable (like
> /var/lock, as Jakub has pointed out).

Well, my idea was not, that dpkg should actually create that file/dir,
but simply that it tracks the information that such a file/dir is
created by the package. Where do you see the security risk wrt dpkg?


>> 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.

Interesting. Can you say a bit more about that, how this is going to
work. If you register an external configuration file with dpkg, will
dpkg take care of removing it on purge or does that still need to be
done by the package itself?

>> or even ressources like system users and groups.
>
> I'm not entirely sure what you mean with this though, maybe something
> like #685734?

Not quite, although #685734 sounds like an interesting idea. I'm
basically just interested in having a central database where packages
can register which ressources they are using, so I can easily query it
later on, e.g. which package created and/or uses a specific system user.

Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Michael Biebl 10-10-2012 03:44 AM

Storing additional metadata in the dpkg database
 
Hi guillem!

On 08.10.2012 22:53, Guillem Jover wrote:
>
> On Mon, 2012-10-08 at 22:02:57 +0200, Michael Biebl wrote:
>> On 08.10.2012 20:15, Michael Gilbert wrote:

>> 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

Interesting question regarding generated files and md5sums. Maybe it
would be best to simply not store md5sums for such externally registered
files/directories.

> worse might cause security issues if they are world writable (like
> /var/lock, as Jakub has pointed out).

Well, my idea was not, that dpkg should actually create that file/dir,
but simply that it tracks the information that such a file/dir is
created by the package. Where do you see the security risk wrt dpkg?


>> 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.

Interesting. Can you say a bit more about that, how this is going to
work. If you register an external configuration file with dpkg, will
dpkg take care of removing it on purge or does that still need to be
done by the package itself?

>> or even ressources like system users and groups.
>
> I'm not entirely sure what you mean with this though, maybe something
> like #685734?

Not quite, although #685734 sounds like an interesting idea. I'm
basically just interested in having a central database where packages
can register which ressources they are using, so I can easily query it
later on, e.g. which package created and/or uses a specific system user.

Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


All times are GMT. The time now is 01:30 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.