One of the biggest advantages to using Arch Linux is having access to the Arch User Repositories (AUR). This allows packages which are not included in the official repositories to be provided all in one place. I much prefer this to (for example) Ubuntu PPAs which require a user include a separate PPA for every package they wish to install, and these may change with package updates. The reason such repositories exist in the first place is to allow a cohesive way for users to install packages through their system’s package manager more easily, instead of simply building and installing directly from source.
With Arch Linux, it’s made very clear that everything on the AUR is provided by the community, meaning that anyone can upload nearly anything as a package (I even have a few packages I maintain there). As such, the package manager pacman will not, on it’s own, build and install packages directly from the AUR. The user is required to handle all of that themselves. Because of this, 3rd party tools known as AUR Helpers come into play, which make it easier for users to install AUR packages.
When I first installed Arch Linux and discovered the wonders of the AUR, the first helper I installed was yaourt. I did this based on recommendations from different guides I read, and it worked fairly well. I have since then switched to pacaur out of community recommendation, but I now have a better understanding as to why. On the arch wiki there is a comparison table for different AUR helpers. This lists certain features they may have, and to what degree the helper implements it. Of these, the two I find more important to focus on are the first two: security and clean builds.
The security feature means that, before any files used to build the application are downloaded, the user is prompted to inspect what the package will be building (looking at the PKGBUILD file) and any installation scripts. This is important, if at the very least as a reminder that any package on the AUR may be malicious. It is highly recommended to inspect PKGBUILDs before the package is even downloaded, to know what you’re getting.
The clean build feature means that existing environment variables will not be exported, and a clean shell is used for the build process. Environment variables may be active or loaded due to some previously executed commands in the current shell, or possibly loaded from elsewhere (i.e. .bashrc). It’s possible that such variables may influence the building process, resulting in a broken or failed build.
Of all the features listed (currently 6), pacaur presently supports all of them, while yaourt only optionally supports one. Neither security nor clean builds are configured in the way yaourt works. While it is my understanding that it would not take much effort to add support for these to yaourt, I have on several occasions now seen users fail to build a package as consequence. One of these, where I was able to recommend using pacaur instead, resulted in a successful build.
Along with this, there are some features of pacaur that I like to use. Most notably is its ability to check for updates. By issuing the -k flag, pacaur will list not only available updates for official packages, but ones on the AUR as well. Some packages use git commits to determine package versions, and while pacaur cannot immediately detect updates for these, the –needed flag will prevent such packages from being updated when the most recent commit to git has not changed.
Overall, I find pacaur to be solid to use. Its seamless integration of pacman functionality and useful feature set make it my first choice as AUR helper. I don’t hold a grudge against yaourt, as it has served me well for the better part of a year, but I can undeniably say I’ve found something better.