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

Re: RFC: new approach to handling conffiles


On Tuesday 04 March 2008 10:15:18 pm Ian Jackson wrote:
> > 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'm not wholly convinced either.  but since i didn't want to dirty my hands 
with some mundane minutiae, as well as overly complicate the initial proof of 
concept, i went with this approach for starters.  funny enough i'd say 
the "mkdir -p" code is still probably the most complicated part of the 

i think most of the corner-case scenarios are equally likely with any other 
implementation (since there's a "database-per-package" which is kept 
logically separate for new/cur/old versions as well, see below), but i agree 
it does seem less efficient, and there's the 
not-quite-real-but-we-should-care-on-principle risk of exceeding PATH_MAX.

> 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.

i think the md5sum of the filename would be ideal in such a case, because (a) 
it's almost cryptgraphically guaranteed to be unique (i'd be impressed to 
find a collision within PATH_MAX starting with /etc, anyway:), and (b) 
there's already md5sum code in dpkg so it involves less new code.  

basically such an approach would involve losing the ugly mkdir -p stuff and 
adding some equally ugly code (or perhaps uglier, depending on whether you 
already have some re-usable helper functions for some of the i/o available)  
for reading/writing index files. 

> 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 ?

because the conffiles are extracted and "handled" at seperate times from what 
i can tell (i.e. unpack vs. configure).  and during the "handling" time 
(where differences are found and admin is prompted) you need all of the "old" 
(i.e. current dist) "current" (i.e. actual) and "new dist" versions 
available.  for the sake of simplicity as well as reducing various error 
scenarios, i keep all these versions logically separated in different 
directories using a slightly munged version of some stuff i found in #defines 
in dpkg.h (comments explain the munging), and  after installation is complete 
only the "new dist" versions remain in the conffile db (now as "current 
dist"), and the rest are rm -rf'd away.

> > 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 ?

sure.  patch (as well as the others mentioned in my original mail) is now 
posted to the ML via git-send-email as well.  if no-one takes the patch with 
the small memory fixes by tomorrow i'll forward the same patch to the BTS.


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: