Gentoo Archives: gentoo-user

From: Volker Armin Hemmann <volkerarmin@××××××××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Cleaning redundant configuration files
Date: Wed, 01 Jun 2011 18:13:59
Message-Id: 5494053.NRLbeOI46p@localhost
In Reply to: Re: [gentoo-user] Cleaning redundant configuration files by David W Noon
1 On Wednesday 01 June 2011 15:57:58 David W Noon wrote:
2 > On Wed, 01 Jun 2011 01:20:02 +0200, Neil Bothwick wrote about Re:
3 >
4 > [gentoo-user] Cleaning redundant configuration files:
5 > >On Tue, 31 May 2011 17:26:43 +0100, David W Noon wrote:
6 > I'll trim my earlier quote down to the salient statement.
7 >
8 > >> >> It
9 > >> >> removes files that are still in the same state as when the
10 > >> >> package was emerged, but not those modified by the user.
11 > >> >
12 > >> >It doesn't remove *any* files that have been modified,
13 > >>
14 > >> Erm ... that's what I wrote, above.
15 > >
16 > >No it's not. You were referring to a special case of the general
17 > >statement I made.
18 >
19 > I can see no material difference in the two statements in question,
20 > unless you mean "by the user" is a special case. By whom else would
21 > files be modified externally to Portage?
22 >
23 > [snip]
24 >
25 > >It's quite simple logic, whether or not you agree with it. If a file is
26 > >modified, it is no longer the file portage installed, so portage does
27 > >not uninstall it. If anything, the problem is that the logic used by
28 > >portage is too simple.
29 >
30 > Yes, that is the way Portage currently works. But ...
31 >
32 > The contents of the file have been modified, but the file itself is
33 > still owned by the package. That's why etc-update, cfg-update, etc.,
34 > check any new version of the file when the package is upgraded: the
35 > file is still owned by the package.
36 >
37 > So, when the package is to be removed, the file should also be removed
38 > if the user has set an option so to do.
39 >
40 > The place where the current logic could be considered valid is when the
41 > file is an executable. If an executable has been modified outside of
42 > Portage then it is likely the user has installed a foreign package or a
43 > home grown program. One could argue that it is not the place of
44 > Portage to remove these.
45 >
46 > >> To repeat myself: I do not see a customized configuration file as
47 > >> being any more important than a vanilla one.
48 > >
49 > >A customised file contains an investment of the user's time, a generic
50 > >file does not. That investment may be small or great, but it is not
51 > >for portage to determine that value and remove the file without the
52 > >user's consent.
53 >
54 > How much is that investment worth when the entire package is being
55 > deleted? Remember: we are discussing the COMPLETE DELETION of a
56 > package, not an upgrade or rebuild.
57 >
58 > [snip]
59 >
60 > >We agree on the usefulness of a purge-like option but not on the
61 > >desirability or otherwise of the current default behaviour
62 >
63 > I called it an "annoyance". Having to clean up obsolete configuration
64 > files is just that, unless you can offer a better term.
65
66 so - what happens when you uninstall a package to cleanly install it again?
67
68 Happens from time to time - and I seriously would not want to see the
69 carefully personalized config file be moved to the big blue electron pool in
70 heaven.