From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1GNwxJ-0005yg-In for garchives@archives.gentoo.org; Thu, 14 Sep 2006 19:33:01 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.6) with SMTP id k8EJWYOl010856; Thu, 14 Sep 2006 19:32:34 GMT Received: from smtp3.mail.easynet.fr (smarthost177.mail.easynet.fr [212.180.1.177]) by robin.gentoo.org (8.13.8/8.13.6) with ESMTP id k8EJUSFS017396 for ; Thu, 14 Sep 2006 19:30:28 GMT Received: from easyconnect2121138-64.clients.easynet.fr ([212.11.38.64] helo=eusebe) by smtp3.mail.easynet.fr with esmtp (Exim 4.62) (envelope-from ) id 1GNwul-00000Z-AW for gentoo-dev@lists.gentoo.org; Thu, 14 Sep 2006 21:30:23 +0200 Date: Thu, 14 Sep 2006 21:30:43 +0200 From: Thomas de Grenier de Latour To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection Message-ID: <20060914213043.3bebb26e@eusebe> In-Reply-To: <200609131947.13027.benno.schulenberg@gmail.com> References: <20060911232211.2cb55425@snowdrop.home> <200609131947.13027.benno.schulenberg@gmail.com> Organization: Fasmz X-Mailer: Sylpheed-Claws 2.4.0 (GTK+ 2.8.20; i686-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id k8EJWYQZ010856 X-Archives-Salt: 9e2be13e-7b98-43f9-a0bd-0334580166e2 X-Archives-Hash: 87d6bb8a34e6747c787e00ee738052fa On Wed, 13 Sep 2006 19:47:12 +0200, Benno Schulenberg wrote: > I would much prefer new files to be treated as if replacing an=20 > existing zero length file.=20 ... > 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=C2=B9, new config files are unexpected change of yo= ur=20 existing configuration, and thus lead to unexpected behaviors. =C2=B9 Well, ok, that's not exactly true. There is also the case of conf= ig 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. --=20 gentoo-dev@gentoo.org mailing list