As is nicely described here , .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:
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:
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.