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

VDT Packaging Policy

Overview of Current Policies

Binary Packages

For now, the VDT contains binary packages, not source packages. The Linux distributions generally prefer source packages, but we are not ready to make that leap yet, because:

Questions

Package Separation

In line with the idea that we want to prepare our packages for standard distribution, we must separate the software components themselves — that is, packaging of upstream software — from VDT/OSG-specific packages, code, and configuration. We have discussed this goal for a long time under the name “configuration separation”.

Software components that require configuration will ship with a default, reasonable, working configuration. However, if need be, the initial configuration can be bare bones and leave the component largely unusable for its intended purpose within the OSG software stack.

Questions

Standard Packaging Conventions

When possible, we will follow the standard packaging conventions and rules of the Linux distributions:

However, there will be specific, (hopefully) temporary exceptions:

Details on our RPM packaging policy are contained in the VDT RPM package checklist.

Standard Components

When possible, we will avoid repackaging components that are available from other well-respected distributions, including the Linux OS distributions themselves. For example, our Expat build does nothing special, and so we should use a standard one instead of our own. But as a counter-example, we currently still modify Apache at build-time to work with GSI certificates, and so we must continue to supply our own.

Questions

Configuration System

The VDT/OSG packages that configure and integrate the software components will use a central, unified configuration system from the VDT. It will feature:


Last Updated: 2 September 2010