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 1QRpvb-0000Tx-7b for garchives@archives.gentoo.org; Wed, 01 Jun 2011 18:13:59 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 925981C09D; Wed, 1 Jun 2011 18:10:24 +0000 (UTC) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 3BE581C09D for ; Wed, 1 Jun 2011 18:10:23 +0000 (UTC) Received: by bwg12 with SMTP id 12so388789bwg.40 for ; Wed, 01 Jun 2011 11:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:from:to:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type; bh=4D4qvW1QV6mdndDPLle7dfZljqJ/mNCialk4PSZq0NY=; b=PMU/wsBBDBTECZd0iMqSndLCxgZep67E9GQ+3dJIXokJ6G8GmaaKl2G2rFmjZpnx6w T8LwNjhZWOQYbdh26vcI/x6KYI+BtzR2PZV+hg38ETE5nZgP/UwytUKOMpv+OWpipeeY P9vGkUsxDrh9s0rOKiws2YE/OY4TFto3Eo/xI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:message-id:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:content-type; b=C9YP7sDFPDA9se6tbvP1CE/10yLCv4FMnppRkY63tAChle4ujqOeui8eUJXGRE74xU 2HrFHgRjUXduM8Tk/y62PkCgKus+WD683PW8YMPZckNVejImrrTUK4o76dneZgweUggA uhEGJ9DHNF5tmwZSNUewwb/X2VOWIc4g/FZOA= Received: by 10.204.47.103 with SMTP id m39mr379666bkf.4.1306951823394; Wed, 01 Jun 2011 11:10:23 -0700 (PDT) Received: from localhost.localnet (p4FC7469C.dip0.t-ipconnect.de [79.199.70.156]) by mx.google.com with ESMTPS id ek1sm1034755bkb.21.2011.06.01.11.10.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2011 11:10:21 -0700 (PDT) From: Volker Armin Hemmann To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Cleaning redundant configuration files Date: Wed, 01 Jun 2011 20:10:19 +0200 Message-ID: <5494053.NRLbeOI46p@localhost> User-Agent: KMail/4.6 rc1 (Linux/2.6.39; KDE/4.6.3; x86_64; ; ) In-Reply-To: <20110601155758.3f197397@karnak.local> References: <20110601155758.3f197397@karnak.local> 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-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Archives-Salt: X-Archives-Hash: 34001f77d90bbb01a0c69d761ccb01a3 On Wednesday 01 June 2011 15:57:58 David W Noon wrote: > On Wed, 01 Jun 2011 01:20:02 +0200, Neil Bothwick wrote about Re: > > [gentoo-user] Cleaning redundant configuration files: > >On Tue, 31 May 2011 17:26:43 +0100, David W Noon wrote: > I'll trim my earlier quote down to the salient statement. > > >> >> It > >> >> removes files that are still in the same state as when the > >> >> package was emerged, but not those modified by the user. > >> > > >> >It doesn't remove *any* files that have been modified, > >> > >> Erm ... that's what I wrote, above. > > > >No it's not. You were referring to a special case of the general > >statement I made. > > I can see no material difference in the two statements in question, > unless you mean "by the user" is a special case. By whom else would > files be modified externally to Portage? > > [snip] > > >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. > > Yes, that is the way Portage currently works. But ... > > The contents of the file have been modified, but the file itself is > still owned by the package. That's why etc-update, cfg-update, etc., > check any new version of the file when the package is upgraded: the > file is still owned by the package. > > So, when the package is to be removed, the file should also be removed > if the user has set an option so to do. > > The place where the current logic could be considered valid is when the > file is an executable. If an executable has been modified outside of > Portage then it is likely the user has installed a foreign package or a > home grown program. One could argue that it is not the place of > Portage to remove these. > > >> 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. > > How much is that investment worth when the entire package is being > deleted? Remember: we are discussing the COMPLETE DELETION of a > package, not an upgrade or rebuild. > > [snip] > > >We agree on the usefulness of a purge-like option but not on the > >desirability or otherwise of the current default behaviour > > I called it an "annoyance". Having to clean up obsolete configuration > files is just that, unless you can offer a better term. so - what happens when you uninstall a package to cleanly install it again? Happens from time to time - and I seriously would not want to see the carefully personalized config file be moved to the big blue electron pool in heaven.