Linux System packaging guidelines

From Wiki [en] OpenMandriva
Jump to: navigation, search

This page gives a selection on guidelines and decisions we follow for packaging.

Contents


things to mention here:

pkgconfig-reqs, ld.gold, no-versions-in-names, just-one-version-in-main,...


general specfile layout

General requirement: separate sections with newline.

A specfile consists of different sections. Please separate each section with a newline.

Example:

%package    progs
Summary:    Tools to %{name}
Group:      Development/C

%description progs
AA-lib tools.

start with macro definition

The first section of a specfile always should be the macro definitions. If no definitions are needed (seldom) it may be blank. Example:

%define major   1
%define fname   %{name}-1.4rc5
%define libname %mklibname aa %{major}
%define devname %mklibname -d aa

name, version, release & sources

The next part of the spec should provide all neccessary information about the software and where to get it:

Summary:    AA (Ascii Art) library
Name:       aalib
Version:    1.4.0
Release:    0.rc5.27
License:    LGPLv2+
Group:      System/Libraries
Url:        http://aa-project.sourceforge.net/aalib/
Source0:    http://prdownloads.sourceforge.net/aa-project/%{fname}.tar.bz2
Patch0:     %{name}-info.patch
Patch1:     aalib-rpath.patch
Patch2:     aalib-1.4-automake18.patch
Patch3:     aalib-1.4.0-automake-1.13.patch
Patch4:     aalib-1.4.0-texinfo-5.x.patch

As you may have noticed, this includes which patches are included.

Requirements needed to build the package

The third part of the specfile is the place where the build-requirements of the package are to be defined:

BuildRequires:  gpm-devel
BuildRequires:  pkgconfig(slang)
BuildRequires:  pkgconfig(x11)
BuildRequires:  texinfo

devel-dependencies in spec-files

please use pkgconfig-requirements instead of requiring devel-packages:

fine:
BuildRequires:  pkgconfig(pango)
bad:
BuildRequires:  pango-devel

just one version in main

In cooker/main should just one version of a software or library be included, if possible. As an example we favor one postgresql package, over having postgresql8.4 and postgresql9.0 both in main.

  • If there's a need to support another program version we favor moving it into cooker/contrib.
  • If there's no need to support an older version we favor to just removing the older version.

avoid version numbers in package names

fine:
gtk+-1.2.0 (version not in package name)
bad:
gtk+1.2-1.2.0 (version also included in package name)
  • sometimes there's a need to break this rule, most often if the package's upstream name includes the major version number
    • example: kdebase4