On Thu August 10 2006 13:13, martin f krafft wrote: > also sprach Bruce Sass <[EMAIL PROTECTED]> [2006.08.10.1959 +0100]: > > Such a utility would need to be shipped with dpkg, a 3rd party or > > random DD implementing it would be silly for anything but local > > consumption. > > > > Is that the only problem? > > If dpkg knew how to track files it did not directly install, of > course it would be of benefit. The question is how to let it know > which files are meant by this. I suppose DEBIAN/conffiles-(files > installed to /etc by the package) would work, but I'd be careful > about touching the "conffile" concept. Maybe DEBIAN/dynfiles -- > since after all it (sh|w)ould be used for things like logfiles as > well. And it should be able to just take a directory, like > /var/lib/dpkg, assuming that everything underneath that directory > would be created by one package, dpkg in this case.
I would expect usefulness with most generated files (all, if one thinks that every file resulting from a pkg install should be "dpkg -S"-able). It may also be useful to create local virtual packages for stuff like "papersize" if there is no good package to append them to. An "update-package" command, run at install time by the maintainer's scripts right after file generation succeeds, would head off potential problems with synchronization that are outside of the Maintainer's control (e.g., DEBIAN/dynfiles containing incorrectly generated paths) and would be simpler to implement, specifically, dynfiles vs. "update-package": an infrastructure which operates at package build and install time, requiring packages and all helpers to be re-engineered[1] to make use of the feature vs. a command which knows how to append a file to a package and can be added to any package's scripts with a line or two of minor code, only depends on dpkg's external stability to continue to work, and whose behaviour could be controlled from a single point[2] Adding a directory appears to be something which could be useful (even if only as a shorthand notation[3]), but I don't think it could be done without touching dpkg internals and a big chunk of the tools (recognizing that a directories contents are owned by a pkg is new). - Bruce [1] "re-engineered"... maybe a bit dramatic and overstated, but unless there is a way to pick the generated paths out of the existing maintainer scripts the conversion would require re-thinking and re-doing existing work, afaict [2] `single point control'... seems to be an important characteristic given the Python transition's recent problems with the various tools being out of sync wrt an evolving policy [3] "if only as..." if the typical <package>.list file is less than the size of a typical disk block then there could be an additional processing overhead for no gain in the typical case, that would suck -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]