[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]
Source packages should specify the most recent version number of this policy document with which your package complied when it was last updated.
This information may be used to file bug reports automatically if your package becomes too much out of date.
The version is specified in the Standards-Version control field. The format of the Standards-Version field is described in Standards-Version, Section 5.6.11.
You should regularly, and especially if your package has become out of date, check for the newest Policy Manual available and update your package, if necessary. When your package complies with the new standards you should update the Standards-Version source package field and release it.[14]
Source packages should specify which binary packages they require to be installed or not to be installed in order to build correctly. For example, if building a package requires a certain compiler, then the compiler should be specified as a build-time dependency.
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 an Ubuntu
package a standard "Hello World!" program written in C or C++. The
required packages are called build-essential, and an informational
list can be found in /usr/share/doc/build-essential/list
(which is
contained in the build-essential package).[15]
When specifying the set of build-time dependencies, one should list only those packages explicitly required by the build. It is not necessary to list packages which are required merely because some other package in the list of build-time dependencies depends on them.[16]
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.
Declaring relationships between packages, Chapter 7 explains the technical details.
If changes to the source code are made that are not specific to the needs of the Ubuntu system, they should be sent to the upstream authors in whatever form they prefer so as to be included in the upstream version of the package.
If you need to configure the package differently for Ubuntu or for Linux, and
the upstream source doesn't provide a way to do so, you should add such
configuration facilities (for example, a new autoconf
test or
#define) and send the patch to the upstream authors, with the
default set to the way they originally had it. You can then easily override
the default in your debian/rules
or wherever is appropriate.
You should make sure that the configure
utility detects the
correct architecture specification string (refer to Architecture specification
strings, Section 11.1 for details).
If you need to edit a Makefile
where GNU-style
configure
scripts are used, you should edit the .in
files rather than editing the Makefile
directly. This allows the
user to reconfigure the package if necessary. You should not
configure the package and edit the generated Makefile
! This makes
it impossible for someone else to later reconfigure the package without losing
the changes you made.
debian/changelog
Changes in the Ubuntu version of the package should be briefly explained in the
Ubuntu changelog file debian/changelog
.[17] This includes modifications made
in the Ubuntu package compared to the upstream one or the Debian package as
well as other changes and updates to the package. [18]
The format of the debian/changelog
allows the package building
tools to discover which version of the package is being built and find out
other release-specific information.
That format is a series of entries like this:
package (version) distribution(s); urgency=urgency [optional blank line(s), stripped] * change details more change details [blank line(s), included in output of dpkg-parsechangelog] * even more change details [optional blank line(s), stripped] -- maintainer name <email address>[two spaces] date
package and version are the source package name and version number.
distribution(s) lists the distributions where this version should be
installed when it is uploaded - it is copied to the Distribution
field in the .changes
file. See Distribution,
Section 5.6.14.
urgency is the value for the Urgency field in the
.changes
file for the upload (see Urgency, Section
5.6.17). It is not possible to specify an urgency containing commas;
commas are used to separate keyword=value
settings in the dpkg
changelog format (though there is currently
only one useful keyword, urgency).
The change details may in fact be any series of lines starting with at least two spaces, but conventionally each change starts with an asterisk and a separating space and continuation lines are indented so as to bring them in line with the start of the text above. Blank lines may be used here to separate groups of changes, if desired.
If this upload resolves bugs recorded in the Debian Bug Tracking System (BTS), they may be automatically closed on the inclusion of this package into the Debian archive by including the string: closes: Bug#nnnnn in the change details.[19] This information is conveyed via the Closes field in the .changes file (see Closes, Section 5.6.22).
Ubuntu: If this upload resolves bugs recorded in Launchpad, they may be automatically closed on the inclusion of this package into the Ubuntu archive by including the string: LP: #nnnnn in the change details.[20] This information is conveyed via the Launchpad-Bugs-Fixed field in the .changes file (see Launchpad-Bugs-Fixed, Section 5.6.23).
The maintainer name and email address used in the changelog should be the details of the person uploading this version. They are not necessarily those of the usual package maintainer. The information here will be copied to the Changed-By field in the .changes file (see Changed-By, Section 5.6.4), and then later used to send an acknowledgement when the upload has been installed.
The date must be in RFC822 format[21]; it must include the time zone specified numerically, with the time zone name or abbreviation optionally present as a comment in parentheses.
The first "title" line with the package name must start at the left hand margin. The "trailer" line with the maintainer and date details must be preceded by exactly one space. The maintainer details and the date must be separated by exactly two spaces.
The entire changelog must be encoded in UTF-8.
For more information on placement of the changelog files within binary packages, please see Changelog files, Section 12.7.
debian/copyright
Every package must be accompanied by a verbatim copy of its copyright and
distribution license in the file
/usr/share/doc/package/copyright
(see Copyright information, Section 12.5 for
further details). Also see Copyright
considerations, Section 2.3 for further considerations relayed to
copyrights for packages.
When make
invokes a command in a makefile (including your
package's upstream makefiles and debian/rules
), it does so using
sh
. This means that sh
's usual bad error handling
properties apply: if you include a miniature script as one of the commands in
your makefile you'll find that if you don't do anything about it then errors
are not detected and make
will blithely continue after problems.
Every time you put more than one shell command (this includes using a loop) in a makefile command you must make sure that errors are trapped. For simple compound commands, such as changing directory and then running a program, using && rather than semicolon as a command separator is sufficient. For more complex commands including most loops and conditionals you should include a separate set -e command at the start of every makefile command that's actually one of these miniature shell scripts.
Maintainers should preserve the modification times of the upstream source files in a package, as far as is reasonably possible.[22]
The source package may not contain any hard links[23], device special files, sockets or setuid or setgid files.[24]
debian/rules
This file must be an executable makefile, and contains the package-specific recipes for compiling the package and building binary package(s) from the source.
It must start with the line #!/usr/bin/make -f, so that it can be
invoked by saying its name rather than invoking make
explicitly.
Since an interactive debian/rules
script makes it impossible to
auto-compile that package and also makes it hard for other people to reproduce
the same binary package, all required targets MUST be non-interactive.
At a minimum, required targets are the ones called by
dpkg-buildpackage
, namely, clean, binary,
binary-arch, binary-indep, and build. It also
follows that any target that these targets depend on must also be
non-interactive.
The targets are as follows (required unless stated otherwise):
The build target should perform all the configuration and compilation of the package. If a package has an interactive pre-build configuration routine, the Debianized source package must either be built after this has taken place (so that the binary package can be built without rerunning the configuration) or the configuration routine modified to become non-interactive. (The latter is preferable if there are architecture-specific features detected by the configuration routine.)
For some packages, notably ones where the same source tree is compiled in different ways to produce two binary packages, the build target does not make much sense. For these packages it is good enough to provide two (or more) targets (build-a and build-b or whatever) for each of the ways of building the package, and a build target that does nothing. The binary target will have to build the package in each of the possible ways and make the binary package out of each.
The build target must not do anything that might require root privilege.
The build target may need to run the clean target first - see below.
When a package has a configuration and build routine which takes a long time, or when the makefiles are poorly designed, or when build needs to run clean first, it is a good idea to touch build when the build process is complete. This will ensure that if debian/rules build is run again it will not rebuild the whole program.[25]
A package may also provide both of the targets build-arch and build-indep. The build-arch target, if provided, should perform all the configuration and compilation required for producing all architecture-dependant binary packages (those packages for which the body of the Architecture field in debian/control is not all). Similarly, the build-indep target, if provided, should perform all the configuration and compilation required for producing all architecture-independent binary packages (those packages for which the body of the Architecture field in debian/control is all). The build target should depend on those of the targets build-arch and build-indep that are provided in the rules file.
If one or both of the targets build-arch and
build-indep are not provided, then invoking
debian/rules
with one of the not-provided targets as arguments
should produce a exit status code of 2. Usually this is provided automatically
by make if the target is missing.
The build-arch and build-indep targets must not do anything that might require root privilege.
The binary target must be all that is necessary for the user to
build the binary package(s) produced from this source package. It is split
into two parts: binary-arch
builds the binary packages which are
specific to a particular architecture, and binary-indep builds
those which are not.
binary may be (and commonly is) a target with no commands which simply depends on binary-arch and binary-indep.
Both binary-* targets should depend on the build
target, or on the appropriate build-arch or
build-indep target, if provided, so that the package is built if
it has not been already. It should then create the relevant binary package(s),
using dpkg-gencontrol
to make their control files and
dpkg-deb
to build them and place them in the parent of the top
level directory.
Both the binary-arch and binary-indep targets must exist. If one of them has nothing to do (which will always be the case if the source generates only a single binary package, whether architecture-dependent or not), it must still exist and must always succeed.
The binary targets must be invoked as root.[26]
This must undo any effects that the build and binary targets may have had, except that it should leave alone any output files created in the parent directory by a run of a binary target.
If a build file is touched at the end of the build target, as suggested above, it should be removed as the first action that clean performs, so that running build again after an interrupted clean doesn't think that everything is already done.
The clean target may need to be invoked as root if binary has been invoked since the last clean, or if build has been invoked as root (since build may create directories, for example).
This target fetches the most recent version of the original source package from a canonical archive site (via FTP or WWW, for example), does any necessary rearrangement to turn it into the original source tar file format described below, and leaves it in the current directory.
This target may be invoked in any directory, and should take care to clean up any temporary files it may have left.
This target is optional, but providing it if possible is a good idea.
This target performs whatever additional actions are required to make the
source ready for editing (unpacking additional upstream archives, applying
patches, etc.). It is recommended to be implemented for any package where
dpkg-source -x does not result in source ready for additional
modification. See Source package handling:
debian/README.source
, Section 4.14.
The build, binary and clean targets must be invoked with the current directory being the package's top-level directory.
Additional targets may exist in debian/rules
, either as published
or undocumented interfaces or for the package's internal use.
The architectures we build on and build for are determined by make
variables using the utility dpkg-architecture
.
You can determine the Debian architecture and the GNU style architecture
specification string for the build machine (the machine type we are building
on) as well as for the host machine (the machine type we are building for).
Here is a list of supported make
variables:
DEB_*_ARCH (the Debian architecture)
DEB_*_GNU_TYPE (the GNU style architecture specification string)
DEB_*_GNU_CPU (the CPU part of DEB_*_GNU_TYPE)
DEB_*_GNU_SYSTEM (the System part of DEB_*_GNU_TYPE)
where * is either BUILD for specification of the build machine or HOST for specification of the host machine.
Backward compatibility can be provided in the rules file by setting the needed
variables to suitable default values; please refer to the documentation of
dpkg-architecture
for details.
It is important to understand that the DEB_*_ARCH string only determines which Debian architecture we are building on or for. It should not be used to get the CPU or system information; the GNU style variables should be used for that.
debian/rules
and DEB_BUILD_OPTIONSSupporting the standardized environment variable DEB_BUILD_OPTIONS is recommended. This variable can contain several flags to change how a package is compiled and built. Each flag must be in the form flag or flag=options. If multiple flags are given, they must be separated by whitespace.[27] flag must start with a lowercase letter (a-z) and consist only of lowercase letters, numbers (0-9), and the characters - and _ (hyphen and underscore). options must not contain whitespace. The same tag should not be given multiple times with conflicting values. Package maintainers may assume that DEB_BUILD_OPTIONS will not contain conflicting tags.
The meaning of the following tags has been standardized:
This tag says to not run any build-time test suite provided by the package.
The presence of this tag means that the package should be compiled with a minimum of optimization. For C programs, it is best to add -O0 to CFLAGS (although this is usually the default). Some programs might fail to build or run at this level of optimization; it may be necessary to use -O1, for example.
This tag means that the debugging symbols should not be stripped from the binary during installation, so that debugging information may be included in the package.
This tag means that the package should be built using up to n parallel processes if the package build system supports this.[28] If the package build system does not support parallel builds, this string must be ignored. If the package build system only supports a lower level of concurrency than n, the package should be built using as many parallel processes as the package build system supports. It is up to the package maintainer to decide whether the package build times are long enough and the package build system is robust enough to make supporting parallel builds worthwhile.
Unknown flags must be ignored by debian/rules
.
The following makefile snippet is an example of how one may implement the build options; you will probably have to massage this example in order to make it work for your package.
CFLAGS = -Wall -g INSTALL = install INSTALL_FILE = $(INSTALL) -p -o root -g root -m 644 INSTALL_PROGRAM = $(INSTALL) -p -o root -g root -m 755 INSTALL_SCRIPT = $(INSTALL) -p -o root -g root -m 755 INSTALL_DIR = $(INSTALL) -p -d -o root -g root -m 755 ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS))) CFLAGS += -O0 else CFLAGS += -O2 endif ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS))) INSTALL_PROGRAM += -s endif ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) MAKEFLAGS += -j$(NUMJOBS) endif build: # ... ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) # Code to run the package test suite. endif
debian/substvars
When dpkg-gencontrol
, dpkg-genchanges
and
dpkg-source
generate control files they perform variable
substitutions on their output just before writing it. Variable substitutions
have the form ${variable}. The optional file
debian/substvars
contains variable substitutions to be used;
variables can also be set directly from debian/rules
using the
-V option to the source packaging commands, and certain predefined
variables are also available.
The debian/substvars
file is usually generated and modified
dynamically by debian/rules
targets, in which case it must be
removed by the clean target.
See deb-substvars(5)
for full details about source variable
substitutions, including the format of debian/substvars
.
debian/watch
This is an optional, recommended control file for the uscan
utility which defines how to automatically scan ftp or http sites for newly
available updates of the package. This is used by http://dehs.alioth.debian.org/
and other Debian QA tools to help with quality control and maintenance of the
distribution as a whole.
debian/files
This file is not a permanent part of the source tree; it is used while building
packages to record which files are being generated.
dpkg-genchanges
uses it when it generates a .changes
file.
It should not exist in a shipped source package, and so it (and any backup
files or temporary files such as files.new
[29]) should be removed by the
clean target. It may also be wise to ensure a fresh start by
emptying or removing it at the start of the binary target.
When dpkg-gencontrol
is run for a binary package, it adds an entry
to debian/files
for the .deb
file that will be
created when dpkg-deb --build is run for that binary package. So
for most packages all that needs to be done with this file is to delete it in
the clean target.
If a package upload includes files besides the source package and any binary
packages whose control files were made with dpkg-gencontrol
then
they should be placed in the parent of the package's top-level directory and
dpkg-distaddfile
should be called to add the file to the list in
debian/files
.
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. Ubuntu packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way.[30] If the included code is already in the Ubuntu archive in the form of a library, the Ubuntu packaging should ensure that binary packages reference the libraries already in Ubuntu and the convenience copy is not used. If the included code is not already in Ubuntu, it should be packaged separately as a prerequisite if possible. [31]
debian/README.source
If running dpkg-source -x
on a source package doesn't produce the
source of the package, ready for editing, and allow one to make changes and run
dpkg-buildpackage
to produce a modified package without taking any
additional steps, creating a debian/README.source
documentation
file is recommended. This file should explain how to do all of the following:
Generate the fully patched source, in a form ready for editing, that would be
built to create Ubuntu packages. Doing this with a patch target
in debian/rules
is recommended; see Main
building script: debian/rules
, Section 4.9.
Modify the source and save those modifications so that they will be applied when building the package.
Remove source modifications that are currently being applied when building the package.
Optionally, document what steps are necessary to upgrade the Ubuntu source package to a new upstream version, if applicable.
This explanation should include specific commands and mention any additional required Ubuntu packages. It should not assume familiarity with any specific Ubuntu packaging system or patch management tools.
This explanation may refer to a documentation file installed by one of the package's build dependencies provided that the referenced documentation clearly explains these tasks and is not a general reference manual.
debian/README.source
may also include any other information that
would be helpful to someone modifying the source package. Even if the package
doesn't fit the above description, maintainers are encouraged to document in a
debian/README.source
file any source package with a particularly
complex or unintuitive source layout or build system (for example, a package
that builds the same source multiple times to generate different binary
packages).
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]
Ubuntu Policy Manual
version 3.8.2.0ubuntu3, 2017-02-20