hiya, 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 implementation. 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. sean
Attachment:
signature.asc
Description: This is a digitally signed message part.