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

Alex Elsayed eternaleye at gmail.com
Mon Feb 27 01:48:55 UTC 2012


Having had some time to think, I have a few refinements to my
proposal.

Firstly, a small change to the directory structure I proposed.

All config-protect goes ubnder one directory, /etc/.config-protect.
Within that are the following directories:

new/
old/
resolved/
protected/
historic/

new, old, and resolved are as in my previous proposal. However,
'protected' and 'historic' are new.

'protected' exists to act as a registry of what is currently
config-protected. If /etc and /var/cfg are protected, but
/etc/.config-protect is config-protect-masked, then it will contain:

etc.protect
etc/.config-protect.mask
var/
  cfg.protect

A .protect or .mask entry will contain a newline separated list of
(timestamp, packageid) tuples with the two elements separated by a
space, corresponding to the packages that added those paths to
config-protect or config-protect-mask.

'historic' exists to provide for three-way-merges. When in the
previous version of my proposal the 'new' entry would be deleted when
the changes are committed, now that entry is moved to 'historic'. On
creating a resolution, a three-way merge can be done between the
user's file (the one in the config-protected path), the previous
upstream (historic) and the new one.

Also, since Ciaran pointed out that never merging directly even if
there is no previous file is unworkable, I'd like to suggest that the
package manager merges to /etc/.config-protect/new and creates a
symlink to *that* file in the protected directory in such a case, so
that it is trivial for eclectic config to detect such files and
automerge them.

Thoughts?




More information about the Exherbo-dev mailing list