[Exherbo-dev] [RFC] A new approach to CONFIG_PROTECT

Dan Callaghan djc at djc.id.au
Sun Feb 19 21:55:54 UTC 2012


Excerpts from Ciaran McCreesh's message of Mon Feb 20 07:01:14 +1000 2012:
> Perhaps a better question to ask is something like "how would we 
> design config protection if it didn't already exist?". From the 
> package mangler side there's probably not much difference here between 
> having a choice of two mechanisms, or having one mechanism that's 
> heavily parameterised.

I had an idea a while back for replacing CONFIG_PROTECT. (I was inspired 
by etckeeper, and the mess that CONFIG_PROTECT makes of it.) Instead of 
merging a package's files under /etc to the filesystem, you commit them 
to their own branch of a git repo (so one branch per package, which gets 
updated when the package is updated). Your master branch is made up by 
merging in all of these "pristine" package branches, and the real /etc 
is a checkout of that.

A whole bunch of useful operations then become easy with git. You can 
see what changed in an upgrade using git log. You can make git do all 
(or most) of the hard work when merging in upgraded config files. 
`eclectic config list` just becomes an operation on the git repo to find 
all pristine package branches which are not fully merged into master.

I hacked up a Paludis merger hook to do this, which mostly worked -- the 
biggest problem I ran into was CONFIG_PROTECT_MASK. It seems there's 
a lot of packages which don't work if they can't overwrite certain 
config files during their upgrade. /etc/env.d seemed to be the main 
culprit. (I would argue that the env.d stuff belongs outside of /etc 
since it's apparently not real configuration. Maybe with just an option 
to override it in /etc, the way systemd lets you do?)

There's also a lot of packages which just don't work if their config 
files are completely absent. The way around this would probably be to 
have the package manager try to merge the pristine package branch into 
master after an upgrade. It would abort if the merge isn't clean, but 
presumably the first merge for a new package would always go through 
cleanly.

It would also be tied to git, which some might say is a downside (I 
don't).

-- 
Dan Callaghan <djc at djc.id.au>



More information about the Exherbo-dev mailing list