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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
