Aaron Griffin (english)
Interview - Part II
I understand pacman was created specifically for Arch. Why create your own package manager?
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.
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?
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.