jasonwryan.com

Miscellaneous ephemera…

AUR Helpers

Or, “Why you should uninstall Yaourt and embrace makepkg…”

The release of Pacman 4.1 saw the same flurry of posts on the boards, in IRC and the mailing lists about people being “unable” to upgrade or, worse, claiming that pacman was “broken” because their upgrade was failing due to unsatisfied dependencies, that pretty much every pacman upgrade ocassions. How is it possible that so many people can run an operating system designed for competent users without having even a basic understanding of how the package manager—one of the single most critical components of the distribution—works?

Even a cursory perusal of the resulting threads on the boards will quickly identify the common denominator in these cases:

resolving dependencies…
looking for inter-conflicts…
error: failed to prepare transaction (could not satisfy dependencies)
:: package-query: requires pacman<4.1

package-query is required by yaourt; so these upgrades have been stymied by a package that is in the (unsupported) AUR? There are a multitude of AUR helpers, but yaourt is most commonly used by people who are new to Arch1 for two reasons. First, it is one of the most “featureful” and secondly, and more to the point of my argument, it can be installed by simply adding an unsupported repo to pacman.conf; thereby effectively bypassing the need for the hapless user ever having to use or understand makepkg.

Consequently, over time, people who are habitually using yaourt -Syu --aur to update both the packages in the supported repositories and those they have installed from the AUR lose the conceptual distinction between the two. yaourt obscures this from them and—if they are completely reliant upon it, as these threads attest they are—they have abnegated responsibility for managing those unsupported packages and in doing so have found themselves incapable of understanding the bind they are in.

This sort of obscuring of fundamental operating principles in the pursuit of “convenience” is anathema to Arch and is precisely the reason I moved away from using yaourt (and indeed from using Ubuntu when I jumped from that sinking ship). Any convenience is purely illusory, in reality it just fosters learned helplessness.

I understand that the yaourt developer(s) was scratching their own itch, and this post is not about maligning the project; but there are significant unintended consequences of giving people a tool that abstracts such a fundamental element of the distribution away from the user, especially for a distribution where you are expected to have complete control and responsbility over your system.

To be clear, I don’t have a complaint with the concept of AUR helpers. I used yaourt initially before switching to aurget and then alighting on cower, or more particularly, a partial wrapper for cower:

cowerd
#!/bin/sh
# install AUR packages with cower

cd $HOME/Build && cower -d "$1"
builddir="$_"
cd "$builddir" && ${EDITOR:-vi} PKGBUILD

makepkg -si && cd - &>/dev/null

read -p "Remove Build directory? [Y/n]? " yn
if [ "$yn" = "y" ]; then
    printf "\n%s\n" "Removing build directory..."
    rm -rf "$builddir"
else
    printf "%s\n" "Build completed."
fi

This provides me the minimum level of automation I require—essentially only around downloading and installing a package. It doesn’t automatically handle dependencies, nor manage updating the packages; that remains, rightly in my view, my responsibility.

If I were to look to a more fully featured wrapper, I would undoubtedly choose meat, however as on my desktop machine, I only have ~30 AUR packages installed, I don’t really need anything more sophisticated.

So by all means, use an AUR helper. But recognize that it is intended to help you, not preclude you from being able to accomplish the most simple and critical task of system maintenance, updating your package manager. Uninstall yaourt if you are using it and familiarize yourself with makepkg; once you do understand the relationship between the official repositories and the AUR, download cower or meat, they are both much better solutions.

Notes

  1. Myself included

Creative Commons image of crutches by net_efekt on Flickr.

Comments