Note: This web site is only kept up to date for OSG Software 1.2 (VDT 2.0.0). If you are looking for information for the most recent release, the RPM-based OSG Software 3.0, please see the OSG documentation web site

Why the VDT uses Pacman

Update: December 2004

When we began the development of the VDT, we needed to decide how to package the VDT. Many options are available, including RPM, GPT, Pacman, and more. So why did we choose Pacman?

First, we examined the software that we needed to install and discovered that it was packaged in a variety of ways:

As we looked at the different ways that the software was packaged, we realized there were a couple of approaches we could take in creating the VDT. First, we could repackage all of the software in a uniform way -- perhaps with GPT or RPM. This would require a great deal of effort that would need to be redone for each new release of software. Alternatively, we could use a flexible packaging mechanism that allows us to work with all of the different software packaging schemes that are available.

We decided on the second method. This wasn't just a choice of expediencey. We expected that a lot of software would be included in the VDT and that it would be extremely difficult -- if not impossible -- to repackage all of the software with a common packaging mechanism.

Pacman has several advantages that enable the VDT to work with a wide variety of software. Pacman is able to download arbitrary files and run a set of commands to install the software. The commands can be different for each set of software -- we can install Globus with GPT, ClassAds with make and VDS with tar. Pacman is a level above GPT and RPM: it can install any software, however it is packaged. Additionally, Pacman allows us to specify dependencies between software packages, no matter how the software is packaged. Condor is installed with a custom installer and it depends on Globus, which is installed with GPT before Condor is installed.

Pacman also has several other advantages, such as helping users set up their environments and knowing where to get the software from. These advantages are described on the Pacman web page.

An update

It's been several years since the VDT team initally decided to use Pacman. In that time the VDT has changed considerably and many of our inital reason are no longer valid. That said, the additional experience we've gained over the years has given us several new reasons to stay with Pacman.

As it stands today, the VDT distributes all its packages as tarballs with pre and post install scripts. It would be fairly easy for us to convert the VDT into a set of RPMS (in fact, we're working on this right now). However, those RPMs would only be useful on a small subset of the platforms that we now support. Pacman lets us create a single package that work on RedHat, Debian and AIX. Pacman lets us deal with the heterogenuity of the grid in a way that no other packaging system would.

In addition to different platforms, Pacman lets us install the VDT as root or non-root users. Most packaging schemes are designed to maintain a single computer, not to handle several user-space installation.

While we're working on making RPM and Debian packages of the VDT, those are designed for users who've already invested heavily in a different packaging format. Without Pacman the VDT would not be what is today.