pacmarge -- a tool for automatically merging .pacnew files

foutrelis · 2015-11-22 04:33:04

After getting really annoyed by the latest shorewall update which changed a comment line in about 10 files, I decided to explore ways to automate such trivial config updates.

The result is pacmarge: https://github.com/foutrelis/pacmarge (AUR package: https://aur.archlinux.org/packages/pacmarge/)

It's best to be used right after a .pacnew file has been created (following an update). It will compare the old packaged version of the file against the current one, and see if the changes apply cleanly to the .pacnew file, in which case it will apply them and overwrite the current file with the modified .pacnew file.

Being a new and untested tool, I cannot guarantee that it will do the right thing. Feel free to look at its few lines of code to understand what it does exactly, and run it at your own risk.

Also keep in mind that I just started maintaining an archive of old backup files today, so any existing .pacnew files won't be handled by this tool; only .pacnew files created by future packages will have the necessary archived copies.

*waiting impatiently for the next pacman-mirrorlist update*

mauritiusdadd · 2015-11-22 08:05:46

Thank you, it's very convenient! I just installed it and it seems to be working: it happily rejected to merge a .pacnew for pacman-mirrorlist (as expected, since I use reflector to update it), and skipped a couple of .pacnews which are not in the backup archive. The code also seems fine to me. I will continue to test it and I'll report any unexpected behaviour.

Wild Penguin · 2015-11-22 11:57:33

Hi,

First, just a simple question - why the name "pacmarge"? I really tried to install first pacmerge, and it took 5 seconds to notice the error

I've migrated from Gentoo, and there used to be / are several tools there to facilitate this kind of mundane and boring jobs. Any of the alternatives would try to merge the new config files with the old ones - and when they could not, the files would be fired up in 'vimdiff' or whatever was supported and chosen by the user. Something similar would be welcome in Arch Linux, too!

However, there is no documentation in your tool. This is my output when I run the program:

$ sudo pacmarge 
:: Cloning pacmarge backup file archive...
Cloning into '/var/cache/pacmarge-archive'...
remote: Counting objects: 3548, done.
remote: Compressing objects: 100% (1453/1453), done.
remote: Total 3548 (delta 242), reused 3514 (delta 208), pack-reused 0
Receiving objects: 100% (3548/3548), 1.96 MiB | 1.29 MiB/s, done.
Resolving deltas: 100% (242/242), done.
Checking connectivity... done.
:: Attempting to merge changes to 10 file(s)
[SKIPPED] /etc/apacman.conf
[SKIPPED] /etc/locale.gen
[SKIPPED] /etc/pulse/client.conf
[SKIPPED] /etc/lightdm/lightdm.conf
[SKIPPED] /etc/monitorix/monitorix.conf
[SKIPPED] /etc/ssh/sshd_config
[SKIPPED] /etc/makepkg.conf
[FAILED] /etc/pacman.d/mirrorlist
[SKIPPED] /etc/ssmtp/ssmtp.conf
[SKIPPED] /etc/sudoers

What does "SKIPPED" mean and how does it differ from "FAILED" ?

Thanks, I believe your tool might really be a good starting point!

ukhippo · 2015-11-22 18:12:02

Wild Penguin wrote:

What does "SKIPPED" mean and how does it differ from "FAILED" ?

My guess (based purely on reading this thread) is:

SKIPPED means that there was no attempt to merge the pacnew file (because there is no previous pacnew stored in the the backup archive from which to derive the actual changes this pacnew introduces)
FAILED means the actual changes were determined, but attempting to merge the changes errored.

So the net result is the same (no merge), but it's at least giving a clue why it was unable to do the merge.

foutrelis · 2015-11-22 18:39:18

ukhippo explained it very well. I also added a man page, pacmarge(1), with some additional information.

ukhippo · 2015-11-22 23:36:47

To help mitigate the skip issue, you might want to consider the following:

check the pacman cache first for the previous version of the package. If present, extract the file from there.
no previous package, check (as now) your archive for the file.
file not in your archive, download package from the Arch Linux Archive and extract file

This has the advantage of not requiring any download if the package is still in the cache. Some people may not want to download the package from the ALA (some packages are quite large), so you could make that user-selectable (e.g. A “--ala” and/or “--no-ala” command line options)

Edit: more on the ALA: https://wiki.archlinux.org/index.php/Arch_Linux_Archive

Last edited by ukhippo (2015-11-22 23:38:56)

foutrelis · 2015-11-23 01:41:02

There's a simpler way; I imported all packages from this year to the archive.

Now I need to make it use a bare checkout which, on ext4, needs about 2.5M of disk space instead of 140M for a normal checkout...

Edit: Bare checkout implemented in: https://github.com/foutrelis/pacmarge/commit/8109763

Last edited by foutrelis (2015-11-23 03:50:37)

Arch Linux

#1 2015-11-22 04:33:04

pacmarge -- a tool for automatically merging .pacnew files

#2 2015-11-22 08:05:46

Re: pacmarge -- a tool for automatically merging .pacnew files

#3 2015-11-22 11:57:33

Re: pacmarge -- a tool for automatically merging .pacnew files

#4 2015-11-22 18:12:02

Re: pacmarge -- a tool for automatically merging .pacnew files

#5 2015-11-22 18:39:18

Re: pacmarge -- a tool for automatically merging .pacnew files

#6 2015-11-22 23:36:47

Re: pacmarge -- a tool for automatically merging .pacnew files

#7 2015-11-23 01:41:02

Re: pacmarge -- a tool for automatically merging .pacnew files

Board footer