+ These are the copyright dates of the original Policy manual.
+ Since then, this manual has been updated by many others. No
+ comprehensive collection of copyright notices for subsequent
+ work exists.
+
+
This manual is free software; you may redistribute it and/or
modify it under the terms of the GNU General Public License
@@ -273,6 +280,32 @@
+
+ restrictions. Thus, the archive is split into areas
The Debian archive software uses the term "component" internally
and in the Release file format to refer to the division of an
- archive. The Debian Social Contract refers to distribution
- areas. This document uses the same terminology as the Social
- Contract.
+ archive. The Debian Social Contract simply refers to "areas."
+ This document uses terminology similar to the Social Contract.
based on their licenses and other restrictions.
@@ -316,12 +347,12 @@
- The main distribution area forms the Debian GNU/Linux
+ The main archive area forms the Debian GNU/Linux
distribution.
- Packages in the other distribution areas (contrib,
+ Packages in the other archive areas (contrib,
non-free) are not considered to be part of the Debian
distribution, although we support their use and provide
infrastructure for them (such as our bug-tracking system and
@@ -428,10 +459,10 @@
- Distribution areas
+ Archive areas
- The main distribution area
+ The main archive area
Every package in main must comply with the DFSG
@@ -462,7 +493,7 @@
- The contrib distribution area
+ The contrib archive area
Every package in contrib must comply with the DFSG.
@@ -502,7 +533,7 @@
- The non-free distribution area
+ The non-free archive area
Packages must be placed in non-free if they are
@@ -618,27 +649,27 @@
Sections
- The packages in the distribution areas main,
- contrib and non-free are grouped further
- into sections to simplify handling.
+ The packages in the archive areas main,
+ contrib and non-free are grouped further into
+ sections to simplify handling.
- The distribution area and section for each package should be
- specified in the package's Section control record
- (see [). However, the maintainer of the
- Debian archive may override this selection to ensure the
- consistency of the Debian distribution. The
- Section field should be of the form:
+ The archive area and section for each package should be
+ specified in the package's Section control record (see
+ ][). However, the maintainer of the Debian
+ archive may override this selection to ensure the consistency of
+ the Debian distribution. The Section field should be
+ of the form:
]
-
section if the package is in the
- main distribution area,
+ main archive area,
-
area/section if the package is in
the contrib or non-free
- distribution areas.
+ archive areas.
@@ -646,18 +677,20 @@
The Debian archive maintainers provide the authoritative
list of sections. At present, they are:
- admin, comm,
- devel, doc,
- editors, electronics, embedded,
- games, gnome, graphics,
- hamradio, interpreters, kde,
- libs, libdevel, mail,
- math, misc, net, news,
- oldlibs,
- otherosfs, perl, python,
- science, shells,
- sound, tex, text,
- utils, web, x11.
+ admin, cli-mono, comm, database,
+ devel, debug, doc, editors,
+ electronics, embedded, fonts,
+ games, gnome, graphics, gnu-r,
+ gnustep, hamradio, haskell,
+ httpd, interpreters, java, kde,
+ kernel, libs, libdevel, lisp,
+ localization, mail, math, misc,
+ net, news, ocaml, oldlibs,
+ otherosfs, perl, php, python,
+ ruby, science, shells, sound,
+ tex, text, utils, vcs,
+ video, web, x11, xfce,
+ zope.
@@ -733,7 +766,8 @@
with required, important, standard or optional
priorities, or are only likely to be useful if you
already know what they are or have specialized
- requirements.
+ requirements (such as packages containing only detached
+ debugging symbols).
@@ -991,29 +1025,23 @@
(see below), and should not do so unless they depend on a
particular version of that package.
- Essential is defined as the minimal set of functionality
- that must be available and usable on the system even
- when packages are in an unconfigured (but unpacked)
- state. This is needed to avoid unresolvable dependency
- loops on upgrade. If packages add unnecessary
- dependencies on packages in this set, the chances that
- there will be an unresolvable
- dependency loop caused by forcing these Essential
- packages to be configured first before they need to be
- is greatly increased. It also increases the chances
- that frontends will be unable to
- calculate an upgrade path, even if one
- exists.
+ Essential is needed in part to avoid unresolvable dependency
+ loops on upgrade. If packages add unnecessary dependencies
+ on packages in this set, the chances that there
+ will be an unresolvable dependency loop
+ caused by forcing these Essential packages to be configured
+ first before they need to be is greatly increased. It also
+ increases the chances that frontends will be unable to
+ calculate an upgrade path, even if one
+ exists.
- Also, it's pretty unlikely that functionality from
- Essential shall ever be removed (which is one reason why
- care must be taken before adding to the Essential
- packages set), but packages have been removed
- from the Essential set when the functionality moved to a
- different package. So depending on these packages
- just in case they stop being essential does way
- more harm than good.
+ Also, functionality is rarely ever removed from the
+ Essential set, but packages have been removed from
+ the Essential set when the functionality moved to a
+ different package. So depending on these packages just
+ in case they stop being essential does way more harm
+ than good.
@@ -1100,10 +1128,13 @@
Essential packages
- Some packages are tagged essential for a system
- using the Essential control file field.
- The format of the Essential control field is
- described in [.
+ Essential is defined as the minimal set of functionality that
+ must be available and usable on the system at all times, even
+ when packages are in an unconfigured (but unpacked) state.
+ Packages are tagged essential for a system using the
+ Essential control file field. The format of the
+ Essential control field is described in ][.
]
@@ -1127,6 +1158,19 @@
appropriate.
+
+ Maintainers should take great care in adding any programs,
+ interfaces, or functionality to essential packages.
+ Packages may assume that functionality provided by
+ essential packages is always available without
+ declaring explicit dependencies, which means that removing
+ functionality from the Essential set is very difficult and is
+ almost never done. Any capability added to an
+ essential package therefore creates an obligation to
+ support that capability as part of the Essential set in
+ perpetuity.
+
+
You must not tag any packages essential before
this has been discussed on the debian-devel
@@ -1183,21 +1227,20 @@
Prompting in maintainer scripts
Package maintainer scripts may prompt the user if
- necessary. Prompting should be done by communicating
+ necessary. Prompting must be done by communicating
through a program, such as debconf, which
- conforms to the Debian Configuration management
- specification, version 2 or higher. Prompting the user by
- other means, such as by hand
- From the Jargon file: by hand 2. By extension,
- writing code which does something in an explicit or
- low-level way for which a presupplied library
- (debconf, in this instance) routine ought
- to have been available.
- , is now deprecated.
+ conforms to the Debian Configuration Management
+ Specification, version 2 or higher.
+
+
+
+ Packages which are essential, or which are dependencies of
+ essential packages, may fall back on another prompting method
+ if no such interface is available when they are executed.
- The Debian Configuration management specification is included
+ The Debian Configuration Management Specification is included
in the debconf_specification files in the
debian-policy package.
It is also available from the Debian web mirrors at
@@ -1206,8 +1249,8 @@
- Packages which use the Debian Configuration management
- specification may contain an additional
+ Packages which use the Debian Configuration Management
+ Specification may contain an additional
config script and a templates
file in their control archive
The control.tar.gz inside the .deb.
@@ -1219,18 +1262,18 @@
Therefore it must work using only the tools present in
essential packages.
Debconf or another tool that
- implements the Debian Configuration management
- specification will also be installed, and any
+ implements the Debian Configuration Management
+ Specification will also be installed, and any
versioned dependencies on it will be satisfied
before preconfiguration begins.
- Packages which use the Debian Configuration management
- specification must allow for translation of their messages
- by using a gettext-based system such as the one provided by
- the po-debconf package.
+ Packages which use the Debian Configuration Management
+ Specification must allow for translation of their user-visible
+ messages by using a gettext-based system such as the one
+ provided by the po-debconf package.
@@ -1583,6 +1626,10 @@
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 [.
@@ -1945,6 +1992,12 @@
]-
DEB_*_ARCH (the Debian architecture)
+ -
+ DEB_*_ARCH_CPU (the Debian CPU name)
+
+ -
+ DEB_*_ARCH_OS (the Debian System name)
+
-
DEB_*_GNU_TYPE (the GNU style architecture
specification string)
@@ -1973,8 +2026,10 @@
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.
+ or system information; the DEB_*_ARCH_CPU and
+ DEB_*_ARCH_OS variables should be used for that.
+ GNU style variables should generally only be used with upstream
+ build systems.
@@ -2005,6 +2060,11 @@
The meaning of the following tags has been standardized:
+ nocheck
+ -
+ This tag says to not run any build-time test suite
+ provided by the package.
+
noopt
-
The presence of this tag means that the package should
@@ -2072,6 +2132,12 @@ 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
@@ -2321,6 +2387,9 @@ Package: libc6
would mean a new paragraph.
+
+ All control files must be encoded in UTF-8.
+
@@ -2397,6 +2466,15 @@ Package: libc6
See [ for details.
+ ]
+ In addition to the control file syntax described above, this file may also contain
+ comment lines starting with # without any preceding
+ whitespace. All such lines are ignored, even in the middle of
+ continuation lines for a multiline field, and do not end a
+ multiline field.
+
+
@@ -2525,6 +2603,14 @@ Package: libc6
package control file when the source package has the same
name and version as the binary package.
+
+
+ Package names must consist only of lower case letters
+ (a-z), digits (0-9), plus (+)
+ and minus (-) signs, and periods (.).
+ They must be at least two characters long and must start
+ with an alphanumeric character.
+
@@ -2639,7 +2725,7 @@ Package: libc6
values:
- A unique single word identifying a Debian machine
- architecture, see
[.
+ architecture as described in ][.
]- all, which indicates an
architecture-independent package.
- any, which indicates a package available
@@ -2650,31 +2736,53 @@ Package: libc6
In the main debian/control file in the source
- package, or in the source package control file
- .dsc, one may specify a list of architectures
- separated by spaces, or the special values any or
- all.
+ package, this field may contain the special value
+ any, the special value all, or a list of
+ architectures separated by spaces. If any or
+ all appear, they must be the entire contents of the
+ field. Most packages will use either any or
+ all. Specifying a specific list of architectures is
+ for the minority of cases where a program is not portable or
+ is not useful on some architectures, and where possible the
+ program should be made portable instead.
+
+
+
+ In the source package control file .dsc, this
+ field may contain either the special value any or a
+ list of architectures separated by spaces. If a list is given,
+ it may include (or consist solely of) the special value
+ all. In other words, in .dsc files
+ unlike the debian/control, all may occur
+ in combination with specific architectures. The
+ Architecture field in the source package control file
+ .dsc is generally constructed from the
+ Architecture fields in the
+ debian/control in the source package.
Specifying any indicates that the source package
isn't dependent on any particular architecture and should
compile fine on any one. The produced binary package(s)
- will be specific to whatever the current build architecture
- is.
- This is the most often used setting, and is recommended
- for new packages that aren't Architecture: all.
-
+ will either be specific to whatever the current build
+ architecture is or will be architecture-independent.
+
+
+
+ Specifying only all indicates that the source package
+ will only build architecture-independent packages. If this is
+ the case, all must be used rather than any;
+ any implies that the source package will build at
+ least one architecture-dependent package.
Specifying a list of architectures indicates that the source
will build an architecture-dependent package, and will only
- work correctly on the listed architectures.
- This is a setting used for a minority of cases where the
- program is not portable. Generally, it should not be used
- for new packages.
-
+ work correctly on the listed architectures. If the source
+ package also builds at least one architecture-independent
+ package, all will also be included in the list.
@@ -2682,7 +2790,11 @@ Package: libc6
field lists the architecture(s) of the package(s)
currently being uploaded. This will be a list; if the
source for the package is also being uploaded, the special
- entry source is also present.
+ entry source is also present. all will be
+ present if any architecture-independent packages are being
+ uploaded. any may never occur in the
+ Architecture field in the .changes
+ file.
@@ -3013,76 +3125,39 @@ Package: libc6
distribution(s) where this version of the package should
be installed. Valid distributions are determined by the
archive maintainers.
- Current distribution names are:
+ Example distribution names in the Debian archive used in
+ .changes files are:
- stable
- -
- This is the current "released" version of Debian
- GNU/Linux. Once the distribution is
- stable only security fixes and other
- major bug fixes are allowed. When changes are
- made to this distribution, the release number is
- increased (for example: 2.2r1 becomes 2.2r2 then
- 2.2r3, etc).
-
-
unstable
-
- This distribution value refers to the
- developmental part of the Debian
- distribution tree. New packages, new upstream
- versions of packages and bug fixes go into the
- unstable directory tree. Download from
- this distribution at your own risk.
-
-
- testing
- -
- This distribution value refers to the
- testing part of the Debian distribution
- tree. It receives its packages from the
- unstable distribution after a short time lag to
- ensure that there are no major issues with the
- unstable packages. It is less prone to breakage
- than unstable, but still risky. It is not
- possible to upload packages directly to
- testing.
-
-
- frozen
- -
- From time to time, the testing
- distribution enters a state of "code-freeze" in
- anticipation of release as a stable
- version. During this period of testing only
- fixes for existing or newly-discovered bugs will
- be allowed. The exact details of this stage are
- determined by the Release Manager.
+ This distribution value refers to the
+ developmental part of the Debian distribution
+ tree. Most new packages, new upstream versions of
+ packages and bug fixes go into the unstable
+ directory tree.
experimental
-
- The packages with this distribution value are
- deemed by their maintainers to be high
- risk. Oftentimes they represent early beta or
- developmental packages from various sources that
- the maintainers want people to try, but are not
- ready to be a part of the other parts of the
- Debian distribution tree. Download at your own
- risk.
+ The packages with this distribution value are deemed
+ by their maintainers to be high risk. Oftentimes they
+ represent early beta or developmental packages from
+ various sources that the maintainers want people to
+ try, but are not ready to be a part of the other parts
+ of the Debian distribution tree.
- You should list all distributions that the
- package should be installed into.
-
-
-
- More information is available in the Debian Developer's
- Reference, section "The Debian archive".
+ Others are used for updating stable releases or for
+ security uploads. More information is available in the
+ Debian Developer's Reference, section "The Debian
+ archive".
+ The Debian archive software only supports listing a single
+ distribution. Migration of packages to other distributions is
+ handled outside of the upload process.
@@ -3223,8 +3298,9 @@ Package: libc6
- The disk space is represented in kilobytes as a simple
- decimal number.
+ The disk space is given as the integer value of the installed
+ size divided by 1024 (in other words, the size in kibibytes)
+ and rounded up.
@@ -3387,8 +3463,7 @@ Package: libc6
scripts this means that you almost always need to
use set -e (this is usually true when writing shell
scripts, in fact). It is also important, of course, that
- they don't exit with a non-zero status if everything went
- well.
+ they exit with a zero status if everything went well.
@@ -4140,6 +4215,22 @@ Build-Depends-Indep: texinfo
Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
+ requires kernel-headers-2.2.10 on all architectures
+ other than hurd-i386 and requires hurd-dev and
+ gnumach-dev only on hurd-i386.
+
+
+
+ If the architecture-restricted dependency is part of a set of
+ alternatives using |, that alternative is ignored
+ completely on architectures that do not match the restriction.
+ For example:
+
+Build-Depends: foo [!i386] | bar [!amd64]
+
+ is equivalent to bar on the i386 architecture, to
+ foo on the amd64 architecture, and to foo |
+ bar on all other architectures.
@@ -4169,6 +4260,9 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
This is done using the Depends, Pre-Depends,
Recommends, Suggests, Enhances,
Breaks and Conflicts control file fields.
+ Breaks is described in [, and
+ Conflicts is described in ][. The
+ rest are described below.
]
@@ -4356,12 +4450,6 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
Packages which break other packages - Breaks
-
- Using Breaks may cause problems for upgrades from older
- versions of Debian and should not be used until the stable
- release of Debian supports Breaks.
-
-
When one binary package declares that it breaks another,
dpkg will refuse to allow the package which
@@ -4446,8 +4534,7 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
dpkg from upgrading or installing the package
which declared such a conflict until the upgrade or removal
of the conflicted-with package had been completed. Instead,
- Breaks may be used (once Breaks is supported
- by the stable release of Debian).
+ Breaks may be used.
@@ -5448,23 +5535,16 @@ libbar 1 bar1 (>= 1.0-1)
- File system Structure
+ File System Structure
The location of all installed files and directories must
- comply with the File system Hierarchy Standard (FHS),
+ comply with the Filesystem Hierarchy Standard (FHS),
version 2.3, with the exceptions noted below, and except
where doing so would violate other terms of Debian
Policy. The following exceptions to the FHS apply:
- -
-
- Legacy XFree86 servers are permitted to retain the
- configuration file location
- /etc/X11/XF86Config-4.
-
-
-
The optional rules related to user specific
@@ -5626,12 +5706,6 @@ rmdir /usr/local/share/emacs 2>/dev/null || true
by any particular mail agents. The use of the old
location /var/spool/mail is deprecated, even
though the spool may still be physically located there.
- To maintain partial upgrade compatibility for systems
- which have /var/spool/mail as their physical mail
- spool, packages using /var/mail must depend on
- either libc6 (>= 2.1.3-13), or on
- base-files (>= 2.2.0), or on later
- versions of either one of these packages.
@@ -5871,13 +5945,6 @@ rmdir /usr/local/share/emacs 2>/dev/null || true
K prefix, but they too are called with the single
argument stop.
-
-
- Also, if the script name ends in .sh, the script
- will be sourced in runlevel S rather than being
- run in a forked subprocess, but will be explicitly run by
- sh in all other runlevels.
-
@@ -6001,6 +6068,18 @@ test -f program-executed-later-in-script || exit 0
script must behave sensibly and not fail if the
/etc/default file is deleted.
+
+
+ /var/run and /var/lock may be mounted
+ as temporary filesystems
+ For example, using the RAMRUN and RAMLOCK
+ options in /etc/default/rcS.
+ , so the init.d scripts must handle this
+ correctly. This will typically amount to creating any required
+ subdirectories dynamically when the init.d script
+ is run, rather than including them in the package and relying on
+ dpkg to create them.
+
@@ -7019,18 +7098,19 @@ strip --strip-unneeded your-lib
support -a and -o as binary logical
operators.
- local to create a scoped variable must be
- supported; however, local may or may not preserve
- the variable value from an outer scope and may or may not
- support arguments more complex than simple variables. Only
- uses such as:
+ supported, including listing multiple variables in a single
+ local command and assigning a value to a variable at the
+ same time as localizing it. local may or
+ may not preserve the variable value from an outer scope if
+ no assignment is present. Uses such as:
fname () {
- local a
- a=''
- # ... use a ...
+ local a b c=delta d
+ # ... use a, b, c, d ...
}
- must be supported.
+ must be supported and must set the value of c to
+ delta.
If a shell script requires non-SUSv3 features from the shell
@@ -8023,12 +8103,27 @@ http://localhost/doc/package/filename
- Mailboxes are generally mode 660
- user:mail unless the system
- administrator has chosen otherwise. A MUA may remove a
- mailbox (unless it has nonstandard permissions) in which
- case the MTA or another MUA must recreate it if needed.
- Mailboxes must be writable by group mail.
+ Mailboxes are generally either mode 600 and owned by
+ user or mode 660 and owned by
+ user:mail
+ There are two traditional permission schemes for mail spools:
+ mode 600 with all mail delivery done by processes running as
+ the destination user, or mode 660 and owned by group mail with
+ mail delivery done by a process running as a system user in
+ group mail. Historically, Debian required mode 660 mail
+ spools to enable the latter model, but that model has become
+ increasingly uncommon and the principle of least privilege
+ indicates that mail systems that use the first model should
+ use permissions of 600. If delivery to programs is permitted,
+ it's easier to keep the mail system secure if the delivery
+ agent runs as the destination user. Debian Policy therefore
+ permits either scheme.
+ . The local system administrator may choose a
+ different permission scheme; packages should not make
+ assumptions about the permission and ownership of mailboxes
+ unless required (such as when creating a new mailbox). A MUA
+ may remove a mailbox (unless it has nonstandard permissions) in
+ which case the MTA or another MUA must recreate it if needed.
@@ -8327,11 +8422,6 @@ name ["syshostname"]:
- -
- Speedo fonts must be placed in
- /usr/share/fonts/X11/Speedo/.
-
-
-
Type 1 fonts must be placed in
/usr/share/fonts/X11/Type1/. If font
@@ -8343,9 +8433,9 @@ name ["syshostname"]:
Subdirectories of /usr/share/fonts/X11/
other than those listed above must be neither
created nor used. (The PEX, CID,
- and cyrillic directories are excepted for
- historical reasons, but installation of files into
- these directories remains discouraged.)
+ Speedo, and cyrillic directories
+ are excepted for historical reasons, but installation of
+ files into these directories remains discouraged.)
-
@@ -8926,10 +9016,10 @@ install-info --quiet --remove /usr/share/info/foobar.info
- Packages in the contrib or non-free
- distribution areas should state in the copyright file that the
- package is not part of the Debian GNU/Linux distribution and
- briefly explain why.
+ Packages in the contrib or non-free archive
+ areas should state in the copyright file that the package is not
+ part of the Debian GNU/Linux distribution and briefly explain
+ why.
@@ -8950,8 +9040,8 @@ install-info --quiet --remove /usr/share/info/foobar.info
Packages distributed under the UCB BSD license, the Apache
license (version 2.0), the Artistic license, the GNU GPL
- (version 2 or 3), the GNU LGPL (versions 2, 2.1, or 3), and
- the GNU FDL (version 1.2) should refer to the corresponding
+ (version 2 or 3), the GNU LGPL (versions 2, 2.1, or 3), and the
+ GNU FDL (versions 1.2 or 1.3) should refer to the corresponding
files under /usr/share/common-licenses,
In particular,
@@ -8962,8 +9052,9 @@ install-info --quiet --remove /usr/share/info/foobar.info
/usr/share/common-licenses/GPL-3,
/usr/share/common-licenses/LGPL-2,
/usr/share/common-licenses/LGPL-2.1,
- /usr/share/common-licenses/LGPL-3, and
- /usr/share/common-licenses/GFDL-1.2
+ /usr/share/common-licenses/LGPL-3,
+ /usr/share/common-licenses/GFDL-1.2, and
+ /usr/share/common-licenses/GFDL-1.3
respectively.
rather than quoting them in the copyright
@@ -9248,7 +9339,7 @@ install-info --quiet --remove /usr/share/info/foobar.info
To view the copyright file for a package you could use this command:
- dpkg --fsys-tarfile filename.deb | tar xOf - \*/copyright | pager
+ dpkg --fsys-tarfile filename.deb | tar xOf - --wildcards \*/copyright | pager
@@ -9800,36 +9891,6 @@ install-info --quiet --remove /usr/share/info/foobar.info
See [.
- ]
- It is recommended that the entire changelog be encoded in the
-
- encoding of
- .
-
- I think it is fairly obvious that we need to
- eventually transition to UTF-8 for our package
- infrastructure; it is really the only sane char-set in
- an international environment. Now, we can't switch to
- using UTF-8 for package control fields and the like
- until dpkg has better support, but one thing we can
- start doing today is requesting that Debian changelogs
- are UTF-8 encoded. At some point in time, we can start
- requiring them to do so.
-
-
- Checking for non-UTF8 characters in a changelog is
- trivial. Dump the file through
- iconv -f utf-8 -t ucs-4
- discard the output, and check the return
- value. If there are any characters in the stream
- which are invalid UTF-8 sequences, iconv will exit
- with an error code; and this will be the case for the
- vast majority of other character sets.
-
-
-
-
Defining alternative changelog formats
@@ -10542,26 +10603,48 @@ install-info --quiet --remove /usr/share/info/foobar.info
supposing that a smailwrapper package wishes to
install a wrapper around /usr/sbin/smail:
- if [ install = "$1" ]; then
- dpkg-divert --package smailwrapper --add --rename \
- --divert /usr/sbin/smail.real /usr/sbin/smail
- fi
- Testing $1 is necessary so that the script
- doesn't try to add the diversion again when
- smailwrapper is upgraded. The --package
- smailwrapper ensures that smailwrapper's
- copy of /usr/sbin/smail can bypass the diversion and
- get installed as the true version.
+ dpkg-divert --package smailwrapper --add --rename \
+ --divert /usr/sbin/smail.real /usr/sbin/smail
+ The --package smailwrapper ensures that
+ smailwrapper's copy of /usr/sbin/smail
+ can bypass the diversion and get installed as the true version.
+ It's safe to add the diversion unconditionally on upgrades since
+ it will be left unchanged if it already exists, but
+ dpkg-divert will display a message. To suppress that
+ message, make the command conditional on the version from which
+ the package is being upgraded:
+
+ if [ upgrade != "$1" ] || dpkg --compare-versions "$2" lt 1.0-2; then
+ dpkg-divert --package smailwrapper --add --rename \
+ --divert /usr/sbin/smail.real /usr/sbin/smail
+ fi
+ where 1.0-2 is the version at which the
+ diversion was first added to the package. Running the command
+ during abort-upgrade is pointless but harmless.
The postrm has to do the reverse:
- if [ remove = "$1" ]; then
+ if [ remove = "$1" -o abort-install = "$1" -o disappear = "$1" ]; then
+ dpkg-divert --package smailwrapper --remove --rename \
+ --divert /usr/sbin/smail.real /usr/sbin/smail
+ fi
+ If the diversion was added at a particular version, the
+ postrm should also handle the failure case of upgrading from an
+ older version (unless the older version is so old that direct
+ upgrades are no longer supported):
+
+ if [ abort-upgrade = "$1" ] && dpkg --compare-versions "$2" lt 1.0-2; then
dpkg-divert --package smailwrapper --remove --rename \
--divert /usr/sbin/smail.real /usr/sbin/smail
fi
-
+ where 1.02-2 is the version at which the
+ diversion was first added to the package. The postrm should not
+ remove the diversion on upgrades both because there's no reason to
+ remove the diversion only to immediately re-add it and since the
+ postrm of the old package is run after unpacking so the removal of
+ the diversion will fail.