Documentations > Developer Documentations > OSCAR infrastructure > OSCAR Packages

As a deployment tool, OSCAR heavily uses packaging systems. Currently, distributions supported by OSCAR are based on RPM or .deb. Furthermore, software specifically packaged for OSCAR uses the opkg packaging system.

opkg packaging

opkg system is specific to OSCAR. It allows developers to describe software with a cluster-wide view and in a multi-distribution way.

The opkg description is then compiled with opkgc to produce packages in distribution native systems (RPM or deb).

Here are useful resources about opkg system:

• Describing a software with opkg
• The opkg compiler

RPM packaging

RPM are used to package OSCAR core system itself. Furthermore, you may create OSCAR packages which depends on software which does not already come in RPM binary format.

There are not any specific guidelines regarding how to build a RPM for OSCAR (they are not any different from building for Fedora or SUSE). We simply asked that you try your best to make the spec file as generic as possible such that it works on all our supported RPM-based distributions like Red Hat, Mandriva and SUSE.

Macroes such as %if %{?suse_version:1}0 are useful to determine what distribution you are building on and provide logic for different “Requires”.

The following are some good resources on how to build RPMs from scratch:

• Packaging Guidelines, by Fedora
• RPM guide, by Fedora
• RPM HOW-TO (rpm.org)
• Maximum RPM guide
• IBM Packaging software with RPM (3 part series):
  • Introductory
  • Building without root, patching software, and distributing RPMs
  • Part 3
• Specific notes for building RPM for OSCAR

Do not build debuginfo package

If you do not wish to build the debuginfo package, put the following in your spec file:

%define debug_package %{nil}

Debian packaging

As for RPM, you may use the Debian packaging system to describe OSCAR core system or to package third-part software which is not yet packaged in Debian.

Here are some useful resources:

• Official documentation, heavy but complete:
  • Debian Developer’s Reference
  • Debian New Maintainers’ Guide
  • Debian Policy Manual
• svn-buildpackage (maintaining packages with Subversion):
  • [http://workaround.org/moin/SvnBuildpackage]
  • svn-buildpackage official documentation

Specific notes for building Debian packages for OSCAR

Package validity

When uploading a Debian package on our repository, package validity is checked with the lintian tool. We strongly advise you to check the package yourself before uploading it.

Distribution

Each changelog entry contains a space-separated list of distribution name this version is aimed to. Valid values are stable, testing or unstable. Usually, Debian packages are written for unstable, and adapted to stable if necessary.

See Debian Policy Manual: Debian changelog for more details.

Section

The Section field in the control files indicates an application area into which the package has been classified. For OSCAR packages (core packages or opkg compiled into .deb), this section must be oscar. For other software (your updated package of lam, for instance), you must set Section to extra.See Debian Policy Manual: Section field for advanced details.

== Package signatures == #PackageSignature

All packaging systems allows developers to sign their packages. Then, we recommend to do it. If you don’t yet have a GPG key, use:

gpg --gen-key

and follow the instructions.

Useful resources:

• GnuPG Mini howto
• Signing Built RPMs, by Fedora
• GnuPG Mini-HOWTO for Debian (mostly applicable to others)

Package repositories

For instructions on uploading packages, have a look at Repositories for Developers page.

To get packages from repositories, have a look at Repositories page.

To know how OSCAR package repositories are maintained see Repositories Internals page.

Modification of the Default Package Set

Have a look at How to exclude OSCAR package from the default package set