On Tue, 31 May 2011 17:26:43 +0100, David W Noon wrote: > >> You have just touched on an annoyance of unmerge, in that it does not > >> clean up configuration files that have been modified. It removes > >> files that are still in the same state as when the package was > >> emerged, but not those modified by the user. I don't see how user > >> changes make the file more important than would be in its vanilla > >> state. > > > >It doesn't remove *any* files that have been modified, > > Erm ... that's what I wrote, above.
No it's not. You were referring to a special case of the general statement I made. > [That is, of course, predicated on > the assumption that installing Package A will not modify configuration > files owned by Package B, and vice-versa: all post-installation > modifications are performed by the user.] That is valid, provide collision-protect is included in FEATURES. > >the reasons > >systems used to get cluttered with orphaned .la files. The logic is > >quite simple, if it is not the file portage installed with the > >package, it should not be uninstalled with the package. > > Why should that be so? It's quite simple logic, whether or not you agree with it. If a file is modified, it is no longer the file portage installed, so portage does not uninstall it. If anything, the problem is that the logic used by portage is too simple. > To repeat myself: I do not see a customized configuration file as being > any more important than a vanilla one. A customised file contains an investment of the user's time, a generic file does not. That investment may be small or great, but it is not for portage to determine that value and remove the file without the user's consent. > I should be clear here: a reinstall means "from new, with no previous > version currently installed" and is quite distinct from an upgrade or > rebuild. Not as distinct as you may think. Portage updates a package by first installing the new version then unmerging the old one. As it uses checksums and timestamps to determine ownership of a file, this is safe as it will not remove files from the new version that overwrote identically-named files from the old package. > >There are > >times when some sort of --force-remove option to remove both these and > >files in CONFIG_PROTECTed directories would be useful. > > Again, what I wrote. > > I think we largely agree on this issue. We agree on the usefulness of a purge-like option but not on the desirability or otherwise of the current default behaviour -- Neil Bothwick A friend in need may turn out to be a nuisance.
signature.asc
Description: PGP signature
