[pacman-dev] config handling

x.chantry at wanadoo.fr x.chantry at wanadoo.fr
Tue May 16 16:09:02 EDT 2006

First, I've to say that I don't see the point of NoUpgrade feature. Default pacman config handling is just great, it'll never overwrite a config file you edited, it'll only upgrade the config files you never edited. Why would anyone not want this ? It just looks like the only sane thing to do.

Secondly, since it seems that NoUpgrade makes sense for most people (please tell if I'm not alone finding it pointless :)), there is a very annoying thing with it : it always extract the config file to pacnew, no matter if the current config is the same (you didn't edit it), or the original is the same (you edited it, and want to keep your config file, not reverting to the default config). Thus most of the times, you'll have a pointless pacnew files. It's harder to track when a config file got updated or not.

Finally, since I dislike current NoUpgrade behavior, I wanted to remove the config files from there and get the (nice) default pacman config handling, which does just the right thing.
But, when a config file is in NoUpgrade, and you (re)install the corresponding package, pacman stores the md5sum of /etc/foo (ie your current local config file), instead of /etc/foo.pacnew (pkg config file).
So when you remove a config file from NoUpgrade, and reinstall the package, you are in the case :
original=X, current=X, new=Y
which is the only case where pacman actually overwrites the config file, which is perfectly right, except that here, the original md5sum is wrong (it's the current config file, instead of the previous pkg one).
So you actually lost your custom config file, which pacman should never allow. (I hope you understand that NoUpgrade is the problem causing this, not an answer).

I've made a patch that makes NoUpgrade behave less annoyingly (even if I would rather remove it totally), by only extracting a pacnew file when the pkg config file has changed (original = X, new = Y), so no more useless pacnew files. And it fix in the same time the above issue.
It always made me feel better with last filesystem upgrade :) (where most of its config files are in NoUpgrade, but the last package update didn't modify these config files, so pacman didn't extract them as .pacnew)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pacman.diff
Type: application/octet-stream
Size: 2035 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/pacman-dev/attachments/20060516/bb2b9afb/attachment.obj>

More information about the pacman-dev mailing list