Re: Silly Packaging Problem
On Thu August 10 2006 13:13, martin f krafft wrote:
> also sprach Bruce Sass <bmsass@shaw.ca> [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
Reply to: