From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1QRY9n-0000Zk-4E for garchives@archives.gentoo.org; Tue, 31 May 2011 23:15:27 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C33161C02E; Tue, 31 May 2011 23:14:06 +0000 (UTC) Received: from mail.digimed.co.uk (82-69-83-178.dsl.in-addr.zen.co.uk [82.69.83.178]) by pigeon.gentoo.org (Postfix) with ESMTP id 643051C02E for ; Tue, 31 May 2011 23:14:06 +0000 (UTC) Received: from digimed.co.uk (yooden.digimed.co.uk [192.168.1.6]) by mail.digimed.co.uk (Postfix) with ESMTPSA id 8122980440 for ; Wed, 1 Jun 2011 00:14:05 +0100 (BST) Date: Wed, 1 Jun 2011 00:14:04 +0100 From: Neil Bothwick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Cleaning redundant configuration files Message-ID: <20110601001404.0d88f259@digimed.co.uk> In-Reply-To: <20110531172643.6526f19f@karnak.local> References: <20110531172643.6526f19f@karnak.local> Organization: Digital Media Production X-Mailer: Claws Mail 3.7.9cvs24 (GTK+ 2.24.3; x86_64-pc-linux-gnu) X-GPG-Fingerprint: 7260 0F33 97EC 2F1E 7667 FE37 BA6E 1A97 4375 1903 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Qt7eVtj5+HFijepF4n8B3q."; protocol="application/pgp-signature" X-Archives-Salt: X-Archives-Hash: 7ec4a14b262873b354c95bcec8faebc8 --Sig_/Qt7eVtj5+HFijepF4n8B3q. Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 31 May 2011 17:26:43 +0100, David W Noon wrote: > >> You have just touched on an annoyance of unmerge, in that it does not > >> clean up configuration files that have been modified. It removes > >> files that are still in the same state as when the package was > >> emerged, but not those modified by the user. I don't see how user > >> changes make the file more important than would be in its vanilla > >> state. > > > >It doesn't remove *any* files that have been modified, >=20 > Erm ... that's what I wrote, above.=20 No it's not. You were referring to a special case of the general statement I made. > [That is, of course, predicated on > the assumption that installing Package A will not modify configuration > files owned by Package B, and vice-versa: all post-installation > modifications are performed by the user.] That is valid, provide collision-protect is included in FEATURES. > >the reasons > >systems used to get cluttered with orphaned .la files. The logic is > >quite simple, if it is not the file portage installed with the > >package, it should not be uninstalled with the package. >=20 > Why should that be so? It's quite simple logic, whether or not you agree with it. If a file is modified, it is no longer the file portage installed, so portage does not uninstall it. If anything, the problem is that the logic used by portage is too simple. > To repeat myself: I do not see a customized configuration file as being > any more important than a vanilla one. A customised file contains an investment of the user's time, a generic file does not. That investment may be small or great, but it is not for portage to determine that value and remove the file without the user's consent. > I should be clear here: a reinstall means "from new, with no previous > version currently installed" and is quite distinct from an upgrade or > rebuild. Not as distinct as you may think. Portage updates a package by first installing the new version then unmerging the old one. As it uses checksums and timestamps to determine ownership of a file, this is safe as it will not remove files from the new version that overwrote identically-named files from the old package. > >There are > >times when some sort of --force-remove option to remove both these and > >files in CONFIG_PROTECTed directories would be useful. >=20 > Again, what I wrote. >=20 > I think we largely agree on this issue. We agree on the usefulness of a purge-like option but not on the desirability or otherwise of the current default behaviour --=20 Neil Bothwick A friend in need may turn out to be a nuisance. --Sig_/Qt7eVtj5+HFijepF4n8B3q. Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk3ldjwACgkQum4al0N1GQPn6gCdFFD9b6v6B7NCmOmBliTyvVhk h6EAoLAUh9LcX8fKtYd8RCb/0lsZD/bg =uKaQ -----END PGP SIGNATURE----- --Sig_/Qt7eVtj5+HFijepF4n8B3q.--