Packaging and Releasing Guidelines

This set of guidelines define how to produce proper packages.

RPM guidelines


Here is a summary of the guidelines provided by Fedora. The complete document is available at: Fedora Guidelines.

  • Dash '-' must be used as delimiter of name parts, no underscore '_' nor plus '+' are allowed
  • Even if they differ by case, package names conflicting with already existing ones are not allowed
  • The SPEC file name should be %{name}.spec
  • Subpackages such as doc, devel, etc. should be named with the main name and must use dash '-' as a delimiter. Examples are ssl-devel, httpd-doc.
  • Modules:
    • PERL modules should have a name with 'perl-' prepended
    • Python2 modules should have a name with 'python-' prepended
    • Python3 modules should have 'python3' instead of 'python'

  • RPMs versions are: VERSION and RELEASE
  • VERSION and release are delimited by dash '-'
  • No dash is allowed in the VERSION
  • To use a single SPEC file for different distributions, it is recommended to append the %{?dist} tag in the RELEASE field
  • Pre-release, Snapshot or post-release packages should have RELEASE as: 0.%{X}.%{TAG} where X is the release number increment and TAG is the descriptive string of the version. Examples are:
    • foo-1.4-0.1.20100610svn -> foo-1.4-0.2.20100619svn -> foo-1.4-0.3.20100701svn
    • foo-1.4-0.4.beta1 -> foo-1.4-0.5.beta2 -> foo-1.4-0.6.rc1 -> foo-1.4-0.7.rc2 -> foo-1.4-1
    • foo-1.4-1 -> foo-1.4-2.SP1 -> foo-1.4-3.SP2
  • To release bugfixes for old branches, the recommended way is to append a version after the %{?dist} tag in the RELEASE:
    • Release: 1%{?dist} becomes 1%{?dist}.1 so that foo-1.0-1.fc4 < foo-1.0-1.fc4.1 < foo-1.0-1.fc5

  • Primary architectures: x86, x86_64
  • Packages must successfully compile and build into binary packages for at least one primary architecture

  • All program binaries or libraries must be built from the code available in the source package
  • Content binaries such as .mo .pdf .png .ps are not required to be built from source
  • Source packages must not contain *.class *.dll *.DS_Store *.exe *.jar *.o *.pyc *.pyo *.egg *.so etc.

  • Spec files must be legible
  • Packager should not be used in SPEC files but rather in ~/.rpmmacros
  • Vendor is set by the build system
  • Copyright is deprecated, use License instead
  • Summary is a single line description not ending with a period
  • PreReq should be replaced by Requires
  • Source shuld be the complete URL to the upstream tarball. Examples:


Exceptions are explained here: Packaging:SourceURL

  • AutoReqProv feature of RPM should be enabled to let RPM to automatically find the requires and provides
  • If a requirement is so old that nobody has a version older, there is not need to include it
  • Epoch must be listed in versioned dependencies E:V-R (to find a Epoch of a package rpm --query --qf "%{EPOCH}\n" packagename )

Change Logs
  • A new changelog entry is required every time a change is made (any change of the package EPOCH-VERSION-RELEASE)
  • ONLY one of these three formats is allowed:

* Fri Jun 23 2006 Jesse Keating <> - 0.6-4
- And fix the link syntax.

* Fri Jun 23 2006 Jesse Keating <> 0.6-4
- And fix the link syntax.

* Fri Jun 23 2006 Jesse Keating <>
- 0.6-4
- And fix the link syntax.

SPEC File Templates

DEB guidelines

EMI guidelines


Owen Synge from dCache

We will find difficulty providing a source packages not containing jar files. While this is an intended goal for dCache to move over to better dependacy management systems such as Maven we are not in a position to start this process immediately.

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r5 - 2010-08-23 - OwenMillingtonSyngeExCern
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback