Configuration file handling (was: RFC: OpenRC as Init System for Debian)
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
Reply to: