1 |
On Tue, 31 May 2011 17:26:43 +0100, David W Noon wrote: |
2 |
|
3 |
> >> You have just touched on an annoyance of unmerge, in that it does not |
4 |
> >> clean up configuration files that have been modified. It removes |
5 |
> >> files that are still in the same state as when the package was |
6 |
> >> emerged, but not those modified by the user. I don't see how user |
7 |
> >> changes make the file more important than would be in its vanilla |
8 |
> >> state. |
9 |
> > |
10 |
> >It doesn't remove *any* files that have been modified, |
11 |
> |
12 |
> Erm ... that's what I wrote, above. |
13 |
|
14 |
No it's not. You were referring to a special case of the general |
15 |
statement I made. |
16 |
|
17 |
> [That is, of course, predicated on |
18 |
> the assumption that installing Package A will not modify configuration |
19 |
> files owned by Package B, and vice-versa: all post-installation |
20 |
> modifications are performed by the user.] |
21 |
|
22 |
That is valid, provide collision-protect is included in FEATURES. |
23 |
|
24 |
|
25 |
> >the reasons |
26 |
> >systems used to get cluttered with orphaned .la files. The logic is |
27 |
> >quite simple, if it is not the file portage installed with the |
28 |
> >package, it should not be uninstalled with the package. |
29 |
> |
30 |
> Why should that be so? |
31 |
|
32 |
It's quite simple logic, whether or not you agree with it. If a file is |
33 |
modified, it is no longer the file portage installed, so portage does not |
34 |
uninstall it. If anything, the problem is that the logic used by portage |
35 |
is too simple. |
36 |
|
37 |
> To repeat myself: I do not see a customized configuration file as being |
38 |
> any more important than a vanilla one. |
39 |
|
40 |
A customised file contains an investment of the user's time, a generic |
41 |
file does not. That investment may be small or great, but it is not |
42 |
for portage to determine that value and remove the file without the |
43 |
user's consent. |
44 |
|
45 |
> I should be clear here: a reinstall means "from new, with no previous |
46 |
> version currently installed" and is quite distinct from an upgrade or |
47 |
> rebuild. |
48 |
|
49 |
Not as distinct as you may think. Portage updates a package by first |
50 |
installing the new version then unmerging the old one. As it uses |
51 |
checksums and timestamps to determine ownership of a file, this is safe |
52 |
as it will not remove files from the new version that overwrote |
53 |
identically-named files from the old package. |
54 |
|
55 |
> >There are |
56 |
> >times when some sort of --force-remove option to remove both these and |
57 |
> >files in CONFIG_PROTECTed directories would be useful. |
58 |
> |
59 |
> Again, what I wrote. |
60 |
> |
61 |
> I think we largely agree on this issue. |
62 |
|
63 |
We agree on the usefulness of a purge-like option but not on the |
64 |
desirability or otherwise of the current default behaviour |
65 |
|
66 |
|
67 |
-- |
68 |
Neil Bothwick |
69 |
|
70 |
A friend in need may turn out to be a nuisance. |