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
The default name is
native.conf. The filename has to start with
native and end with
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.
The files are parsed by the Config::General module. They are key-value pairs, separated by whitespace, with the following exceptions:
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.
foo <<END here be stuff END
The make-vdt script will substitute variables from defs files in the standard way. For example:
The following syntax literally includes the contents of another 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.
license Apache version 2or
license <<END Apache version 2 ...full text of apache license here... END
The RPM epoch for the package (prefixed to the version). Most likely we won't have to use this at all.
A URL where you can find more information about the package.
A list of dependencies. There are multiple ways of specifying this:
depends gcc, perl
depends gcc depends perl
allplatform. For example:
<depends> rhap5 rpm, gcc, perl(Foo) deb5 dpkg vdt vdt-base </depends>
A list of prerequisites this package provides that may not be detected by the
packaging tools. Same syntax as
A list of packages this package will conflict with. Same syntax as
A list of packages this package obsoletes (i.e. obsoleted packages should be removed once this package is installed).
User-defined bash commands to be run during the build process. The
(relative to the buildroot) are defined.
BUILD_ROOT would be
VDT_LOCATION would be something like
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
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 ENDThe 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.:
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
build0 for purposes of ordering.
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_rpm2, etc. work as
build2, etc. do above.
build_rpm sorts after
build, such that
build_rpm2 section will be inserted after
bash commands to be placed in
setup.sh is sourced. Use this to set environment
variables, such as
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
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.
Shell commands to be executed directly before running the symlinker script (see above). This is for setting up shell variables.
<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
Empty directories to be created, e.g.,
/var/log/glexec. One on
dir /var/log/glexec dir $VDT_LOCATION/globus/log
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>
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
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.
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).
Flags regarding which attributes of a file to compare against the package
metadata when running
verify must be followed by a parenthesized, space-separated list
of attributes to verify for the given file. For example,
verify (owner group) /dir/fileThis line means that
rpm -Vwill only complain if the owner or the group of
/dir/filehas 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.confwill make
rpm -Vcomplain 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.
Files to be marked as documentation. rpmbuild can do special processing to these (e.g. gzipping them).
Directories to be marked as documentation. Everything in this directory will be considered documentation.
User-defined post-install commands.
VDT_LOCATION will be set.
post <<END cd $VDT_LOCATION . setup.sh vdt/sbin/vdt-gpt-postinstall END
User-defined pre-install commands.
User-defined pre-uninstall commands.
User-defined post-uninstall commands.
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 email@example.com - VERSION-RELEASE Did stuff. END
Space- or comma-separated list of options that affect autogeneration of certain features. Currently implemented flags are:
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 firstname.lastname@example.org - 22.214.171.124-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