1 |
On Tue, May 31, 2011 at 12:08 AM, David W Noon <dwnoon@××××××××.com> wrote: |
2 |
> On Mon, 30 May 2011 21:20:01 +0200, Neil Bothwick wrote about Re: |
3 |
> [gentoo-user] Cleaning redundant configuration files: |
4 |
> |
5 |
>>On Mon, 30 May 2011 19:05:10 +0100, David W Noon wrote: |
6 |
> [snip] |
7 |
>>> The only algorithmic approach with which I would feel comfortable |
8 |
>>> would be if the file were checked against the previous contents of a |
9 |
>>> package and found present, but has disappeared from the new contents |
10 |
>>> of that same package. Even then, I would want manual confirmation. |
11 |
>> |
12 |
>>That omits the most common cause of orphaned files, that the package |
13 |
>>owning it has been unmerged. |
14 |
> |
15 |
> You have just touched on an annoyance of unmerge, in that it does not |
16 |
> clean up configuration files that have been modified. It removes files |
17 |
> that are still in the same state as when the package was emerged, but |
18 |
> not those modified by the user. I don't see how user changes make the |
19 |
> file more important than would be in its vanilla state. |
20 |
> |
21 |
> Perhaps an option to remove (by an unmerge, not etc-update or the |
22 |
> like) these genuinely orphaned files could be set in /etc/make.conf. |
23 |
|
24 |
The logic appears to be that an unmodified file will be re-instated |
25 |
as-is should the package be re-merged, so nothing changes. A modified |
26 |
config file is more problematic - if the package is re-merged, which |
27 |
version should be used? The old one or the new vanilla one? Presumably |
28 |
the user modified the file last time round for a reason and that |
29 |
reason might still be valid. |
30 |
|
31 |
Only one sensible choice remains - present both files to the human |
32 |
user and ask them to decide. |
33 |
|
34 |
If memory serves, this is in some doc somewhere, I know I read it long |
35 |
ago but don't remember where. |
36 |
|
37 |
|
38 |
-- |
39 |
Alan McKinnon |
40 |
alan dot mckinnon at gmail dot com |