OSCAR Packager Manual

Geoffroy Vallee


Table of Contents
1. Introduction
2. Access to Source Code
3. Automatic Generation of Binary Packages
4. Generation of a Local Repository for the Storage of Generated Binary Packages
5. Scripts for Binary Package Creation Before OSCAR-5.2

1. Introduction

OSCAR is based on binary packages: both the OSCAR core and OSCAR packages are shipped and managed via binary packages. Those binary packages have to be generated for all new supported Linux distribution (module architecture independent binary package on Linux distributions having the same configuration). oscar-packager aims to ease the creation of those binary packages, generating them automatically for the local platform.


2. Access to Source Code

The generation of binary packages require the access to the source code of the software that needs to be packaged. The source code may be available in many different ways: tarballs, svn check-out, SRPMs. Since OSCAR components use those different methods of source code distribution, oscar-packager must hide those details to the packager and deal with this different configuration.

Because OSCAR is two kinds of components, core components and OSCAR packages, it is convenient to be able to compile one those groups of packages or both of them at the same time. Moreover, one may want to compile the stable version of the OSCAR components, others may want to compile the unstable (development) version. To do that, four configuration files are available:

  1. Two configuration files for core packages: one for the stable version and one for the unstable version.

  2. Two configuration files for OPKGs: one for the stable version and one for the unstable version.

Those configuration files describe how to access the source code of the OSCAR component to compile. The following example specifies that the stable version of ODA is available via SVN, at a specific URL:
      
[oda]
source  = svn,http://svn.oscar.openclustergroup.org/svn/oscar/pkgsrc/oda/tags/oda-1.3
              
    

oscar-packager does not aim to implement the policy regarding the storage of code source (for instance to guarantee we can repackage any release of OSCAR at any time). oscar-packager is only a simple tool that aims to enable the automatic generation of binary packages for OSCAR based on a description (though configuration files) of the location of the source code and the method to use for the actual creation of the binary packages.


3. Automatic Generation of Binary Packages

Once we have access to the source code, we need to know how to generate the binary packages. Typically, we need to:

  1. know the dependencies required for the creation of the binary package,

  2. specify some environment variables needed for the creation of the binary package,

  3. where to save the binary packages (the location is different for architecture independent and architecture dependent binary packages).

To specify this data, each OSCAR component must provide a build.cfg file. This capability is actually from a previous effort, initiated by Erich Focht from NEC Europe; we only extend it for the support of Debian packages.

With this data, it is possible to generate the binary packages: oscar-packager gets the source code, parse the build.cfg file and finally execute the command for the creation of the binary package. For that, oscar-oackages automatically detect the binary package format of the local Linux distribution.


4. Generation of a Local Repository for the Storage of Generated Binary Packages

In order to ease the usage of the generated binary packages, those binary packages are automatically copied into a local repository. This local repository is the standard OSCAR repositories, i.e., the different repositories available in /tftpboot/distro and /tftpboot/oscar.

!!WARNING!! Even if the repositories are fully functional, they won't be necessarly used by default by OSCAR, you MUST check the repository configuration files.


5. Scripts for Binary Package Creation Before OSCAR-5.2

build_all_rpms calls build_oscar_rpms and build_oscar_rpms calls build_rpms at the back-end