Bug 43066 – CONFIG_PROTECT during unmerge is redundant

• Product: Portage Development
• Status: RESOLVED DUPLICATE

[Description Jason Stubbs (RETIRED) 2004-02-27 00:29:23 UTC]

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.

[Comment 1 Jason Stubbs (RETIRED) 2004-02-27 00:34:08 UTC]

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.

[Comment 2 Jason Stubbs (RETIRED) 2004-02-27 00:36:41 UTC]

Created attachment 26450 [details, diff]
Patch to ignore CONFIG_PROTECT when unmerging

[Comment 3 Masatomo Nakano (RETIRED) 2004-02-27 06:52:28 UTC]

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.

[Comment 4 Jason Stubbs (RETIRED) 2004-02-27 07:10:13 UTC]

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.

[Comment 5 SpanKY 2004-02-27 11:22:05 UTC]

*** This bug has been marked as a duplicate of 8423 ***

[Comment 6 TGL 2004-02-27 17:42:17 UTC]

> 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).