Better pacnew handling with the next kalu

If you've been following development of the next version of pacman, and are using pacman-git, then you weren't able to use kalu; Let's fix that today.

Also, you might already know that some new events have been added into ALPM, notably events when .pac* files are created. This will make it possible/much easier for frontends (such as pacman, or kalu) to know when such files are created.

From a user perspective, it might not change anything as it's all internal changes. However, the next version of kalu will actually take advantage of this, and can thus make your handling of those .pacnew files quite easier.

kalu's updater and post-sysupgrade processes

As you may already know, when using kalu's updater to perform your system upgrade, you can already define one or more processes to be ran after said sysupgrade was completed.

You can simply enter the command line to be started as is, but you can also use special variables. Specifically, $PACKAGES will be replaced with the list of all packages involved in the sysupgrade (i.e. packages upgraded, as well as those added or removed, for instance with a package is replaced by another one).

The next version of kalu will introduce another variable - $PACFILES - which will be replaced with the list of all .pacnew and .pacorig files created during the sysupgrade.

For .pacorig files the full /path/to/filename will be specified; For .pacnew files it will also be followed by an extra parameter, consisting of the package name & old version.

For example, if /etc/pacman.conf.pacnew was installed during the upgrade, while upgrading from 4.1.2-3 to 4.2.0-1 then the two parameters would be:

/etc/pacman.conf.pacnew pacman-4.1.2-3

Therefore, you can know use this information to improve your handling of those files. Obviously kalu won't do anything else, but you can have e.g. a little bash script to perform a 3-way merge, having pulled the old file from the old package file (assuming it was still in your pacman cache).

Example of automatic 3-way merge handling of .pacnew files

Here's an example of a little script you could call, using $PACFILES as argument. And whenever .pacorig files were installed, a diff of said file and its existing counterpart will show up in GVim. And for every .pacnew files that were installed during the system upgrade, automatically afterwards you'll have a nice 3-way diff opened (for each file, one after the other) in GVim.

  1. #!/bin/bash
  2. tmpdir=
  3. while true; do
  4.     pacnew=$1
  5.     shift
  6.     [[ -z $pacnew ]] && break
  7.     if [[ ${pacnew:${#pacnew}-8} == ".pacorig" ]]; then
  8.         gvim -f -geometry 199x60 -d "$pacnew" "${pacnew:0:-8}"
  9.         ic-question "Remove $pacnew ?"
  10.         [[ $? -eq 0 ]] && SUDO_ASKPASS=~/bin/sap sudo -A rm "$pacnew"
  11.         continue;
  12.     fi
  13.     pkg=$1
  14.     shift
  15.  
  16.     [[ -z $tmp ]] && tmpdir=$(mktemp -d)
  17.  
  18.     pkg=/var/cache/pacman/pkg/$pkg
  19.     file=${pacnew:1:-7}
  20.     old="$tmpdir"/${file##*/}.old
  21.  
  22.     tar xJf "$pkg"* --xform 's#.*/##' --xform 's/$/.old/' -C "$tmpdir" "$file"
  23.     gvim -f -geometry 199x60 -d "$old" "/$file" "$pacnew"
  24.     rm "$old"
  25.     ic-question "Remove $pacnew ?"
  26.     [[ $? -eq 0 ]] && SUDO_ASKPASS=~/bin/sap sudo -A rm "$pacnew"
  27. done
  28. [[ -n $tmpdir ]] && rmdir $tmpdir

Now, this obviously would need tweaking (and could be improved), but it's an example of what can be done.

In this script, it is assumed any old package can/will be found under /var/cache/pacman/pkg and it uses ic-question as well a another little script, sap which reads as follow:

  1. #!/bin/bash
  2. ic-input -H "$@"
  3. echo

And uses ic-input, both of which are simple tool from intercourse (available in the AUR) to provide GUI interfaces to scripts, e.g. could be replaced with things like zenity or the likes; You're in control.

Download packages only

In other news, the next version of kalu will also offer the ability to simply download packages (but not perform the sysupgrade). This is about the same as doing a pacman -Syuw but, again, using a temporary copy of your databases so your databases aren't synced, for the same reason as always.

This works simply by starting a simulation, where you'll find a new button "Download packages" waiting to be clicked. Then, after the usual polkit password prompt (and a final confirmation), downloading of packages will occur.

This can allow you to "pre-download" packages ahead of time, but leaving the actual sysupgrade to later, maybe when you have more time but less bandwidth (nothing that some remains required, to sync your databases).

Downloads and whatnot

All this will be in the next kalu, alongside a few bugfixes and other minor changes, for a full detailled list please refer to the git log. This next version of kalu, which will be called kalu 3.0, is planned for soon after the release of pacman 4.2 (planned for August 31st).

But if you can't wait & are willing to, or are already running pacman-git, then you'll be happy to find a branch pacman-next on github, which you can use to build a compatible kalu, and benefit from all the aforementioned additions. (You can use this PKGBUILD as source, making sure to change the branch name.)

See kalu for more about it in general, and of course, as always, new bug reports, suggestions or any other form of constructive criticism is very much welcome.

Top of Page