Why AUR is part of the Arch Linux success

November 1, 2011

If you usually follow some blogs about Linux, especially those on Arch Linux, there is a common word that you are come across often, AUR, acronym of Arch User Repository. You might wonder what does it mean, what does it imply for the distribution, and why it’s so popular for the Arch Linux community. If you asking yourself those questions, this post is for you.

First, you should keep these two characteristics in mind.

AUR is a kind of repository totally public, open to whoever want to contribute to let some resources available to anyone. No ceremonials, agreement or long ritual initiation to submits a package to AUR.

It’s as easy to contribute to AUR as to use it, with some AUR helpers such as yaourt or others alternatives. Install a package from AUR isn’t more difficult than install one with the official package manager pacman, manager such as apt-get for Debian or Ubuntu. Dependencies and research are easily managed that way. Even a vote system allow credibility about security and code source of a package.

The main idea about packaging for AUR is to write some installation directives in a file called PKGBUILD, by simply follow some easy packaging’s rules. That’s what AUR contain, only directives that gives instruction to the helper on how to build the package. There aren’t binary packages in AUR.

The fact that a PKGBUILD is easy to write increase the idea that everyone can contribute to AUR given that the repository is open to everyone. If you managed to install Arch Linux by yourself, you should be able to find out how to write PKGBUILD. Of these two ideas, easy to contribute, and for everyone, resulting implications very beneficial for Arch Linux.

For example, a person who have some practice with it, can make a script or a program available within few minutes (which was the case for example to offer hacker-top and reddit-top a bit on a whim). If more time was needed, would I have done it? probably not. This is also beneficial for the user, so you may easily enjoy interesting programs that would not be known however.

This simplification of the provision also encourages some exotic applications, with for example some very recent drivers that would not be incorporated otherwise. But also with the latest programming frameworks in vogues. Knowing that a framework can gain very big reputation in a short time. So latest framework can be available easily and quickly to users. Most importantly, it allows them to be updated, This is important if the evolution is rapid. For example, if I try Node.js, I do not want the version of last year, but the latest. Same for Ruby on Rails, I do not want to watch a version of Ruby, which may not be compatible with the latest Rails. This last example taken from a real example, when we saw on the forums concerns about running Rails with version 3, especially for Debian. All installed cleanly with a packet manager, not by hand as we see often advisable in such cases.

All this convenience, and the non-formality could even be quantified. The website, front-end of AUR, announces 32,000 packages available for archers, it’s more than 29,000 packages debian announced on their home page. So I know that is not the same and that is not far from being a troll, but it is a fact that Arch Linux has a community and a number of developers much less important than Debian, and is undeniable, for this system, Arch Linux is able to offer to his users almost as many packages.

From the maintainer’s point of view, those concerned with the [community] repository, they can easily demote a package in AUR so it was officially supported, without worrying to much about consequences, associated with the fact that Arch Linux only supports two architectures, not dragging dozen architecture to their credit. these two points I believe are the key to their reactivity, and can keep a small core team (no more than two dozen core-dev, without TU’s). A responsiveness of a small team to a rolling release enough stable to interest a median users of Linux.

AUR also allows a developer to easily share its application, whatever the language chosen, each language generally offers opportunities, such as pip (python) gem (ruby), it is still nice to have an opportunity to ensure the smooth running of installation on its own distribution. Simplify installation and distribution of software that is not known and still under development, is a good way to promote an application. Furthermore, PKGBUILD allows be easily coupled to a manager for review as git or svn, allowing for easier returns on development issues by an user.

Among all these points, everyone’s winner, from the median user to developers. I hope that with these explanations, far from being exhaustive, the success of the AUR for Arch Linux is more clear implications that can be blurred at first.

Without AUR, Arch Linux would no longer be the same.

Edit: More comments on Hacker News, or on Reddit.

Tweet

Related-ish Posts

About

I'm Nicolas Paris, aka Nic0, I like to share about programming and Linux tricks. Follow me on Twitter, where the content is pretty much like here, mainly programming stuff. Or visite my website