I had the same issue 3 months ago (update from .31-5 to .31-6). I compared those files — they differed in two seemingly random bytes. I assumed it's some kind of unimportant data that got modified by db changes, and that the "real" contents are identical in both files. And since I am a little bit OCD (ok, more than a little bit), I ditched the old file; keeping it would mean that it would show as 'MODIFIED' in pacman -Qii, which imo should never happen if the modifications were not intentional.
]]>If I get it right, the correct .pacnew procedure here is rm the .pacnew, isn't it?
]]>It's one of those things that are not really harmful, but nonetheless ridiculously stupid. On my system:
$ pacman -Qii | grep 'MODIFIED' | cut -d '/' -f 2 | sort | uniq -c
1 boot
167 etc
4 usr
2 var
karol wrote:I wonder why pacman creates the .pacnew for it? Something has altered this file - usually it's the user customization, in this case it seems to not involve direct manipulation of the file in question.
This. And I wonder why this file is even in the PKGBUILDs backup array. I though everything under /usr is supposed to be entirely static data, why is the user expected to change something there? Is this worth a bug report?
Should be save to replace the file and reboot than like WonderWoofy suggested before!, strange at least!
edit: reboot was ok, no issues
I wonder why pacman creates the .pacnew for it? Something has altered this file - usually it's the user customization, in this case it seems to not involve direct manipulation of the file in question.
This. And I wonder why this file is even in the PKGBUILDs backup array. I though everything under /usr is supposed to be entirely static data, why is the user expected to change something there? Is this worth a bug report?
]]>Is this even possible?
In this case it is a gdbm database, so it should be possible. You should always replace service-types.db, though. AFAIK the only changes are made by upstream, I don't know why the file (checksum) changes.
]]>Do you use avahi?
]]>