When unmerging a package, Portage often fails to delete certain files, because they're config protected, or they've changed, etc. I would like to propose something like a /var/db/pkg/cruft directory, where we would put an UNDELETABLE-CONTENTS file for each package with files that weren't deleted. Users can then see which files weren't deleted, and manually delete them. It might be a good idea to make the UNDELETABLE-CONTENTS file similar to the CONTENTS file, with MD5 sums of the undeletable files *at the time the unmerge happened*. That way, if someone makes a tool to automatically remove the undeletable files, it could still warn the user if the file has changed since the package was unmerged, indicating that the file is still in use.
No central file db- this is why portage relies on mdm5's and mtime to determine if the file needs be removed. That is the underlying cause of orphaning files on unmerge. That's also why this request is questionable ;) . To do what you're asking, we need a central file db to determiine if the file actually _was_ orphaned- collision-protect does makes this easier, but it's not a required feature, thus an actual centrak db is required. Mind you I'm not excusing orphaning files- that bugs the hell out of me personally. Just explaining the reasons, and why their is no orphan list- if we implemented that list, we would already solve the orphaning problem.
Reopening for duping
*** This bug has been marked as a duplicate of bug 159165 ***
