| 1 |
On May 31, 2011 3:02 AM, "Neil Bothwick" <neil@××××××××××.uk> wrote: |
| 2 |
> |
| 3 |
> On Mon, 30 May 2011 23:08:08 +0100, David W Noon wrote: |
| 4 |
> |
| 5 |
> > You have just touched on an annoyance of unmerge, in that it does not |
| 6 |
> > clean up configuration files that have been modified. It removes files |
| 7 |
> > that are still in the same state as when the package was emerged, but |
| 8 |
> > not those modified by the user. I don't see how user changes make the |
| 9 |
> > file more important than would be in its vanilla state. |
| 10 |
> |
| 11 |
> It doesn't remove *any* files that have been modified, the reasons |
| 12 |
> systems used to get cluttered with orphaned .la files. The logic is quite |
| 13 |
> simple, if it is not the file portage installed with the package, it |
| 14 |
> should not be uninstalled with the package. There are times when some |
| 15 |
> sort of --force-remove option to remove both these and files in |
| 16 |
> CONFIG_PROTECTed directories would be useful. |
| 17 |
> |
| 18 |
If you want to ensure that portage removes a configuration file then add |
| 19 |
CONFIG_PROTECT_MASK="/etc" to the unmerge line and portage will remove the |
| 20 |
configuration files as well. |
| 21 |
|
| 22 |
James Wall |
| 23 |
> |
| 24 |
> -- |
| 25 |
> Neil Bothwick |
| 26 |
> |
| 27 |
> Format: (v.) to erase irrevocably and unintentionally. |
| 28 |
> (n.) The process of such erasure. |
Archives