Hi, As is nicely described here [1], .pacnew files are created if the new version differs from both the old version, and the user modified version. User intervention is required to resolve the conflict. Since the user modified the file themselves, one might think that they would have no trouble resolving that conflict. However, in my experience it is sometimes not as trivial as it should be. For example, just recently /etc/group.pacnew was created due to an upgrade of 'filesystem'. This was the output of diff group group.pacnew for me: 8c8 < lp:x:7:daemon,drizzd ---
lp:x:7:daemon 11c11 < wheel:x:10:root,drizzd
wheel:x:10:root 15c15 < log:x:19:root,drizzd
log:x:19:root 21,25c21,26 < games:x:50:drizzd < network:x:90:drizzd < video:x:91:drizzd < audio:x:92:drizzd,mpd < optical:x:93:drizzd
games:x:50: lock:x:54: network:x:90: video:x:91: audio:x:92: optical:x:93: 27,29c28,30 < storage:x:95:drizzd < scanner:x:96:drizzd < power:x:98:drizzd
storage:x:95: scanner:x:96: power:x:98: 32,50d32 < dbus:x:81: < avahi:x:84: < rtkit:x:133: < gdm:x:120: < postgres:x:88: < postfix:x:73: < nm-openconnect:x:104: < postdrop:x:75: < networkmanager:x:1000:drizzd < usbmux:x:140: < mpd:x:45: < vboxusers:x:108: < lpadmin:x:1001:drizzd < munin:x:999: < adbusers:x:1002:drizzd < lock:x:54: < ntp:x:87: < lxdm:x:1003:
Ok, so I added myself to several groups. Those are easily eliminated. But what about this large number of groups at the end, which seem to be gone in the new version? I didn't add them manually, but surely some of those are still needed. With help of some version control history I found out that the 'lock' group was added, but /etc/group was immediately updated by the install script, and therefore the .pacnew file was redundant. Long story short, this could have gone much more smoothly if a .pacold file (corresponding to the original file from the old package version) had been provided alongside the .pacnew file. Diffing old vs. new would show the single-line change, making it obvious what to do: nothing. So much for the motivation. As for the feasibility, I've done some research. On my system, I currently have in total of: 1037 packages 406 backup files 2.7M of disk space used by backup files 408K of disk space used by tar.gz'd backup files 25M of disk space used by /var/lib/pacman/local Currently, the local db stores only hashes of the installed backup files, but not the actual contents. Judging from the example above, storing the contents of the backup files would add only 2.7M to currently 25M. Compression can be used to reduce the overhead further. I have not worked on pacman before, but if the concept sounds good to you, I will try to implement this. As a future improvement, once .pacold files are available, pacnew merge tools could also be taught to use three-way merge. Clemens [1] https://wiki.archlinux.org/index.php/Pacnew_and_Pacsave_Files#.pacnew