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

Format of native.conf Files

The native.conf file is the description for packaging up an NMI build in an RPM. The VDTGlue.pm module has a function make_rpm which takes native.conf and a tarball, and creates a binary RPM.

The default name is native.conf. The filename has to start with native and end with .conf, since make-vdt does !!-substitution on those files. If you have an NMI build from which more than one package is derived (e.g., VOMS), you will have multiple .conf files, one for each package.

General Format

The files are parsed by the Config::General module. They are key-value pairs, separated by whitespace, with the following exceptions:

Sections

These are XML-style, e.g.:

<move>
  <destdir /etc/glexec>
    file foo
  </destdir>
</move>

The open/close tags may not be on the same line as anything else.

Here-Documents

Perl-style, e.g.:

foo <<END
here be stuff
END

Substitutions

The make-vdt script will substitute variables from defs files in the standard way. For example:

version !!PRODUCTION_VERSION!!

becomes

version 2.0.0

Inclusions

The following syntax literally includes the contents of another file:

include other-file

This works like the #include statement in C. Note that it does not do anything inside a comment or a heredoc. This can be used to put changelogs, long licenses, etc. in external files. The external file must be in the same place as the native.conf file--don't forget to add it to the filelist if you are submitting an NMI build. Config::General will die if the file is not found.

Required Fields

name
The name of the package.
summary
A one-line summary of what the package does.
description
A long (i.e. multi-line) description of what the package does.
version
The version of the package. Use !!FOO_VERSION!! to get it from the defs file.
release
The revision of the package.
license
The license for the package. String, can be single line or multi-line. If the license is long, it may be better to put the license field into a separate file and use the inclusion mechanism (see above).
license Apache version 2
or
license <<END
Apache version 2
...full text of apache license here...
END

Optional Fields

epoch

The RPM epoch for the package (prefixed to the version). Most likely we won't have to use this at all.

url

A URL where you can find more information about the package.

depends

A list of dependencies. There are multiple ways of specifying this:

provides

A list of prerequisites this package provides that may not be detected by the packaging tools. Same syntax as depends.

conflicts

A list of packages this package will conflict with. Same syntax as depends or provides.

obsoletes

A list of packages this package obsoletes (i.e. obsoleted packages should be removed once this package is installed).

build

User-defined bash commands to be run during the build process. The environment variables BUILD_ROOT and VDT_LOCATION (relative to the buildroot) are defined. BUILD_ROOT would be something like /var/tmp/vdt-globus-base-essentials-root and VDT_LOCATION would be something like /opt/vdt.

build <<END
./configure_glexec_native --native
find . -type f -print0 | xargs -0 sed -i -e "s,MAGIC_VDT_LOCATION/$VDT_LOCATION,g"
END

New: Sections named build1, build2, etc. will be added in order after the build section to create the overall build script. The purpose of this change is to allow common build-time code to be factored out into separate files which get included into the native.conf for each package. Example:

common.conf:
build2 <<END
# Do some other stuff here
END
native-package1.conf:
include common.conf
build1 <<END
# Do some stuff here
END
The build* sections will be combined to create something that looks like
# Do some stuff here
# Do some other stuff here

The sections do not have to be consecutively numbered, e.g.: build1, build3, build4 will be combined without error. If two sections have the same number, the order in which they are combined is undefined. Plain build is equivalent to build0 for purposes of ordering.

build_rpm

Same as build, but will only be run for RPM builds. This is used in gLExec, where the %_lib macro is used to figure out what to change the rpaths to.

build_rpm1, build_rpm2, etc. work as build1, build2, etc. do above. build_rpm sorts after build, such that a build_rpm2 section will be inserted after build2 but before build3.

setupsh

bash commands to be placed in VDT_LOCATION/setup.d, sourced whenever setup.sh is sourced. Use this to set environment variables, such as LD_LIBRARY_PATH.

setupsh <<END
export PATH=$PATH:$VDT_LOCATION/glite/bin:$VDT_LOCATION/glite/sbin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$VDT_LOCATION/glite/lib
END

links

A list of symlinks to create using the symlinker script. Looks like:

links <<END
/usr/bin -> $VDT_LOCATION/bin/*
END

See here for information on how this section should look.

links_pre

Shell commands to be executed directly before running the symlinker script (see above). This is for setting up shell variables.

move

Section for relocating files. The following example illustrates how it works:
 <move>
   <destdir /etc/sysconfig>
     file config1
     file config2
   </destdir>
   <destfile /etc/init.d/foo>
     file $VDT_LOCATION/initscript
   </destdir>
 </move>
 
 will become
 
 mkdir -p $RPM_BUILD_ROOT/etc/sysconfig
 mv -f $RPM_BUILD_ROOT/config1 $RPM_BUILD_ROOT/etc/sysconfig
 mv -f $RPM_BUILD_ROOT/config2 $RPM_BUILD_ROOT/etc/sysconfig
 mkdir -p $RPM_BUILD_ROOT/etc/init.d
 mv -f $RPM_BUILD_ROOT/$VDT_LOCATION/initscript $RPM_BUILD_ROOT/etc/init.d/foo

dir

Empty directories to be created, e.g., /var/log/glexec. One on each line:

dir /var/log/glexec
dir $VDT_LOCATION/globus/log

perms

Set permissions on a file, if the permissions in the SVN checkout are not correct or will not be carried over to the installation intact. Example:

<perms $VDT_LOCATION/glexec-osg/sbin/glexec>
  owner root
  group root
  mode 6755
</perms>

config

Files to be marked as config files (won't be overwritten on upgrade). One on each line. On erase, they will be removed unless they have been changed.

config /etc/sysconfig/foo
config /etc/init.d/foo

config_replace

Files to be marked as config files that may be overwritten on an upgrade but backups will be saved. On erase, they will be removed unless they have been changed.

ghost

Files to be marked as ghost files. Ghost files are files that are considered to be owned by the package, but are created after the bits are laid down at install time. The files will be removed at uninstall time (though not on an upgrade).

verify

Flags regarding which attributes of a file to compare against the package metadata when running rpm -V.

verify must be followed by a parenthesized, space-separated list of attributes to verify for the given file. For example,

verify (owner group) /dir/file
This line means that rpm -V will only complain if the owner or the group of /dir/file has been changed since the file was laid down. If the first element of the list is not, then all attributes except those given are verified. For example,
verify (not md5 size mtime) /etc/foo.conf
will make rpm -V complain if the md5sum, the size, or the modification time was changed for /etc/foo.conf. This is useful if the post-install script modifies the file.

Note that only one file or file glob can be given per line.

See the relevant section of Maximum RPM for a list of attributes.

doc

Files to be marked as documentation. rpmbuild can do special processing to these (e.g. gzipping them).

docdir

Directories to be marked as documentation. Everything in this directory will be considered documentation.

post

User-defined post-install commands. VDT_LOCATION will be set.

post <<END
cd $VDT_LOCATION
. setup.sh
vdt/sbin/vdt-gpt-postinstall
END

pre

User-defined pre-install commands.

preun

User-defined pre-uninstall commands.

postun

User-defined post-uninstall commands.

changelog

Custom changelog. Unfortunately rpmbuild is finicky about how the date is entered — see below for an example. The rest of the format seems to be fairly open, so indented paragraphs separated by blank lines should be fine (and readable).

It may be better to put the changelog field into a separate file and use the inclusion mechanism (see above), especially if you are making multiple packages in the same build.

changelog <<END
* Mon Oct 11 2010 matyas@cs.wisc.edu - VERSION-RELEASE
        Did stuff.
END

flags

Space- or comma-separated list of options that affect autogeneration of certain features. Currently implemented flags are:

Examples

This is the native.conf file for voms-essentials. Note the setupsh section, which requires the dependency on vdt-compat to work.

name                voms-essentials
version             !!VOMS_RPM_VERSION!!
release             2.p1.1
summary             Virtual Organization Management Service essential libraries
description         <<END
VOMS stands for Virtual Organization Management Service. It manages membership
lists and roles for a virtual organization (VO). For example, a group of twenty
scientists across three universities might collaborate with each other for a
long-lived experiment. In order to keep track of who is in their virtual
organization, they use VOMS. VOMS can keep track of each user, and their roles.
For example, the principal investigator might have the role of "TechLead",
while others do not. Other grid software such as EDG mkgridmap and GUMS can
consult VOMS to decide if a user is part of a virtual organization.

Users are described by their X509 certificate's Distinguished Name, so all
users must have X509 certificates.

VOMS is provided by INFN in Italy, and is part of the gLite project. 
END
url                 !!VOMS_URL!!
license             Apache License, version 2.0

depends vdt-compat

setupsh <<END

# From VOMS-Environment
export VOMS_LOCATION=$VDT_LOCATION/glite
export VOMS_USERCONF=$VDT_LOCATION/glite/etc/vomses

END

changelog <<END
* Fri Nov 12 2010 cat@cs.wisc.edu - 1.8.8.2-2.p1.1
        Changed dependency from vdt-base to vdt-compat.
END

This is the native.conf file for the xrootd binaries. This is somewhat more complicated. Note the links section and the include parts.

name            xrootd
version         !!XROOTD_RPM_VERSION!!
release         !!XROOTD_RPM_RELEASE!!
summary         Xrootd client and server applications

description     <<END
Xrootd is a high-performance network file system designed for large data
files in the grid world.

This package contains client and server applications for Xrootd.
END

url             !!XROOTD_URL!!
flags           make_debuginfo_packages

build           <<END
rm -rf $BUILD_ROOT_VDT/xrootd/bin/xrootdutils/CVS
rm -f  $BUILD_ROOT_VDT/xrootd/etc/rpm.spec.template
END

<perms $VDT_LOCATION/xrootd/bin/xrootdutils/installOpenAFS.sh>
    mode 755
</perms>

<perms $VDT_LOCATION/xrootd/bin/xrootdutils/installOpenSSL.sh>
    mode 755
</perms>

# Gets rid of "script-without-shebang" warnings from RPMlint
<perms $VDT_LOCATION/xrootd/bin/xrootdutils/*.pm>
    mode 644
</perms>


links           <<END
<skip>
    $VDT_LOCATION/xrootd/bin/xrootdutils
</skip>
/usr/bin        -> $VDT_LOCATION/xrootd/bin/*
END

doc $VDT_LOCATION/xrootd/etc/*.example
doc $VDT_LOCATION/xrootd/etc/xrootd.cf.example2
doc $VDT_LOCATION/xrootd/etc/example.*.cfg
doc $VDT_LOCATION/xrootd/etc/README


include         xrootd-changelog.conf
include         xrootd-license.conf

depends         xrootd-libs = !!XROOTD_RPM_VERSION!!-!!XROOTD_RPM_RELEASE!!
conflicts       xrootd-essentials <= 20100315.1007-1.vdt2