Two ideas: - When etc-update updates a file, the previous version should be checked in with rcs to keep a history of changes. This should be one of the portage features. - If a protected file is updated, and the file is still the file that came with the original emerge, it should be overwritten without asking (checking it into rcs like etc-update). This is based on the fact that the ebuild maintainer knows what goes on in the ebuild. This bug is dependant on bug #7596, because it relies on the config file details being known.
I have not yet considered the possibility of using rcs, but the auto-upgrade capability is something that will be coming soon.
Nice suggestion. I was going to ask for a finer control on config_protect because typically, I want portage to update all the files that I haven't touched. I was thinking about a timestamp thing, but of course souce control is far better.
The only way that it's safe to overwrite config files -- even if they haven't been changed -- is by knowing that the config files are "compatible". Meaning, if todays Apache uses /var/http as the default directory, and tomorrow they decide to change that to /home/http, your web server is toast. The package maintainer can make sure that the directory doesn't change, but since he needs to check that stuff anyway, it makes sense for the ebuild to include information about whether or not its config files are suitable to replace older ones or not. (Or need to replace older ones because the format changed.)
*** This bug has been marked as a duplicate of 11736 ***
I assume you meant to mark this as a duplicate of 11763, not 11736.
wrong bug
*** This bug has been marked as a duplicate of 11763 ***
