There are many times when I do upgrades where I see portage report that configuration files have changed. I usually just tell etc-update to replace all of them because none of them are files I modified. Portage should store the hash of configuration files whenever it installs a program and then upon updating a program where a conflict occurs between an old configuration file and a new configuration file, it should check to see if the hash of the old file matches the hash in its database for the stock version of that file and if it matches, it should automatically replace the file. Otherwise, it should behave as it does now. Reproducible: Always Steps to Reproduce: This would help make people's lives easier by automating a task that they would otherwise do with etc-update. Some sort of option could be used to opt-out of the new behavior to make portage retain the old behavior. If having it be opt-out is a problem, then an opt-in option would be nice, although I imagine that the majority of portage users would opt into this feature than opt out of this feature.
The quickpkg program complicates things, since a user cache create a binary package from an installed package (with modified config) and when this binary package is installed there is no way to know whether or not the config was really unmodified or not. Additionally, there may be cases in which the default configuration has changed in a way that is incompatible with the previous default configuration. For example, the default layman configuration recently changed the default storage location for overlays, and blindly updating to the default config would not be very nice in this case. Also, note that portage has a "config memory" feature which helps the user avoid having to merge an identical configuration file more than one (disabled by emerge --noconfmem).
Could quickpkg be modified to include both the stock configuration files and the modified configuration files? Portage could probably handle the old format by keeping a note that the stock configuration files are missing. As for the default configuration changing in a way that is incompatible with the previous default configuration, ebuilds should provide warnings for that and if the user is ignoring those messages, issues due to changes like that would likely happen anyway. If either the issues caused by poorly maintained ebuilds or users that ignore warning messages are enough to prevent this from being made a standard feature, could this be provided as an opt-in feature for advanced users like PORTAGE_IONICE_COMMAND was? Advanced users should know the ins and outs of portage enough that they could handle any issues that might arise.
I believe this is currently implemented in Portage 2.2.28 (and possibly earlier) with the default FEATURE flag config-protect-if-modified. From the man page for make.conf: "This causes the CONFIG_PROTECT behavior to be skipped for files that have not been modified since they were installed. This feature is enabled by default." I can't speak about quickpkg, but that isn't the issue from the original post. Can this 6 year old bug get closed now?
