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

Ciaran McCreesh ciaran.mccreesh at googlemail.com
Sat Feb 18 21:00:11 UTC 2012

On Sat, 18 Feb 2012 05:11:06 +0000 (UTC)
Alex Elsayed <eternaleye at gmail.com> wrote:
> The current layout of a directory under CONFIG_PROTECT is somewhat
> less than ideal. An update to a protected directory results in
> ._cfg0000_.* files strewn throughout, with no information as to their
> origin.

Well... Their origin should just be "cave owner" on the unprotected
file, shouldn't it?

> This is how I imagine the new layout might look:
> /etc/
>     .config-protect/
>         new/
>         old/
>         resolved/

I'm slightly confused by your directory layout here. Let's say
that /var/foo is also protected. Would that live in /var/foo/.c-p
or /etc/.c-p/var/foo?

I'm in favour of the latter, incidentally. It's an utter pain in the
ass having to know that one package added /lib/blah to C_P, since we
have to scan through exndbam for every package to see where C_P things
might live.

> Note that the package manager will *never* merge directly to a
> CONFIG_PROTECT directory, even if there is no preexisting file.

That's unworkable. Say foo deps upon bar, and bar needs /etc stuff
present to work. You'd not be able to install foo and bar as part of
the same resolution then.

> When the user next runs 'eclectic config', it will scan
> /etc/.config-protect/new/ to see what action needs to be taken. This
> should be a considerable performance improvement over the old system -
> while still O(n), now n is 'the files that need updates' rather than
> 'all files in /etc.'

Don't think performance is an issue. Let's focus on functionality first.

> However, in order to support configuration management properly, we
> cannot have the user altering the original files in the course of
> managing these updates. Therefore, when the user would perform an
> action that could modify the original file, the original file is
> instead copied to the 'old' directory and the action is performed on
> the copy.

That sounds like it's getting in the way of the user. Supporting
complex things is good, but we shouldn't force it upon people who don't
want to screw around with configuration management.

Ciaran McCreesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.exherbo.org/pipermail/exherbo-dev/attachments/20120218/5acb31fb/attachment.asc>

More information about the Exherbo-dev mailing list