You are not logged in.
After upgrading avahi 5 min. ago, I noticed this;
/usr/lib/avahi/service-types.db.pacnew
really, I have no clue how to handle this one!
Last edited by qinohe (2013-05-21 13:00:38)
Offline
$ less /usr/lib/avahi/service-types.db
"/usr/lib/avahi/service-types.db" may be a binary file. See it anyway?
Interesting :-)
Offline
I won't reboot before I know what is going on, I also had 3.9.3.1.
Since *.db can't be read I love to hear know;) what to do!
Last edited by qinohe (2013-05-20 20:36:14)
Offline
I just moved the pacnew file into place. I honestly don't actually use avahi on this system, and it is just installed as a dep of something else. So it doens't really matter to me. This has come up in the past, but that time I did the same thing...
Do you use avahi?
Offline
Same as wonderwoofy. Survived reboot, but I too don't use avahi.
If I'm curt with you it's because time is a factor. I think fast, I talk fast and I need you guys to act fast if you wanna get out of this. So, pretty please... with sugar on top. Clean the [censored] car. -The Wolf
Offline
Well the only reason I come up with it is.
The file is standing there but if I needed to merge!, how would I do that, with a *.db file?
Is this even possible?
Offline
I guess you could determine what kind of db it is and attmpt to use whatever tool is required. But this si the only incident that I have seen where these circumstances arise. So if you don't actually use avahi, just copy over the pacnew file to the right spot and move on...
Offline
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.
Offline
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.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
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?
Offline
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
Last edited by qinohe (2013-05-20 22:07:16)
Offline
I think it is a packaging error. A binary file shouldn't be saved as pacnew.
Offline
Thank you all, for clearing this.
Offline
https://bugs.archlinux.org/task/33930
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
Offline
Thanks for the bug report link, msthev.
If I get it right, the correct .pacnew procedure here is rm the .pacnew, isn't it?
Offline
Yes, I did read that bugreport yesterday.
Is there a command to check which were the actual ones updated?
I have some too, but!, etc-update or pacmatic can't find them
But they might actually only be looking in /etc
Offline
I'd say the correct thing to do is `mv $f.pacnew $f`. If you didn't deliberately modify any of those files, then you probably want to keep the package vanilla, in which case system files should be identical to those from the package.
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.
Offline
So if I understand correct, move into place is the way?
This I did, but didn't force it!!
Offline