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
- Make binary packages
- Separate packages for upstream software and VDT configuration
- Follow standard packaging conventions (with exceptions)
- Use standard components from Linux or other distributions
- Configuration packages will use a central, unified configuration system from the VDT
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:
We have no mandate to produce distribution-ready source packages yet. Alain and Tim are proposing to include source
packaging in OSG Prime.
The NMI build system does not support building native packages using standard ways. In particular, we need to be
able to install prerequisite packages at build time, ideally by inspecting the dependency metadata contained in the
source package. However, the normal method for installing packages requires root. Further, we prefer to do builds
using “clean-build” tools (i.e., mock for Red Hat-like systems), which also requires root to create a
How will we build Globus Toolkit and the things that depend on it? We do not have an NMI build for GT, so we cannot
directly apply the existing technique of piggy-backing on NMI. Further, we have started an excellent set of
packages for LIGO that build from source, and we know that we must extend them to include pre-WS GRAM and the
jobmanagers. Maybe we build these packages by hand.
How will we build Debian binaries at all? Even simple Debian binary packages need at least some Debian development
packages installed on the build machine. Do we just ask NMI nicely to install any build-time prerequisite packages?
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
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.
- How do we name the just-the-bits packages and the VDT/OSG packages?
- What are the canonical dependency relationships between packages?
- What does it ultimately look like to install a significant set of packages on an OSG site?
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:
As stated above, we are not creating source packages.
Filesystem organization: For now, we will install all software in /opt/vdt. When possible, a VDT package should
treat /opt/vdt as the root of the standard filesystem and organize files within to conform to standard filesystem
layouts. In that case, we should find ways to add paths within /opt/vdt to standard environment variables such as
PATH, MANPATH, and LD_LIBRARY_PATH. If it is not possible (within reasonable time constraints), a VDT package may
make a subdirectory off of /opt/vdt to include its contents (e.g., /opt/vdt/globus). In that case, we should use
the filesystem symlinking tricks started with the LIGO packaging to make it appear that the binaries, man pages,
etc., are in standard locations. For Debian, all packages should use the symlinking tricks, because there
is no standard mechanism for modifying users’ environment variables.
We are making packages only for our supported platforms, not all platforms supported by the distributions.
Details on our RPM packaging policy are contained in the VDT RPM package
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.
- What standard distributions should we recommend (per platform)?
The VDT/OSG packages that configure and integrate the software components will use a central, unified configuration
system from the VDT. It will feature:
- The ability to turn Big-P parameters into little-p settings
- A way to document how each Big-P parameter affects little-p settings
- The ability to read and write configuration settings from files in config.ini format
- A central repository for installation-wide configuration settings
- A means of running all post-installation configuration steps from a single command
- Significant reuse of existing configuration scripts
Last Updated: 2 September 2010