Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection

[Thomas de Grenier de Latour <degrenier@easyconnect.fr>]

On Wed, 13 Sep 2006 19:47:12 +0200,
Benno Schulenberg <benno.schulenberg@gmail.com> wrote:

> I would much prefer new files to be treated as if replacing an 
> existing zero length file. 
...
> it should be up to tools like etc-update to (configurably) automerge
> new files

A quick look through my CONFIG_PROTECTed directories shows that, on a
total of ~1000 config files installed by ebuilds, only ~60 may have
affected my system when they were new and have been unconditionnaly
installed.  With such a false-positive rate, i would probably have soon
disabled the etc-update paranoid mode you propose, and i think most
users would have done the same.

I think that protection against harmfull new config files should be
selective to be useful.  It should only affect directories from which
files are blindly sourced by some services you are already running.
There, and only there¹, new config files are unexpected change of your 
existing configuration, and thus lead to unexpected behaviors.

 ¹ Well, ok, that's not exactly true. There is also the case of config
files being moved (a program expecting /etc/foo.conf in one version,
and /etc/foo/foo.conf in the later), things like that.  But imho, in
such cases, documentation (postinst messages, or GLEP 42) is enough,
whereas an anti-new-files-protection wouldn't really help.

The directories i'm thinking of are all this /etc/*.d/: "acpi.d",
"logrotate.d", "pam.d", etc.  There, adding a new file is really
just like appending a new chunk to an existing config file.

Implementation of a special anti-new-file-protection for this critical
directories could be done in at least two ways:
 - a global NEW_CONFIG_PROTECT variable (but i don't think it's would be
a good idea, too hard to maintain given the number of packages / devs
which would have a path to add to the list),
 - an ebuild-specific variable, which would be taken into account by the
contents merging function of the package manager (sure, this variable
should be accessible through aux_get() or alike, ie. not bash-level
only, but part of the ebuild metadatas).


But anyway, sorry for the off-topic Ciaran, i realize that this
discussion is far from being comments on the specs you've written.

--
TGL.
-- 
gentoo-dev@gentoo.org mailing list