Re: Silly Packaging Problem
On Thu August 10 2006 13:13, martin f krafft wrote:
> also sprach Bruce Sass <email@example.com> [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
an infrastructure which operates at package build and install time,
requiring packages and all helpers to be re-engineered to make use
of the feature
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
Adding a directory appears to be something which could be useful (even
if only as a shorthand notation), 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).
 "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
 `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
 "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