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

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.


> 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

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 ?


Reply to: