Re: [gentoo-user] Cleaning redundant configuration files

[David W Noon]

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.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwnoon@××××××××.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*