Packaging Guidelines


Follow the Fedora Package Guidelines

(When I wrote this section I didn't know about our FedoraPackaging page which has loads of helpful advice on making Fedora-compliant packages. You should most definitely look at that page as well as this one. -- ChrisCooke - 30 Mar 2009 )

The Fedora Packaging Guidelines are a great guide to making a good package. Some of the advice is Fedora-specific but most of it is widely applicable. Here are some highlights - but do read the guidelines themselves to find more:

Use rpmlint
Run rpmlint on the rpms to examine them for common errors, and fix them (unless rpmlint is wrong, which can happen, too). If you find rpmlint's output cryptic, the -i switch to it can be used to get more verbose descriptions of most errors and warnings. (Use rpmlint)
Every time you make changes, that is, whenever you increment the E-V-R of a package, add a changelog entry. This is important not only to have an idea about the history of a package, but also to enable users, fellow packages, and QA people to easily spot the changes that you make. (Changelogs)
Source Tag
Your Source tag should be a complete URL to the (upstream) tarball.
Packager Tag
This is one area in which we differ from the Fedora guidelines. Fedora uses the standard definition of the Packager tag, which is roughly the person who built this package (Tags). This is not necessarily the person who maintains the software or even the person who wrote the spec file. By contrast we in Informatics generally take the Packager tag to indicate the author of the software, and our LCFG buildtools makes this connection automatically. If your package is going to be passed upstream you should adhere to the Fedora guidelines for the Packager tag. If it's for local and downstream use you should use it to indicate authorship.
Use a sane buildroot location: Buildroot and make sure to delete any existing one before using it.
Make the package clean up after itself - see %clean for details.
Requires and BuildRequires
At some point we'll be moving to a build system based on mock in which packages are built in a clean environment shorn of most of the packages you know and love. You should craft your BuildRequires appropriately. See the Fedora Requires and BuildRequires sections for some sensible advice on this.
File and Directory Ownership
Your package should own all of the files it installs. It should not own any file that's already owned by another package. This doesn't always hold for directories though - see the discussion in File and Directory Ownership for details.

Test your package with rpmlint

Consider making your package pass the rpmlint test.

Use cpanspec, not cpan2pm

If you need to package a Perl module (which should only be the case if we don't have it already - see the next section) then use cpanspec to generate packages for Perl modules rather than cpan2rpm.

Prefer Extras, then EPEL, then Fedora

If your desired software isn't installed already,
  • look first in the extras bucket. If a suitable version is there, use it.
  • The next option is to look for an EPEL package. For SL5 look for "Fedora EPEL 5" packages. If you find a suitable package, ask the MPU to update our extras bucket, then use the package from there.
  • Failing that you can try building a package from a Fedora source package. Simon's blog post Using Packages from Upstream tells you how to go about it.

RPM Naming Guidelines

There's an agreed set of RPM naming guidelines for the shared RPM repository maintained by IS Desktop Services. We should stick to the same naming guidelines. Informatics' local identifier string is inf.

Always change the number

When you change anything about a package you must always change one of its numbers. It doesn't matter how trivial the change is. There must never be two packages with the same name-version-release string but different contents.

Package Buckets

With one important exception, if a locally built package can be freely distributed in a binary package form then it should, whenever possible, go into the 'world' bucket. We expect this bucket to hold the majority of software we build. The exception is LCFG component packages (with names beginning "lcfg-"), which should go into the 'lcfg' bucket, not into the 'world' bucket.

If a locally built package can only be distributed within the University of Edinburgh then it should go into the 'uoe' bucket. For example, a rebuilt firefox, including the EUCS certificate, is not world distributable but should be ok within the University.

The 'inf' bucket is for two types of binary packages: those which are license restricted to the School of Informatics and those which should not be externally distributed for security reasons. We expect this bucket to contain only a few packages.

This bucket should be used for submitting LCFG component packages (rather than putting them into 'world' for instance). Also note that whenever possible we want to put LCFG components into the 'lcfg' bucket, even if you don't think it is useful for anyone outside of Informatics, you never know how it might help other people.

base or distro
This bucket contains the packages provided as the core of the distribution (e.g. SL5). This is managed by MPU, you should never need to submit packages into this bucket.

This bucket contains any (security/bugfix) updates to the core made by the distributor. This is managed by MPU, you should never need to submit packages into this bucket.

For the "Fedora Core" platforms this is the extras packages distributed by the Fedora Project. For Scientific Linux this is the "extras packages for enterprise linux" (epel) packages. This is managed by MPU, you should never need to submit packages into this bucket. You may however occasionally want to ask the MPU to update the extras bucket with recent EPEL packages, as we only update extras perhaps once a month. You can check Fedora EPEL 5 packages here for instance.

This bucket is for testing packages. It is only visible to machines using the develop release. When you have finished your tests, you should submit the production version of your package to one of the other buckets, not to devel.

Further Notes

The names 'uoe', 'world' and 'inf' have been deliberately altered from those we used before (i.e. made different to the 'ed' and 'dice' header/package levels) to make it clear that the buckets are to show licensing restrictions and not to reflect at which level the packages are being used.

The 'dice' and 'ed' buckets are now to be considered deprecated and submission to these buckets is prevented by rpmsubmit. They will remain available for machines to acquire packages.

-- StephenQuinney - 26 Feb 2008

-- ChrisCooke - 13 Feb 2009

Topic revision: r11 - 19 Dec 2014 - 11:51:47 - AlastairScobie
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies