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 1QRIjj-0000U2-Nn for garchives@archives.gentoo.org; Tue, 31 May 2011 06:47:32 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7F55C1C04F; Tue, 31 May 2011 06:45:59 +0000 (UTC) Received: from mail-iy0-f181.google.com (mail-iy0-f181.google.com [209.85.210.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 502E81C04F for ; Tue, 31 May 2011 06:45:59 +0000 (UTC) Received: by iyb26 with SMTP id 26so5788846iyb.40 for ; Mon, 30 May 2011 23:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=FDAxUgBUg/OvVDsuAN1BSAv+xC5EtmP9+DGgsXpHEjk=; b=dNabQdRCrjxspFiV4Cs5OIbUi3rCoUcy4nENHq8l7sI1HYDi0cYp17TdSXnU+IWOTg zje980FGLIDivKsgJ+m2TFbaYRu8kvqG9SQ9ut1uoRgQ9NAnzjSvtlhxEo339oUXgL7S h6JEM38ZdstwS7PrSEVJklANOsIBRNgsrmwDY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=nIm9p57KxeiJ4F5WtkqCoJ7KUj68+LGFiD6iU3/z61Wg02+mWHkpEIr4hO6RT03Sh4 PDNlP6dzTDNgtfJNopyordjWKquzI4n9ON4HWMWIhBjR86T2i0oG7pGEgTJ90GQlHK8E 67nHq+u7BcfO0cvdf96Mrl0D7WPyEHkvgOlr0= 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 Received: by 10.43.134.194 with SMTP id id2mr12896808icc.155.1306824358789; Mon, 30 May 2011 23:45:58 -0700 (PDT) Received: by 10.42.29.200 with HTTP; Mon, 30 May 2011 23:45:58 -0700 (PDT) In-Reply-To: <20110530230808.41ecb29a@karnak.local> References: <20110530230808.41ecb29a@karnak.local> Date: Tue, 31 May 2011 08:45:58 +0200 Message-ID: Subject: Re: [gentoo-user] Cleaning redundant configuration files From: Alan McKinnon To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 9c9d4521a15d48f03e6f0ade03fc584f On Tue, May 31, 2011 at 12:08 AM, David W Noon wrote: > On Mon, 30 May 2011 21:20:01 +0200, Neil Bothwick wrote about Re: > [gentoo-user] Cleaning redundant configuration files: > >>On Mon, 30 May 2011 19:05:10 +0100, David W Noon wrote: > [snip] >>> The only algorithmic approach with which I would feel comfortable >>> would be if the file were checked against the previous contents of a >>> package and found present, but has disappeared from the new contents >>> of that same package. =C2=A0Even then, I would want manual confirmation= . >> >>That omits the most common cause of orphaned files, that the package >>owning it has been unmerged. > > You have just touched on an annoyance of unmerge, in that it does not > clean up configuration files that have been modified. =C2=A0It removes fi= les > that are still in the same state as when the package was emerged, but > not those modified by the user. =C2=A0I don't see how user changes make t= he > file more important than would be in its vanilla state. > > Perhaps an option to remove (by an unmerge, not etc-update or the > like) these genuinely orphaned files could be set in /etc/make.conf. The logic appears to be that an unmodified file will be re-instated as-is should the package be re-merged, so nothing changes. A modified config file is more problematic - if the package is re-merged, which version should be used? The old one or the new vanilla one? Presumably the user modified the file last time round for a reason and that reason might still be valid. Only one sensible choice remains - present both files to the human user and ask them to decide. If memory serves, this is in some doc somewhere, I know I read it long ago but don't remember where. --=20 Alan McKinnon alan dot mckinnon at gmail dot com