On Fri, May 11, 2012 at 11:53:34AM +0100, Steve McIntyre wrote: > Jean-Christophe Dubacq wrote: > > > >If dpkg kept a copy of the original configuration file (to be retrieved > >at all times), it would be easier to spot local changes. > >I use etckeeper to do that, but it's a bit tiresome to isolate all local > >changes (I have to save the diffs somewhere) (and a lost hope if you do > >install etckeeper late in the workstation life). My git-fu is probably > >not good enough (I am probably looking for a "pristine" branch and a > >rebased "local" branch used in production). > > You might be interested in a proposal at UDS this week: > > https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles
I'm unconvinced that this would be workable. How many programs and configuration files reference absolute paths under /etc? Which wouldn't be overridable using the proposed mechanism. Is this going to concern itself only with init.d scripts or all conffiles? Bind mounting the prinstine copy over the broken copy is probably the safest way--it keeps all the paths consistent, though you'd lose /all/ configuration if you bind over the whole /etc rather than just parts of it. A unionfs overlay might also be an option, then the /etc-only files can show through; but all these are still far too fragile for my liking. I would much rather we had a more general mechanism of storing the real configuration files (as opposed to just md5s) by dpkg itself, which would enable proper merging of admin changes between old and new conffiles, and perhaps also allow dpkg to implement ucf-like conffile handling (or remove the need for ucf entirely). These could be stored under /var/lib/dpkg/conffiles (for example). For the "pristine" initscripts use case, it would be possible to mirror a subset under /lib or /etc. But how often does anyone make their system unbootable even with the most extreme init script hacking? We already have rescue boot CDs etc. to cater for this eventuality in any case--why introduce a pile of complexity into the system when it's already redundant? On a related note... While we might criticise rpm for its bad conffile handling, dpkg is itself fairly woeful, and if we change one thing for wheezy+1, it should be sane conffile handling. dpkg should never "forget" about conffiles; the fact that maintainer scripts have to take care of purging such files is a glaring defect, and possibly the source of the greatest fragility in our maintainer scripts--it's impossible for maintainer scripts to get this right all the time given all the corner cases like downgrades and being taken over by other packages. If this was implemented robustly, the maintainer script should never need to concern itself with such cleanup, or indeed any manual work with conffiles at all, except maybe for deletion ahead of purge where this is needed. And given the frequency this is needed, a defined mechanism to do this would be useful. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120511124132.gn23...@codelibre.net