It is my contention that CONFIG_PROTECT for the unmerge action is pretty much pointless. Config files that have been modified will not be removed due to a changed MD5 sum. However, config files that haven't been modified are useless without the package itself and will be reinstalled with the package should a user decide to do so. I'll open this for discussion on gentoo-dev@g.o to get a much wider set of opinions.
Created attachment 26449 [details] List of cruft left behind when unmerging I had to manually trim of files that should be in /etc even though they are not owned by installed packages. The real list for my computer may actually be larger.
Created attachment 26450 [details, diff] Patch to ignore CONFIG_PROTECT when unmerging
I don't think portage should delete files under /etc automatically. My idea is to make /etc/.delete0000_filename file during unmerging. (It's similar with ._cfg0000_filename but it would be empty) Then, we could real delete it by some tools like etc-update or dispatch-conf etc.
That's a good idea, too. Another possibility is deleting only if a new FEATURES flag is set. I'm sure that there are probably some situations where deleting an unmodified configuration file could be detrimental but I can't think of any. The main problem is that there is no way to track what's left behind once a package has been unmerged. Any solution that deals with that is fine by me.
*** This bug has been marked as a duplicate of 8423 ***
> I'm sure that there are probably some situations where deleting an unmodified > configuration file could be detrimental but I can't think of any. Reading your patch i think i've seen one: - foobar-1.0 installs /etc/foobar.conf - you never edit that file - you upgrade to foobar-1.1, it adds /etc/._cfg0000_foobar.conf - /etc/foobar.conf is removed during foobar-1.0 autoclean, and you won't have a foobar config at all until your next etc-update. There would be at least two solutions to this issue: - either makes portage overwrite the unmodified /etc/foobar.conf instead of creating an /etc/._cfg0000_foobar.conf (then it wouldn't be autocleaned since mtime/md5 would be new ones). This can be done safely after checking the /var/cache/edb/config, but the drawback if that users won't see what's new in the default config files they are using. - or you could remove config files only when the action is a real "unmerge" but not a simple "clean" (the 'trimworld' parameter of the unmerge function should be okay to get this information from emerge).
