Keeping one’s system up-to-date is something that should be done regardless of one’s system. It’s not that it’s more true with Arch Linux, just that updates are (likely to be) more frequent, due to its rolling-release nature.
One way to do so is to remember to manually do a
syu (or whatever alias you have set for
sudo pacman -Syu), but that might not be ideal. If you work within a X session, using an upgrade notifier might feel like a very logical solution.
There are already a few “update notifier” out there, which will run in the background and let you know as soon as a package has been updated, but I couldn’t find one that would fit my needs (granted I didn’t search too hard, I was also interested in making my own as a fun exercice…) so I decided to make a new one.
I already posted about kalu a little while ago, but at the time it was still in development stage. It has now hit stable status, so I figured I might make a little post about it.
kalu (which could stand for “Keeping Arch Linux Up-to-date”) is a small application that will add an icon to your systray and sit there, regularly checking if there’s anything new for you to upgrade. As soon as it finds something, it’ll show a notification to let you know about it. Very classic stuff.
You can know whether kalu found something or not during its last check simply by looking at its icon: if all gray, nothing was found. If blue, move your pointer over it to see (in the tooltip) what was found. If the icon happens to “blink” from gray to blue, it simply means kalu is currently busy.
What makes kalu any different?
For starter, it doesn’t need root privileges to do its checking. Not because it doesn’t synchronize databases, since that would make it mostly useless, but because it will create a temporary copy of your sync databases, sync those, and then remove them of course.
The idea is not only not to require root privileges, but more importantly to avoid putting you in a situation where you’d risk messing up your system, as you might unknowingly end up basically doing a
pacman -Sy foobar (which is pretty generally understood to be a bad idea).
Because if kalu did sync your databases, and there were upgrades available, but you did not apply them right away (for one reason or another, e.g. you’re busy, or were AFK when the notification poped up and didn’t see it…) then your next -S operation would really by a -Sy, event though you might not even realize it.
What does it check for?
kalu can check for a few things :
Arch Linux News. To be sure not to miss an important announcement from Arch Linux’s official website.
Available upgrades for installed packages. That is, anything from one of the repos, or what would be upgraded with a
Available upgrades for non-installed packages. You can define a list of “watched packages”, that is packages for which you’d like to be notified when an upgrade is out, even though they’re not installed. (E.g. packages you repack for yourself to apply a patch or something)
Available upgrades for AUR packages. All foreign packages (i.e. not found in any repo, aka
-Qm) can be checked for upgrades available in the AUR.
Available upgrades for watched AUR packages. Just like with “regular” packages, you can have a list of packages in the AUR for which you’d like to be notified when an upgrade is available, even though they’re not installed.
Of course you don’t have to use all of this, and you can define which of those checks kalu should do. Besides maintaining lists of watched (AUR) packages, you can also define a list of foreign packages that kalu should not check the AUR for. Since there’s no reason to check for packages you know aren’t from the AUR (e.g. packages of your own making).
When does it check?
You can define how often kalu should run its automatic checks, from few minutes to days (or more). You can also, of course, have them run at any time though menu Check for Upgrades.
Automatic checks are good if you’re in front of the screen, so you can see the notifications and act of them (or not). But even if you have your computer on 24/7, chances are you still go to bed at some point. Since there’s no reason to have kalu keep checking for upgrades then, you can define a period of time during which no automatic checks will be performed (e.g. nothing from 11 p.m. till 8 a.m.).
Whenever something is found, kalu will show a notification. Each check has its own notification, defined using a template.
All templates are made of 3 fields: Title, Package (or News item), and Separator. Title will be the title of the notification. Package (News item) is the text corresponding to one package/news item. It will be repeated for each package/news item, separated using Separator, to make the body of the notification.
Each field can have none, one or more variables. They are not the same for all templates, but basically you have the package name, its old/current version number, the new version number, and (if applicable, i.e. not for AUR packages) the download, installed and net (post-installation difference) sizes. (For a bit more information, check out kalu’s man page.)
Notifications for upgrades & AUR upgrades can also feature a button to start the corresponding upgrade. This button can be used to simply trigger a process of your choosing, e.g. you could have it start pacman with something like
urxvt -e sudo pacman -Syu
While for AUR upgrades there is no more option, for upgrades you can decide to use kalu’s own system updater, which does exactly the same, only in a GTK GUI.
Checking is good. Upgrading too.
kalu’s updater aims to provide a way to upgrade your system (like a
pacman -Syu would) from a GUI. It doesn’t do anything else (i.e. it’s not a package manager, and can’t be used to install or remove packages).
Before being able to synchronize your databases (and possibly upgrade the system) the updater will obviously require root privileges. The way it works is: kalu itself only contains the GUI, and the part that does interact with libalpm (to actually upgrade your system) is in a secondary binary (
Only this binary requires root privileges, will be started through DBus and rely on PolicyKit to ensure you are authorized before doing anything.
Obviously this requires you to have PolicyKit installed, but also (assuming default configuration) a PolicyKit agent, which is the one in charge of asking for your/root password and making sure you don’t just press random keys and whatnot.
You can also define one or more processes to be run after completing a system upgrade (to start e.g. localepurge and/or PkgClip), and kalu will ask whether to start them or not. In case you specify more than one, the full list will be featured and you will be able to determine which (if any) to start each time.
Because people love screenshots, right? :-)
(And there are a few more in the original post here).
There you go. Hopefully this might be useful to some. As hinted above, DBus and PolicyKit (including a running PK agent) are required for kalu to work. It also requires libalpm 7 (pacman 4), cURL, libnotify (and a notify daemon if you wanna see something, obviously) as well as GTK3.
Thanks to the Pacman development team for their great work and nice code; Thanks to Dave Gamble for his JSON parser; And thanks to Painless Rob for his great icon.
kalu is released under GNU GPL v3+ The source code is available on this BitBucket repository.
You can also find a PKGBUILD in the AUR.
And of course bug reports, suggestions or any other form of constructive criticism is very much welcome.