Skip to content

Instantly share code, notes, and snippets.

@kergoth
Last active January 8, 2024 20:48
Show Gist options
  • Save kergoth/9a164df69e211c82fa6b11e854677059 to your computer and use it in GitHub Desktop.
Save kergoth/9a164df69e211c82fa6b11e854677059 to your computer and use it in GitHub Desktop.

Notes from review of Debian Developer Documentation

Policy Manual

A native source package is one that does not distinguish between Debian packaging releases and upstream releases. A native source package contains a single tar file of source material, and the versioning does not have a Debian-specific component. Native packages are normally (but not exclusively) used for software that has no independent existence outside of Debian, such as software written specifically to be a Debian package.

Source packages should specify the most recent version number of this policy document with which your package complied when it was last updated.

The version is specified in the Standards-Version control field. The format of the Standards-Version field is described in Standards-Version.

It is not necessary to explicitly specify build-time relationships on a minimal set of packages that are always needed to compile, link and put in a Debian package a standard “Hello World!” program written in C or C++. The required packages are called build-essential

If build-time dependencies are specified, it must be possible to build the package and produce working binaries on a system with only essential and build-essential packages installed and also those required to satisfy the build-time relationships (including any implied relationships). In particular, this means that version clauses should be used rigorously in build-time relationships so that one cannot produce bad or inconsistently configured packages when the relationships are properly satisfied.

If your package includes the scripts config.sub and config.guess, you should arrange for the versions provided by the package autotools-dev be used instead (see autotools-dev documentation for details how to achieve that). This ensures that these files can be updated distribution-wide at build time when introducing new architectures.

The following targets are required and must be implemented by debian/rules: clean, binary, binary-arch, binary-indep, build, build-arch and build-indep. These are the targets called by dpkg-buildpackage.

https://www.debian.org/doc/debian-policy/ch-source.html#debian-rules-and-deb-build-options has an example rules file to make use of DEB_BUILD_OPTIONS.

Some software packages include in their distribution convenience copies of code from other software packages, generally so that users compiling from source don’t have to download multiple packages. Debian packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way. 17 If the included code is already in the Debian archive in the form of a library, the Debian packaging should ensure that binary packages reference the libraries already in Debian and the convenience copy is not used. If the included code is not already in Debian, it should be packaged separately as a prerequisite if possible.

Packages in the Debian archive using the 3.0 (quilt) source package format must not contain a non-default series file. That is, there must not exist a file debian/patches/foo.series for any foo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment