[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


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: