| 1 |
On Wed, 1 Jun 2011 15:57:58 +0100, David W Noon wrote: |
| 2 |
|
| 3 |
> >No it's not. You were referring to a special case of the general |
| 4 |
> >statement I made. |
| 5 |
> |
| 6 |
> I can see no material difference in the two statements in question, |
| 7 |
> unless you mean "by the user" is a special case. By whom else would |
| 8 |
> files be modified externally to Portage? |
| 9 |
|
| 10 |
I mean that your referring to config files is a special case, portage |
| 11 |
won't remove any file from anywhere in the tree that has been modified. |
| 12 |
|
| 13 |
> The contents of the file have been modified, but the file itself is |
| 14 |
> still owned by the package. |
| 15 |
|
| 16 |
That depends on your definition of ownership. The file is not the same |
| 17 |
file that portage installed, so it can no longer claim ownership, that |
| 18 |
is now down to whoever modified the file. |
| 19 |
|
| 20 |
> That's why etc-update, cfg-update, etc., |
| 21 |
> check any new version of the file when the package is upgraded: the |
| 22 |
> file is still owned by the package. |
| 23 |
|
| 24 |
No, portage is checking whether a config file of the same name as the one |
| 25 |
installed by the package exists. It doesn't care where the existing file |
| 26 |
originated, only that it is in a CONFIG_PROTECTed directory and should |
| 27 |
not be overwritten. etc-update and friends simply look for ._cfg* files. |
| 28 |
|
| 29 |
> >A customised file contains an investment of the user's time, a generic |
| 30 |
> >file does not. That investment may be small or great, but it is not |
| 31 |
> >for portage to determine that value and remove the file without the |
| 32 |
> >user's consent. |
| 33 |
> |
| 34 |
> How much is that investment worth when the entire package is being |
| 35 |
> deleted? |
| 36 |
|
| 37 |
That depends on whether the package will be installed again. |
| 38 |
|
| 39 |
> Remember: we are discussing the COMPLETE DELETION of a |
| 40 |
> package, not an upgrade or rebuild. |
| 41 |
|
| 42 |
We are discussing unmerge behaviour, unmerging is part of the upgrade |
| 43 |
and rebuild processes. |
| 44 |
|
| 45 |
> >We agree on the usefulness of a purge-like option but not on the |
| 46 |
> >desirability or otherwise of the current default behaviour |
| 47 |
> |
| 48 |
> I called it an "annoyance". Having to clean up obsolete configuration |
| 49 |
> files is just that, unless you can offer a better term. |
| 50 |
|
| 51 |
How about "feature request waiting to be made"? |
| 52 |
|
| 53 |
|
| 54 |
-- |
| 55 |
Neil Bothwick |
| 56 |
|
| 57 |
If at first you don't succeed, call in an airstrike. |
Archives