Arch User Repository

See Time For a Change for the first in this series, or check out the index for all the posts on Arch Linux. Today I'll get the Arch User Repository working, which will let me configure my email, calendar, and contact integration.

Setting Up the Arch Build System
I briefly mentioned the Arch User Repository (AUR) during the Moneydance installation, and during that rollercoaster ride I actually used it in a failed attempt to get Moneydance working. Since it didn't pan out, I didn't include that as part of the post. But in order for Kontact to integrate with Google Calendar and Contacts, I will definitely need the AUR.

The Arch Way stipulates that everything should be kept as simple as possible - not for the user/administrator, but from a software dependency perspective - so only truly globally-useful software should make its way into the supported package repositories. That means that a great deal of very valuable software either doesn't have a wide enough target audience, or is too encumbered by pervasive library dependencies, or simply doesn't have the bullet-proof cross-platform support necessary to let it graduate into the big leagues. There is still a wide market for these packages, however, so the Arch team developed the Arch User Repository to hold the grab bag of all these fringe applications. This may sound a little Wild West - and it is - but consider the alternative that Windows users deal with every day. If you want something for Windows, you go find it online, download it, install it, and hope it works. It is a slightly different process for every application on your computer, which means that all the version management, update management, dependency checking, and distribution is multiplied by the number of applications on your hard drive. What a waste! By providing a central repository for stuff like this, Arch gives us a single place to look to see if anyone else has configured a given application and made it available.

To use the AUR, I needed to install and configure the Arch Build System. If you're trying to do this yourself, pay close attention to whether I'm giving root (#) or user ($) commands from here on. There are very good reasons not to use root unless absolutely necessary when working with the AUR.

# pacman -S abs
# abs
# abs

I ran abs twice because the first time after installation it sets up its own internal indexes but fails to download any updates. The second and every subsequent time it updates everything from the Arch Mothership. This is a lengthy process, so I went and made some coffee while I waited.

Using the AUR
Now that the ABS is set up, I can use it to get, build, and install the two Google-integration packages I will need in the next post. First, we have libgcal: this is a Google Calendar library that other applications can use to access Calendars. Second, we have akonadi-googledata, which gives Akonadi the ability to communicate with Google Information Servers. Akonadi is the KDE-wide framework that gives access to personal information like email, calendars, and contacts to applications written to use it. Tying everything together, akonadi-googledata uses libgcal to interact with Google Calendars. If this seems complicated and error-prone, then it's because you are a very perceptive reader. Most of my swearing and hair-pulling with KDE is caused by Akonadi.

There is an easier way to install packages from the AUR than manually using ABS, as I do below. This easier method, called yaourt (which stands for Yet AnOther User Repository Tool), itself must be set up via the ABS. Since the two packages I need for this step are so simple to do manually, there really isn't any reason to install yaourt to get this job done.

To get started, I made an abs subdirectory under my home directory, and downloaded libgcal and akonadi-googledata from the AUR into that subdirectory, extracting them there as well. The URLs below aren't magic; I just went to the AUR and searched for the packages, and then ran their URLs through bit.ly so they would fit on one line.

$ mkdir ~/abs ; cd ~/abs 
$ wget http://bit.ly/sJXtXi # libgcal
$ wget http://bit.ly/tZyrQz # akonadi-googledata
$ tar xf libgcal.tar.gz
$ tar xf akonadi-googledata.tar.gz

At this point, both packages are ready for building in ABS. Since akonadi-googledata depends on libgcal, I did libgcal first and akonadi-googledata second.

$ cd libgcal ; makepkg -si libgcal
$ cd ../akonadi-googledata ; makepkg -si akonadi-googledata

Makepkg is part of the ABS, and will read all the meta-files in the AUR tarball, downloading, compiling, and installing as necessary. With the -i flag, it creates a package that can be installed with pacman. With the -s flag, it goes ahead and automatically installs with pacman, asking for my password so it can sudo that operation. You should only use the -s flag if you know and trust the package. AUR packages are scripts and software, provided by other users, that you are using super-user privileges to install onto your system. In the unlikely event that there is malware in a package, you are giving it carte blanche on your computer. So be careful!

The commands above both output a tremendous amount of stuff, most of it very scary to non-developers. But they do their jobs, limiting their interaction with me to "what's your password" and "please confirm you want to do this", and a quick verify afterward yields good results:

# pacman -Q libgcal akonadi-googledata
libgcal 0.9.6-1
akonadi-googledata 1.2.0-1

Next: Configuring Kontact
Or check out the Index.