Re: RFC: new approach to handling conffiles
sean finney writes ("RFC: new approach to handling conffiles"):
> hey dpkg peeps,
Thanks, this is very interesting.
> i spoke with a couple folks on irc about the idea of keeping the
> "dist" version of conffiles on-disk somehow, and the general
> consensus was that it seemed like a good idea but noone had the time
> to push it out of a todo list. keeping the dist version of the
> conffiles gives the ability to do things like old->new dist version
> diffing, as well the coveted 3-way diff/merge.
Right.
> so, this past weekend i had a couple of 12-hour train rides and thus
> some time to kill, and threw together a proof of concept for your
> perusal. basically, every package has a subdirectory
> <admindir>/conffiles/<pkg><ext> (where <ext> is one of
> "","_dpkg-new","_dpkg-old"), under which its conffiles are stored.
> currently the subdirectory contains nested subdirectories reflecting
> the on-disk location of the real-file
> (i.e. <conffdbdir>/<pkg>/etc/foo.cfg), but other approaches are also
> possible such as using <conffdbdir>/<pkg>/<cksum>, where <cksum> is
> the md5sum of the on-disk location (/etc/foo.cfg).
I'm not wholly convinced that this deep directory structure is ideal.
Deep directory structures are slow, cumbersome to program to
manipulate, and prone to corner case problems.
I would prefer either encoding the filename somehow (although we
perhaps shouldn't expect that every conffile pathname will fit in a
leaf component in /var/lib/dpkg) or your suggesting of using the
md5sum.
Why do you have _dpkg-new, _dpkg-old, etc. ? Surely all that's needed
is the file from the currently-installed version of the package -
strictly, the file corresponding to the md5sum in the conffiles
field ?
> anyway, this version doesn't do anything apart from extract/update/purge the
> conffiles into this db, but the relatively small amount of code/changes
> required to do this and a well modularized implementation should make it
> clear that it wouldn't be too hard to start tacking features on top of it.
I haven't looked at the code yet; I'd like to discuss the behavioural
specification a bit more before delving in. But thanks for providing
the references.
> oh, i also found two rather minor memory leaks, which are fixed in the first
> commit of that branch.
Could you please submit a separate bug report about that, either with
a patch, or with a reference to a specific git commit ?
Ian.
Reply to: