PackagingGuidelines < DICE

DICE Web>PackagingGuidelines (19 Dec 2014, AlastairScobie) (raw view)EditAttach
---++!! Packaging Guidelines

%TOC%

---+++ Standards
---++++ 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.  -- Main.ChrisCooke - 30 Mar 2009 )

The [[http://fedoraproject.org/wiki/Packaging/Guidelines][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. ([[https://fedoraproject.org/wiki/Packaging:Guidelines#Use_rpmlint][Use rpmlint]])
   $ Changelogs: 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. ([[https://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs][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_ ([[https://fedoraproject.org/wiki/Packaging:Guidelines#Tags][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.
   $ Buildroot: Use a sane buildroot location: [[https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag][Buildroot]] and make sure to delete any existing one before using it.  
   $ Clean: Make the package clean up after itself - see [[https://fedoraproject.org/wiki/Packaging:Guidelines#.25clean][%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 [[https://fedoraproject.org/wiki/Packaging:Guidelines#Requires][Requires]] and [[https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires][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 [[https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership][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 [[http://fedoraproject.org/wiki/EPEL][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 [[http://blob.inf.ed.ac.uk/sxw/2008/03/27/using-packages-from-upstream/][Using Packages from Upstream]] tells you how to go about it.
---++++ RPM Naming Guidelines

There's [[https://www.wiki.ed.ac.uk/display/LCFG/RPMRepositoriesProposal#RPMRepositoriesProposal-naming][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

   $ world : 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.

   $ uoe : 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.

   $ inf : 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.

   $ lcfg : 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.

   $ updates : 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.

   $ extras : 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 [[http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/epel/5/][here]] for instance.

   $ devel : 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.




-- Main.StephenQuinney - 26 Feb 2008

-- Main.ChrisCooke - 13 Feb 2009
Topic revision: r11 - 19 Dec 2014 - 11:51:47 - AlastairScobie
DICE
This is WebLeftBar
Copyright © 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