Interview - Part II
I understand pacman was created specifically for Arch. Why create your own package manager?
Makepkg is a tool using information stored in a PKGBUILD file to create packages for ArchLinux. These packages can then be installed using pacman.
ABS is a tool to download PKGBUILDs for the packages in the official repositories, allowing the user to compile their own packages from source.
PKGBUILDs are text files containing the necessary information to compile a package from source. This includes where the source can be retrieved from, what compilation options will be used, for which architecture can it be buildt upon, what license does it use... Anyone can create a PKGBUILD, and if you want you can share the PKGBUILD with your fellow archers on the AUR (Arch User Repository).
Pacman was created because, everything else is just too complex. Other systems needed 7 tools and had complex package formats. Pacman attempted to be simple and straightforward.
AUR allows users to upload their own PKGBUILDs for everyone to enjoy. When did the AUR idea come on the table?
The AUR started ages ago. It was originally called the TUR or Trusted-User Repository, where we had a group of people who each had their own repos that we officially supported. There was no real web interface or anything like that until we began discussing combining everyone's repos into one central repo, [community].
The AUR now exists and is ever evolving. There is usually a lot of activity on our aur-dev mailing list, where people help develop the AUR interface and overall experience.
Click to view a larger version of this image
Using AUR and a front-end like yaourt, you're able to install packages in an easy fashion even though they're not officially supported in the repositories. Why don't pacman have an option to compile packages from AUR? Or why isn't front-ends like yaourt added to the community repository?
The Arch User Repository
The AUR is actually two repositories where the users are in charge. In the [unsupported] repository, anyone can upload their PKGBUILD file. Users can then find and download this PKGBUILD through the AUR web interface. If they like the PKGBUILD, they can vote for the package. A PKGBUILD with a lot of votes has a big chance of making it into the other repository, [community].
[community] contains binary packages which can be installed through pacman. Because of this, packages not following the Arch guidelines will not make it into this repository, like yaourt. The [community] repository is controlled by a group of Trusted Users (TUs). These are people who have contributed a lot of safe PKGBUILDs to [unsupported] in the past, and who has probably helped out in some other ways.
Firstly, pacman will never compile apps from source. It's just not what it does. Having that feature would be like having cp also list directory contents. It makes no sense. In Unix Philosophy speak: one tool for one job.
There are far too many security risks with the auto build tools. That is not to say that we think our users are dumb. We believe that if you want to take the risks, you're more than welcome to. However, there should be a slight barrier to enable these security risks. One shouldn't be able to accidentally enable AUR auto-installation.
Having these auto-build tools in the official repos, is the same as us giving a head-nod to all the PKGBUILDs in [unsupported]. It's like us, the developers of the core of the OS, saying "Sure, go ahead. It's fine". The problem is, it's not fine. It's a security risk that everyone should be aware of.
How are the repositories set-up? What are the restrictions on the different repositories?
The [core] repo contains the "Core of ArchLinux". That is, it contains all the packages that MUST be in perfect working order to make sure your system continues to run. These are the absolute system-critical packages. We are very picky about what packages end up in [core].
However, [extra] is much different. Extra generally contains all the extra packages that we feel an OS should support, but are not system critical. Sure, some of these packages, such as apache, may be critical to some users, they are not critical to ALL users. We try to keep the number of packages in [extra] under control, simply because we may end up with too many packages that no one has time to maintain in [extra].
The [unstable] repo contains software we want to have in extra but is too unstable at the moment. Sometimes we also officially support version-control based packages in there (at the moment, I believe [unstable] contains a svn build of mplayer).
The [testing] repo is where we test our packages before they hit core and extra. We require that all core packages spend some time in testing, so that we can ensure a working machine, but extra packages are left to the developer's discretion.
The [community] repo is managed by the Trusted Users, and the AUR users. Packages usually end up in [community] based on AUR voting, or simply if a Trusted User likes and uses the package.
Why not combine the [extra] and [community] repo?
They are managed by two different groups of users, in different ways. I have actually thought about this, but with our current infrastructure, it is impossible. One nice idea would be switching the repos to SVN, and using AuthZ based permissions to make sure that the TUs and official Developers don't overlap and fiddle with the wrong packages (a new TU editing and breaking apache, for instance, wouldn't be appretiated).
Do you know the future plans for improving pacman?
Hmm, anymore I don't spearhead the pacman development. Dan McGee is in charge of that, and he does an amazing job of it. We have a lot of active developers working on things too. As far as future developments go, I'd imagine it's more code-oriented than anything else. We'd love to see a clean and intuitive interface to libalpm (the back-end library for pacman) so that other people can more freely develop front-ends. Right now it's a tad difficult to work with.Neste side