There are basically three kinds of files in the non-home part of the file system: 1. Files installed by packages, and in the case of FEATURES=protect-owned associated with exactly one package that did install them. 2. Files (symlinks and *.pyc in particular) created by postinst hooks, eselect modules, library caching, or some other non-portage system tool operation. These are somewhat weakly related to a set of packages, but were not installed by any of them. 3. Files created by the user/admin or left over from some misbehaving tool. These are not related to any installed package at all. It is currently almost impossible to distinguish cases 2. and 3. On the other hand, it might make sense to clean up those from 3. from time to time, in order to remove cruft and avoid possible causes for unexpected behaviour. Therefore I suggest adding an option that would allow ebuilds to declare what I call a "file affinity": stating that a given file (or set of files identified using a glob, particularly useful for config dirs) are related to this package, although they haven't been installed by the package itself. A suitable command in ebuilds could be used to store this information in a temporary file to be later included in the CONTENTS of the package. Ebuild writers would be encouraged to declare affinity for all files that are commonly present on installs of their package. This would allow tools like qfile from portage-utils to state all packages with an affinity to a named file, thus making the orphan search much more powerful. You could also add an option to unmerging which would not only remove CONFIG_PROTECTed files but also clean all files with an affinity to a given package, as long as no other package has any kind of ownership (strong or weak) over them.
Is there a real point for this? I guess at the time of reporting situation was worse but right now we try to make some packages own caches and other kinds of files that are updated in postinst. It's usually as trivial as installing an empty file -- it isn't perfect but it works. I suspect having an explicit 'keepfile' (alike keepdir) wouldn't hurt but is it worth the effort?
*** Bug 699798 has been marked as a duplicate of this bug. ***
