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?
Attachment:
signature.asc
Description: OpenPGP digital signature