On Wed, 13 Sep 2006 19:47:12 +0200, Benno Schulenberg <[EMAIL PROTECTED]> 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
