Request for a "NeverUpgrade" option for pacman.

Question

Yesterday something very serious happened, pacman moved my grub menu.lst file to menu.lst.pacsave. If I wouldn't have spotted this, my system would have become unbootable. This can be fixed by putting it in NoUpgrade (pacman.conf) by default, but there is an underlying problem here.
Pacman will always move your modified files (excluding the ones in NoUpgrade) to .pacsave and use a default file instead. Imagine this would happen on the httpd.conf (apache), my.cnf (mysql), php.ini (php),... files on a production server! It shouldn't, the server admin should have seen that pacman moved them, or he should have put them in the NoUpgrade line. But we're all human and these things happen. And a human error like this already happened with the grub file.
I've always been concerned with the actions of pacman. As Gyroplast said on irc: "Don't f*cking touch any already exiting config files until I explicitly tell you to!".
I've also noticed that a lot of times, these 'new' files are just the same as the original (unmodified) file, or are not worth the upgrade. It only costs time moving the old file back to its original position.
Newbies, people who didn't see that pacman moved their old file (on big updates, the console can even be to small to show this), people that do a "pacman -Syu" through cron,.. will never notice that their system can become unbootable, that apache's config file has been moved, so all their client's sites will be down after a reboot or apache restart,...
This is a very serious issue!
I have a very simpel solution though. I'm sure there are some people that are used to the old way and want to keep it, so we should give people the choice. Either use the old system, or the new. Let's say there is a "NeverUpdate" = yes/no option in pacman.conf. (default: YES!)
If you say no, everything will be back to 'normal'.
If you say yes, things will be different. We will now work with a whitelist instead of a blacklist as Gyroplast proposed. So instead of the "NoUpgrade" option, we will have an "Upgrade" option. All files will be protected by default (and use the .pacnew system), only the files in "Upgrade" can be overwritten, and moved to a .pacsave version. This is all VERY easy (and fast) to implement, if I knew C I would do it myself
I think it's important that this happens as soon as possible, to prevent things like the grub fiasco to happen again.
We can go further however: when a packager creates a new package with config files, he can tell pacman what has been changed (with a new option in PKGBUILD). If I upgrade that package, pacman will tell me exactly what has been added/changed so I can upgrade my file really quickly. Much faster than doing a 'diff' or just comparing it line by line. More work for 1 packager, but less work for hundreds of users. (and that 1 packager will also benefit from this, because he will save time updating packages from other packagers, so a win-win situation 8)). I realize that this will be much more work to implement, but would be a very nice feature in some future version of pacman.
I'm sure there will be some discussion about this, new ideas, people that hate me,..
I hope the Arch developers (particulary apeiro) will join this discussion, and also explain to us why the current pacman is so radical.

Answer 1

FreeBSDs mergemaster really only is a frontend for sdiff, no black magic, so it'd probably be well possible to port it to arch, especially as it's only a shell script.
I think I've given enough examples of how someone can miss this
Yeah, and I could easily construct a dozen more, but there's no excuse for not paying attention to the output of a crucial program if you cannot risk your system going haywire. If you _can_ risk it, though, your point is moot.
The inherent problem is that you cannot fully automate the process, thus always requiring manual interaction if a new config file differs from the original file and the current file has been modified. There is no way around that. You will shredder your system if you do not pay attention when this scenario happens, with the proposed change a little less often, but still. Since problems are not totally ruled out, you still have to check just as often as before, because you cannot know in advance how basic the config file changes are. If you still have to do the same amount of work, I don't see a reason to change anything.
I do not believe in "some security". Either pacman is able to do the job of upgrading reliably and automatically, or it is my sole duty to ensure configuration integrity. All pacman has to (and already can) do in that case is telling me that my interaction is required, and where. It does that now already (if I leave the NoUpgrade misbehaviour aside).
The mergemaster tool would be a very helpful _additional_ tool that could be offered, I have nothing against that, but it's not part of pacman. As I wrote it's just a frontend to sdiff, a fancy tool that may or may not be used. One job - one tool. Pacman's job is installing packages, not solving impossible dilemmas, therefore I'd vote against this extra functionality and would rather discuss how to improve administrator notification to reduce the chance of changes going unnoticed.
A solution to this underlying core problem would be "statistics" at the end of an upgrade process, stating if and what files have been replaced with newer versions. That's legible, it's easy to implement, and it does the job. If you're running pacman unattended, you're acting irresponsible. No matter if your config is replaced or not, you risk your system's integrity, the former risks it a bit more, the latter a bit less, but it's nevertheless risked, which is per se inacceptable, thus leaving the difference in reliability being merely a moot point.
I'll rephrase that:
Yes, the system will probably break more often if the current implementation is kept, but only if the administrator does not do his job and check pacman's warnings. There are no superfluous warnings being generated by pacman that would cause an admin to disregard the output, the only (documented) case of a pacsave being generated is when default config parameters have been changed in the package, which needs interaction _every time_. You're not winning anything by the change, you just gain a "safety net" that is not sufficient for the situation you are constantly referring to; A server system that simply must work. Therefore the safety measure is useless by concept. You cannot reliably help an admin who does not care, and if an admin does not care, it's by defintion not important enough to be considered, so why should a function be implemented that would solve (some, but not all) cases that are considered as unimportant by the admin anyway?
Whoa, evil topic here, so I say "Port mergemaster, make pacman a bit more verbose, be done with it." to keep it short.
Greets,
  Dennis