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 1QSDNo-0005D5-7b for garchives@archives.gentoo.org; Thu, 02 Jun 2011 19:16:40 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 454CE1C244; Thu, 2 Jun 2011 19:14:56 +0000 (UTC) Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) by pigeon.gentoo.org (Postfix) with ESMTP id CC6E21C253 for ; Thu, 2 Jun 2011 19:14:55 +0000 (UTC) Received: by wyi11 with SMTP id 11so1225043wyi.40 for ; Thu, 02 Jun 2011 12:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:user-agent:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=FRuUQsznhlenZM4NEXPcc6IdHspsvbGKpFRltqWiOPg=; b=V3OAAnKLY3Qo25ff831sWmHRr0ge/60RJqhzZj+XSqYGOQxYMvCJmi8jqaJ7+PsjMW y7/a4iB45YNOtn6DFdPhSkYcEPl6M6pbflRiAF7txsC8vo+v0K/pR9JwpVWoMDuonMMQ egO6gzlsoUYUW8q5WUPKD+iIPqJoPEHocMke4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; b=hZ+FYIZo3j/VRz1zJnlriEEo1eSwjAiNq3e+lSkKiUJBSfK39hzTO4LRy7K+tYXtHh nYGlI2pQSFhu+uvedhbzSox6SFsmJyI7/b7zptUEc3J+DFFQWRNHCmqJXnEZa0VW6Dvm VaaURqRU+wQbAz+ASzWADlKdTlLrD1kbTKrnc= Received: by 10.216.229.195 with SMTP id h45mr6605553weq.48.1307042094974; Thu, 02 Jun 2011 12:14:54 -0700 (PDT) Received: from nazgul.localnet (196-215-91-253.dynamic.isadsl.co.za [196.215.91.253]) by mx.google.com with ESMTPS id m8sm572534wbh.11.2011.06.02.12.14.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2011 12:14:53 -0700 (PDT) From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Cleaning redundant configuration files Date: Thu, 2 Jun 2011 21:08:11 +0200 User-Agent: KMail/1.13.7 (Linux/2.6.39-ck; KDE/4.6.3; x86_64; ; ) References: <20110602172644.108239bc@karnak.local> In-Reply-To: <20110602172644.108239bc@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-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201106022108.11864.alan.mckinnon@gmail.com> X-Archives-Salt: X-Archives-Hash: ad140688d4a2c4c45c29d63ab486ed3e Apparently, though unproven, at 18:26 on Thursday 02 June 2011, David W Noon did opine thusly: > On Thu, 02 Jun 2011 01:10:02 +0200, Alan McKinnon wrote about Re: > > [gentoo-user] Cleaning redundant configuration files: > >Apparently, though unproven, at 17:52 on Wednesday 01 June 2011, David > > > >W Noon did opine thusly: > >> On Wed, 01 Jun 2011 17:20:03 +0200, Alan McKinnon wrote about Re: > [snip] > > >> >Your suggestion runs counter to the general philosophy that runs > >> >through Gentoo. > >> > >> In what way? Since it would be an option, it would not diminish the > >> control the user has over the machine. > > > >If you can provide solid examples where standard Gentoo tools do this > >operation: > > > >"I don't know what this is, but I'm just going to delete/modify/change > >it anyway" > > My issue is with your "I don't know what this is," application. > > Portage knows exactly what a given configuration file is, as the > package still owns the file. The way it detects that the file has been > customized is that the MD5 checksum and/or file size differ from that > stored in the package manifest. Please look a little deeper and try to understand what I am saying, your response is bordering closely on being a strawman. When I used the word "this", I meant the file itself, it's contents and all known metadata about the file. Which is a lot more information than the mere existence of the file itself. > > As an example, here is the manifest for sys-apps/mlocate: [snip file list] > [For those who don't know, this file is > named /var/db/pkg/sys-apps/mlocate/CONTENTS. All packages have a > CONTENTS file, as that is how Portage keeps track of file ownership by > packages.] > > Now, nearly everybody modifies /etc/updatedb.conf. This does not > remove that name from mlocate's manifest. So, Portage knows precisely > to which package the file belongs. Hence I think your assertion of "I > don't know what this is," is specious. Of course portage knows *what* the file is, it recorded the fact that it installed the file. It could even know what the *changed content* of the file is, that is mere data. What it doesn't know is what the changed content means, because that is information, not data, and portage is software (by definition it is stupid). With an unmerge, portage is confronted with a changed file. It has no idea what information the changes mean, not even differences consisting only of whitespace (some config files are sensitive to whitespace). Realize that a deleted file is gone, all information in it is removed and in all likelihood cannot be retrieved (devs cannot assume that users are backing up files, and it has never been a documented requirement anyway to do so). So even in your example, portage really does not know what "this" is, and does not delete it. > > If I then do "emerge -C mlocate" and delete the package, my customized > version of /etc/updatedb.conf will remain on the root partition, in > spite of the fact that it is now useless. Says whom? Why do you assume it is useless? It may well be you on your machine for the next 5 minutes as the code that uses it is missing, but is it always going to be useless? Can you guarantee that for all users and all instances for ever and ever? > During that emerge > operation, Portage knows that the file belongs to the package being > removed, but because the MD5 differs from that in the manifest it does > not delete the file. I would prefer that it did delete the file, at > least in response to a run-time option. All that portage knows is that the package is being unmerged, it does not know why - again, that is information and you have no way to tell portage *why* you want the package unmerged, only *that* you do. Your last sentence implies you'd prefer it if portage deleted the file by default, but would be happy to have it done as an option. Do you comprehend how dangerous that is? Do you realise how easy it is to, for example, unmerge a package to resolve blockers and forget that portage will nuke your configs? Are you really willing to take that chance? -- alan dot mckinnon at gmail dot com