Please attach the output from pacman when using the --verbose switch, so I can see the md5sum comparisons.

thanks.

i'll do that asap - i'm actually having trouble replicating this now - which is strange!

Pacman should not ***EVER*** overwrite files in /etc, under any circumstance. This is an absolutely horrible and intollerable bug how Arch Linux behaves this way. Anything at all under /etc which is not a stock file should have new files output as .pacnew, never overwriting. Arch Linux is the only distro I have ever seen that has this critical flaw. At the VERY least it should ask user confirmation to overwrite ANY file in /etc. I have lost a large custom /etc/profile after two Bash updates in one day, not noticing the .pacnew file. At the VERY, VERY, VERY, ***VERY*** least, make it .pacsave.1 then .pacsave.2, etc.

Oops, "not noticing the .pacnew file" should be "not noticing the .pacsave file".

i have to say i think your problem is essentially "user error" but i do agree that it is an error far to easy to make - especially if files in /etc are being moved to .pacsave when you don't want them touched at all and assume they aren't.

i think pacsave.1 then .pacsave.2 - is a good idea but could get messy

>>>> At the VERY least it should ask user confirmation to overwrite ANY file in /etc

i think that is a good point BUT pacman DOES tell you when it moves files around

"BUT pacman DOES tell you when it moves files around"

How is a program "telling you" that it is doing something wholley wrong helpful ? It is one line in pages and pages of output when doing a full --sysupgrade. The point is that it should NEVER overwrite a custom configuration file with a distro stock config file. There is *no* sense in doing this. It is *never* a good idea. Anyone that has configured their system custom, does not want it being overwritten when they keep their system up-to-date.

It is one of the biggest things setting Arch Linux back from being a usable server distro -- I can't imagine any server operator trusting a distro that erases their absolutely vital config files, just for the hell of it.

Furthermore there is already a concept of .pacnew, which makes perfect sense. *ALL* files that fall under /etc should be extracted as .pacnew, without any exceptions. If the user ever wishes to revert to a distro stock version of a particular config file, such as PHP's, all they need to do is:

mv /etc/php.ini{.pacnew,}

ah - finally - proof of the problem

http://dtw.jiwe.org/share/pacman_errors.rtf

I think that says it all - it is the -U that is the problem

actually please try

http://dtw.jiwe.org/share/pacman_errors_new.txt

I have to agree with Raven, it was quite a "surprise" (not in a good way) when I first did a --sysupgrade and pacman overwrote my custom config files.

I think a less aggressive logic when upgrading packages might be:

if config file is stock, overwrite it, otherwise install new config file as <file>.pacnew

As an observation, urpmi in Mandriva handles config files similarly, but only overwrites the config file if it is not changed from the one originally installed. So if my sshd_config file includes custom mods, the new config file for a version upgrade (which may contain more options or a different default setting) is installed as sshd_config.rpmnew, but if the file was not changed from the previous install, it is overwritten with the new default config file.

IMHO, this is a very sane way of handling this, allowing pacman to roll out new default settings to people that use them, but leaving custom configs alone when they have been put in place by the admin.

Greg Meyer:

Yes, I agree, that is the sensible and sane way to do it.

status ?

See also these comments:
http://bugs.archlinux.org/task/3644