+ 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
@@ -83,11 +90,10 @@
is used by, a significant number of packages, and
therefore should not be changed without peer
review. Package maintainers can then rely on this
- interfaces not changing, and the package
- management software authors need to ensure
- compatibility with these interface
- definitions. (Control file and changelog file
- formats are examples.)
+ interface not changing, and the package management
+ software authors need to ensure compatibility with
+ this interface definition. (Control file and
+ changelog file formats are examples.)
@@ -336,12 +346,12 @@
- The main category forms the - Debian GNU/Linux distribution. + 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
@@ -355,7 +365,7 @@
The Debian Free Software Guidelines (DFSG) form our
definition of "free software". These are:
Every package in main must comply with the DFSG
@@ -482,7 +492,7 @@
Every package in contrib must comply with the DFSG.
@@ -522,7 +532,7 @@
Packages must be placed in non-free if they are
@@ -559,8 +569,8 @@
- Every package must be accompanied by a verbatim copy of
- its copyright and distribution license in the file
+ Every package must be accompanied by a verbatim copy of its
+ copyright information and distribution license in the file
- The packages in the categories 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 category 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:
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. The additional section debian-installer
+ contains special packages used by the installer and is not used
+ for normal Debian packages.
+
+ For more information about the sections and their definitions,
+ see the
- 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.
- 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 .
@@ -1147,6 +1165,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
@@ -1203,21 +1234,20 @@
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
+ 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
- Packages which use the Debian Configuration management
- specification may contain an additional
+ Packages which use the Debian Configuration Management
+ Specification may contain an additional
- 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
@@ -1588,11 +1618,38 @@
- The date must be in RFC822 format
+
@@ -1616,11 +1673,11 @@
- Every package must be accompanied by a verbatim copy of
- its copyright and distribution license in the file
+ Every package must be accompanied by a verbatim copy of its
+ copyright information and distribution license in the file
It must start with the line #!/usr/bin/make -f,
so that it can be invoked by saying its name rather than
- invoking
Since an interactive
@@ -1969,6 +2036,12 @@
+ A paragraph must not contain more than one instance of a + particular field name. +
+Many fields' values may span several lines; in this case each continuation line must start with a space or a tab. @@ -2348,6 +2428,8 @@ Package: libc6
Field names are not case-sensitive, but it is usual to capitalize the field names using mixed case as shown below. + Field values are case-sensitive unless the description of the + field says otherwise.
@@ -2411,8 +2493,6 @@ Package: libc6 The syntax and semantics of the fields are described below.
- -
These fields are used by
+ In addition to the control file syntax described
+ The structure of the Debian changes files is versionned, and + this document describes the format 1.8. +
+
The fields in this file are:
@@ -2477,15 +2571,17 @@ Package: libc6
+ Package names (both source and binary, + see ) 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. +
The package maintainer's name and email address. The name - should come first, then the email address inside angle - brackets <> (in RFC822 format). + must come first, then the email address inside angle + brackets <> (in RFC822 format).
@@ -2588,17 +2695,17 @@ Package: libc6
- List of the names and email addresses of co-maintainers of
- the package, if any. If the package has other maintainers
- beside the one named in the
-
+ List of the names and email addresses of co-maintainers of
+ the package, if any. If the package has other maintainers
+ beside the one named in the
+
Any parser that interprets the Uploaders field in
- The name and email address of the person who changed the
- said package. Usually the name of the maintainer.
- All the rules for the Maintainer field apply here, too.
+ The name and email address of the person who prepared this
+ version of the package, usually a maintainer. The syntax is
+ the same as for the
- This field represents how important that it is that the user + This field represents how important it is that the user have the package installed. See .
@@ -2660,11 +2768,9 @@ Package: libc6- 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. + Binary package names must follow the same syntax and + restrictions as source package names. See + for the details.
In the main
+ Specifying a specific list of architectures indicates that the + source will build an architecture-dependent package only on + architectures included in the list. Specifying a list of + architecture wildcards indicates that the source will build an + architecture-dependent package on only those architectures + that match any of the specified architecture wildcards. + Specifying a list of architectures or architecture wildcards + other than any is for the minority of cases where a + program is not portable or is not useful on some + architectures. Where possible, the program should be made + portable instead. +
+ +
+ In the source package control file
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.
- Specifying a list of architectures indicates that the source
- will build an architecture-dependent package, and will only
- work correctly on the listed architectures.
+ Specifying a list of architectures or architecture wildcards + indicates that the source will build an architecture-dependent + package, and will only work correctly on the listed or + matching architectures. If the source package also builds at + least one architecture-independent package, all will + also be included in the list.
In a
- See for information how to get the - architecture for the build process. + See for information on how to get + the architecture for the build process.
@@ -2786,8 +2942,8 @@ Package: libc6
Thus only the first three components of the policy version
are significant in the Standards-Version control
- field, and so either these three components or the all
- four components may be specified.
@@ -2954,10 +3111,12 @@ Package: libc6
not intended to cope with version numbers containing
strings of letters which the package management system cannot
interpret (such as ALPHA or pre-), or with
- silly orderings (the author of this manual has heard of a
- package whose versions went 1.1, 1.2,
- 1.3, 1, 2.1, 2.2,
- 2 and so forth).
+ silly orderings.
- In a
- The part of the field before the first newline is empty; - thereafter each line has the name of a binary package and - the summary description line from that binary package. - Each line is indented by one space. -
-- 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".
- This field includes the date the package was built or last edited.
+ This field includes the date the package was built or last
+ edited. It must be in the same format as the date
+ in a
@@ -3142,13 +3264,25 @@ Package: libc6
- This field specifies a format revision for the file.
- The most current format described in the Policy Manual
- is version 1.5. The syntax of the
+ In
+ In
- There should be nothing in this field before the first - newline; all the subsequent lines must be indented by at - least one space; blank lines must be represented by a line - consisting only of a space and a full stop. + The first line of the field value (the part on the same line + as Changes:) is always empty. The content of the + field is expressed as continuation lines, with each line + indented by at least one space. Blank lines must be + represented by a line consisting only of a space and a full + stop (.).
@@ -3216,7 +3352,7 @@ Package: libc6 for the most recent version should be returned first, and entries should be separated by the representation of a blank line (the "title" line may also be followed by the - representation of blank line). + representation of a blank line).
@@ -3224,29 +3360,27 @@ Package: libc6- This field is a list of binary packages. + This field is a list of binary packages. Its syntax and + meaning varies depending on the control file in which it + appears.
- When it appears in the
- When it appears in a
- The syntax is a list of binary packages separated by
- commas
- This field appears in the control files of binary
- packages, and in the
- The disk space is represented in kilobytes as a simple - decimal number. + The disk space is given as the integer value of the estimated + installed size in bytes, divided by 1024 and rounded up.
@@ -3272,20 +3408,30 @@ Package: libc6This field contains a list of files with information about each one. The exact information and syntax varies with - the context. In all cases the part of the field - contents on the same line as the field name is empty. The - remainder of the field is one line per file, each line - being indented by one space and containing a number of - sub-fields separated by spaces. + the context. +
+ ++ In all cases, Files is a multiline field. The first line of + the field value (the part on the same line as Files:) + is always empty. The content of the field is expressed as + continuation lines, one line per file. Each line must be + indented by one space and contain a number of sub-fields, + separated by spaces, as described below.
In the
In the
@@ -3316,7 +3468,7 @@ Package: libc6
no new original source archive is being distributed the
.dsc must still contain the Files field
entry for the original source archive
-
+ These fields contain a list of files with a checksum and size + for each one. Both Checksums-Sha1 + and Checksums-Sha256 have the same syntax and differ + only in the checksum algorithm used: SHA-1 + for Checksums-Sha1 and SHA-256 + for Checksums-Sha256. +
+ +
+ Checksums-Sha1 and Checksums-Sha256 are
+ multiline fields. The first line of the field value (the part
+ on the same line as Checksums-Sha1:
+ or Checksums-Sha256:) is always empty. The content
+ of the field is expressed as continuation lines, one line per
+ file. Each line consists of the checksum, a space, the file
+ size, a space, and the file name. For example (from
+ a
+ In the
+ This field is similar to the
+ This field is similar to the
@@ -3494,15 +3710,26 @@ Package: libc6
- The maintainer scripts are guaranteed to run with a - controlling terminal and can interact with the user. - Because these scripts may be executed with standard output - redirected into a pipe for logging purposes, Perl scripts - should set unbuffered output by setting $|=1 so - that the output is printed immediately rather than being - buffered. + Maintainer scripts are not guaranteed to run with a controlling + terminal and may not be able to interact with the user. They + must be able to fall back to noninteractive behavior if no + controlling terminal is available. Maintainer scripts that + prompt via a program conforming to the Debian Configuration + Management Specification (see ) may + assume that program will handle falling back to noninteractive + behavior. +
+ ++ For high-priority prompts without a reasonable default answer, + maintainer scripts may abort if there is no controlling + terminal. However, this situation should be avoided if at all + possible, since it prevents automated or unattended installs. + In most cases, users will consider this to be a bug in the + package.
- If this fails, the package is in a "Failed-Config" + If this fails, the package is in a "Half-Configured" state, or else it remains "Installed".
@@ -4178,8 +4405,39 @@ 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:
+
+ All fields that specify build-time relationships may also be
+ restricted to a certain set of architectures using architecture
+ wildcards. The syntax for declaring such restrictions is the
+ same as declaring restrictions using a certain set of
+ architectures without architecture wildcards. For example:
+
Note that the binary package relationship fields such as Depends appear in one of the binary package @@ -4207,6 +4465,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.
@@ -4343,12 +4604,12 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386], be unpacked the pre-dependency can be satisfied if the depended-on package is either fully configured, or even if the depended-on - package(s) are only unpacked or half-configured, - provided that they have been configured correctly at - some point in the past (and not removed or partially - removed since). In this case, both the + package(s) are only unpacked or in the "Half-Configured" + state, provided that they have been configured + correctly at some point in the past (and not removed + or partially removed since). In this case, both the previously-configured and currently unpacked or - half-configured versions must satisfy any version + "Half-Configured" versions must satisfy any version clause in the Pre-Depends field.
@@ -4394,12 +4655,6 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386],- 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,
A package will not be regarded as causing breakage merely because its configuration files are still installed; it must - be at least half-installed. + be at least "Half-Installed".
@@ -4424,17 +4679,29 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
Normally a Breaks entry will have an "earlier than" version clause; such a Breaks is introduced in the - version of an (implicit or explicit) dependency which - violates an assumption or reveals a bug in earlier versions - of the broken package. This use of Breaks will - inform higher-level package management tools that broken - package must be upgraded before the new one. + version of an (implicit or explicit) dependency which violates + an assumption or reveals a bug in earlier versions of the broken + package, or which takes over a file from earlier versions of the + package named in Breaks. This use of Breaks + will inform higher-level package management tools that the + broken package must be upgraded before the new one.
If the breaking package also overwrites some files from the - older package, it should use Replaces (not - Conflicts) to ensure this goes smoothly. + older package, it should use Replaces to ensure this + goes smoothly. See for a full discussion + of taking over files from other packages, including how to + use Breaks in those cases. +
+ ++ Many of the cases where Breaks should be used were + previously handled with Conflicts + because Breaks did not yet exist. + Many Conflicts fields should now be Breaks. + See for more information about the + differences.
If one package is to be installed, the other must be removed
- first - if the package being installed is marked as
- replacing (see ) the one on the system,
- or the one on the system is marked as deselected, or both
- packages are marked Essential, then
-
A package will not cause a conflict merely because its configuration files are still installed; it must be at least - half-installed. + "Half-Installed".
@@ -4479,13 +4749,52 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
- A Conflicts entry should almost never have an
- "earlier than" version clause. This would prevent
-
+
+ Conflicts should be used
+
+
+ Be aware that adding Conflicts is normally not the best
+ solution when two packages provide the same files. Depending on
+ the reason for that conflict, using alternatives or renaming the
+ files is often a better approach. See, for
+ example, .
+
+ A Conflicts entry may have an "earlier than" version
+ clause if the reason for the conflict is corrected in a later
+ version of one of the packages. However, normally the presence
+ of an "earlier than" version clause is a sign
+ that Breaks should have been used instead. An "earlier
+ than" version clause in Conflicts
+ prevents
- If a relationship field has a version number attached
- then only real packages will be considered to see whether
- the relationship is satisfied (or the prohibition violated,
- for a conflict or breakage) - it is assumed that a real
- package which provides the virtual package is not of the
- "right" version. So, a Provides field may not
- contain version numbers, and the version number of the
- concrete package which provides a particular virtual package
- will not be looked at when considering a dependency on or
- conflict with the virtual package name.
+ If a relationship field has a version number attached, only real
+ packages will be considered to see whether the relationship is
+ satisfied (or the prohibition violated, for a conflict or
+ breakage). In other words, if a version number is specified,
+ this is a request to ignore all Provides for that
+ package name and consider only real packages. The package
+ manager will assume that a package providing that virtual
+ package is not of the "right" version. A Provides
+ field may not contain version numbers, and the version number of
+ the concrete package which provides a particular virtual package
+ will not be considered when considering a dependency on or
+ conflict with the virtual package name.
- It is likely that the ability will be added in a future
- release of
- If you want to specify which of a set of real packages
- should be the default to satisfy a particular dependency on
- a virtual package, you should list the real package as an
- alternative before the virtual one.
+ If the virtual package represents a facility that can only be
+ provided by one real package at a time, such as
+ the
- Firstly, as mentioned before, it is usually an error for a
- package to contain files which are on the system in
- another package.
+ It is usually an error for a package to contain files which
+ are on the system in another package. However, if the
+ overwriting package declares that it Replaces the one
+ containing the file being overwritten, then
- However, if the overwriting package declares that it
- Replaces the one containing the file being
- overwritten, then
@@ -4599,40 +4952,35 @@ Provides: bar
special argument to allow the package to do any final
cleanup required. See .
- Replaces is a one way relationship -- you have to
- install the replacing package after the replaced
- package.
-
For this usage of Replaces, virtual packages (see ) are not considered when looking at a - Replaces field - the packages declared as being + Replaces field. The packages declared as being replaced must be mentioned by their real names.
- Furthermore, this usage of Replaces only takes - effect when both packages are at least partially on the - system at once, so that it can only happen if they do not - conflict or if the conflict has been overridden. + This usage of Replaces only takes effect when both + packages are at least partially on the system at once. It is + not relevant if the packages conflict unless the conflict has + been overridden.
-- Secondly, Replaces allows the packaging system to + Second, Replaces allows the packaging system to resolve which package should be removed when there is a - conflict - see . This usage only - takes effect when the two packages do conflict, - so that the two usages of this field do not interfere with - each other. + conflict (see ). This usage only takes + effect when the two packages do conflict, so that the + two usages of this field do not interfere with each other.
@@ -4646,7 +4994,8 @@ Conflicts: mail-transport-agent Replaces: mail-transport-agent ensuring that only one MTA can be installed at any one - time. + time. See for more information about this + example.
- If you make "build-arch" or "binary-arch", you need - Build-Depends. If you make "build-indep" or - "binary-indep", you need Build-Depends and - Build-Depends-Indep. If you make "build" or "binary", - you need both. -
There is no Build-Depends-Arch; this role is essentially - met with Build-Depends. Anyone building the - build-indep and binary-indep targets - is basically assumed to be building the whole package - anyway and so installs all build dependencies. The - autobuilders use dpkg-buildpackage -B, which - calls build (not build-arch, since it - does not yet know how to check for its existence) and - binary-arch. + met with Build-Depends. Anyone building the + build-indep and binary-indep targets is + assumed to be building the whole package, and therefore + installation of all build dependencies is required.
- The purpose of the original split, I recall, was so that - the autobuilders wouldn't need to install extra packages - needed only for the binary-indep targets. But without a - build-arch/build-indep split, this didn't work, since - most of the work is done in the build target, not in the - binary target. + The autobuilders use dpkg-buildpackage -B, which + calls build, not build-arch since it does + not yet know how to check for its existence, and + binary-arch. The purpose of the original split + between Build-Depends and + Build-Depends-Indep was so that the autobuilders + wouldn't need to install extra packages needed only for the + binary-indep targets. But without a build-arch/build-indep + split, this didn't work, since most of the work is done in + the build target, not in the binary target.
- The development files associated to a shared library need to be
- placed in a package called
-
@@ -5272,10 +5616,10 @@ dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/* \
- If you are creating a udeb for use in the Debian Installer, you
- will need to specify that
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
-
The optional rules related to user specific
@@ -5524,6 +5861,40 @@ libbar 1 bar1 (>= 1.0-1)
for 64 bit binaries is removed.
+ The requirement for object files, internal binaries, and
+ libraries, including
+ Applications may also use a single subdirectory under
+
+ The execution time linker/loader, ld*, must still be made
+ available in the existing location under /lib or /lib64
+ since this is part of the ELF ABI for the architecture.
+
The requirement that
@@ -5547,6 +5918,15 @@ libbar 1 bar1 (>= 1.0-1)
symlinked there, is relaxed to a recommendation.
+ The following directories in the root filesystem are
+ additionally allowed:
- Note, that this applies only to directories below
-
@@ -5659,17 +6041,12 @@ rmdir /usr/local/share/emacs 2>/dev/null || true
- The system-wide mail directory is
Dynamically allocated user accounts. By default @@ -5760,11 +6137,6 @@ rmdir /usr/local/share/emacs 2>/dev/null || true
Reserved.
-@@ -5909,16 +6281,9 @@ 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
-
@@ -5968,6 +6333,23 @@ rmdir /usr/local/share/emacs 2>/dev/null || true option.
+
+ Be careful of using set -e in
If a service reloads its configuration automatically (as
in the case of
+
- Note that the same symbol (") is used for the left - and right quotation marks. A grave accent (`) is - not a quote character; neither is an apostrophe - ('). + Note that the same symbol (") is used + for the left and right quotation marks. A grave accent + (`) is not a quote character; neither is an + apostrophe (').
+ Unlike
- The scripts or crontab entries in these directories should + The scripts or crontab entries in these directories should check if all necessary programs are installed before they try to execute them. Otherwise, problems will arise when a package was removed but not purged since configuration files - are kept on the system in this situation.
+ are kept on the system in this situation. + + +
+ Any cron daemon must provide
+
@@ -6940,17 +7369,6 @@ strip --strip-unneeded your-lib
-
- Packages containing shared libraries that may be linked to
- by other packages' binaries, but which for some
- compelling reason can not be installed in
-
An ever increasing number of packages are using
- Shell scripts (
+ Every script should use set -e or check the exit status + of every command.
-
Scripts may assume that
- Packages must not include device files in the package file
- tree.
+ Packages must not include device files or named pipes in the
+ package file tree.
@@ -7200,6 +7624,18 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
+ Named pipes needed by the package must be created in
+ the
@@ -7617,15 +8055,12 @@ endscript
security policy by changing the permissions on a binary:
they can do this by using
If a program needs to specify an architecture specification
- string in some place, it should select one of the
- strings provided by dpkg-architecture -L. The
- strings are in the format
- os-arch, though the OS part
- is sometimes elided, as when the OS is Linux. Currently, the strings are:
- i386 ia64 alpha amd64 armeb arm hppa m32r m68k mips
- mipsel powerpc ppc64 s390 s390x sh3 sh3eb sh4 sh4eb
- sparc darwin-i386 darwin-ia64 darwin-alpha darwin-amd64
- darwin-armeb darwin-arm darwin-hppa darwin-m32r
- darwin-m68k darwin-mips darwin-mipsel darwin-powerpc
- darwin-ppc64 darwin-s390 darwin-s390x darwin-sh3
- darwin-sh3eb darwin-sh4 darwin-sh4eb darwin-sparc
- freebsd-i386 freebsd-ia64 freebsd-alpha freebsd-amd64
- freebsd-armeb freebsd-arm freebsd-hppa freebsd-m32r
- freebsd-m68k freebsd-mips freebsd-mipsel freebsd-powerpc
- freebsd-ppc64 freebsd-s390 freebsd-s390x freebsd-sh3
- freebsd-sh3eb freebsd-sh4 freebsd-sh4eb freebsd-sparc
- kfreebsd-i386 kfreebsd-ia64 kfreebsd-alpha
- kfreebsd-amd64 kfreebsd-armeb kfreebsd-arm kfreebsd-hppa
- kfreebsd-m32r kfreebsd-m68k kfreebsd-mips
- kfreebsd-mipsel kfreebsd-powerpc kfreebsd-ppc64
- kfreebsd-s390 kfreebsd-s390x kfreebsd-sh3 kfreebsd-sh3eb
- kfreebsd-sh4 kfreebsd-sh4eb kfreebsd-sparc knetbsd-i386
- knetbsd-ia64 knetbsd-alpha knetbsd-amd64 knetbsd-armeb
- knetbsd-arm knetbsd-hppa knetbsd-m32r knetbsd-m68k
- knetbsd-mips knetbsd-mipsel knetbsd-powerpc
- knetbsd-ppc64 knetbsd-s390 knetbsd-s390x knetbsd-sh3
- knetbsd-sh3eb knetbsd-sh4 knetbsd-sh4eb knetbsd-sparc
- netbsd-i386 netbsd-ia64 netbsd-alpha netbsd-amd64
- netbsd-armeb netbsd-arm netbsd-hppa netbsd-m32r
- netbsd-m68k netbsd-mips netbsd-mipsel netbsd-powerpc
- netbsd-ppc64 netbsd-s390 netbsd-s390x netbsd-sh3
- netbsd-sh3eb netbsd-sh4 netbsd-sh4eb netbsd-sparc
- openbsd-i386 openbsd-ia64 openbsd-alpha openbsd-amd64
- openbsd-armeb openbsd-arm openbsd-hppa openbsd-m32r
- openbsd-m68k openbsd-mips openbsd-mipsel openbsd-powerpc
- openbsd-ppc64 openbsd-s390 openbsd-s390x openbsd-sh3
- openbsd-sh3eb openbsd-sh4 openbsd-sh4eb openbsd-sparc
- hurd-i386 hurd-ia64 hurd-alpha hurd-amd64 hurd-armeb
- hurd-arm hurd-hppa hurd-m32r hurd-m68k hurd-mips
- hurd-mipsel hurd-powerpc hurd-ppc64 hurd-s390 hurd-s390x
- hurd-sh3 hurd-sh3eb hurd-sh4 hurd-sh4eb hurd-sparc
-
@@ -7805,6 +8207,27 @@ done arch-unknown-linux, since the unknown does not look very good.
+ +
+ A package may specify an architecture wildcard. Architecture
+ wildcards are in the format any (which matches every
+ architecture), os-any, or
+ any-cpu.
@@ -8062,12 +8485,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
@@ -8366,11 +8804,6 @@ name ["syshostname"]:
-
@@ -8509,9 +8942,9 @@ name ["syshostname"]:
Customization of programs' X resources may also be
supported with the provision of a file with the same name
- as that of the package placed in the
-
- Packages using the X Window System should not be
- configured to install files under the
-
- Programs that use GNU
- The installation of files into subdirectories
- of
- Packages should install any relevant files into the
- directories
- These libraries used to be all symbolic
- links. However, with X11R7,
- /usr/include/X11 and /usr/lib/X11
- are now real directories, and packages
- should ship their files here instead
- of in /usr/X11R6/{include,lib}/X11.
- x11-common (>= 1:7.0.0) is the package
- responsible for converting these symlinks into
- directories.
-
- Due to limitations in current implementations, all characters
- in the manual page source should be representable in the usual
- legacy encoding for that language, even if the file is
- actually encoded in UTF-8. Safe alternative ways to write many
- characters outside that range may be found in
-
- Your package should call
- It is a good idea to specify a section for the location of
- your program; this is done with the --section
- switch. To determine which section to use, you should look
- at
- You should remove the entries in the
- If
+ Info documents should contain section and directory entry
+ information in the document for the use
+ of
Please note that this does not override the section on
changelog files below, so the file
-
Every package must be accompanied by a verbatim copy of its
- copyright and distribution license in the file
+ copyright information and distribution license in the file
- Packages in the contrib or non-free categories - 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.
@@ -8986,23 +9417,30 @@ 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
- files under
In particular,
-
- The maintainer scripts are guaranteed to run with a - controlling terminal and can interact with the user. - See . + The maintainer scripts are not guaranteed to run with a + controlling terminal and may not be able to interact with + the user. See .
@@ -9803,23 +10241,23 @@ install-info --quiet --remove /usr/share/info/foobar.infoThe source archive scheme described later is intended to - allow a Debianised source tree with some associated control - information to be reproduced and transported easily. The - Debianised source tree is a version of the original program - with certain files added for the benefit of the - Debianisation process, and with any other changes required + allow a Debian package source tree with some associated + control information to be reproduced and transported easily. + The Debian package source tree is a version of the original + program with certain files added for the benefit of the + packaging process, and with any other changes required made to the rest of the source code and installation scripts.
The extra files created for Debian are in the subdirectory
-
- See . -
- -- It is possible to use a different format to the standard - one, by providing a parser for the format you wish to - use. -
- -
- In order to have dpkg-parsechangelog run your
- parser, you must include a line within the last 40 lines
- of your file matching the Perl regular expression:
- \schangelog-format:\s+([0-9a-z]+)\W The part in
- parentheses should be the name of the format. For
- example, you might say:
-
- If such a line exists then dpkg-parsechangelog
- will look for the parser as
-
- The parser will be invoked with the changelog open on - standard input at the start of the file. It should read - the file (it may seek if it wishes) to determine the - information required and return the parsed information - to standard output in the form of a series of control - fields in the standard format. By default it should - return information about only the most recent version in - the changelog; it should accept a - -vversion option to return changes - information from all versions present strictly - after version, and it should then be an - error for version not to be present in the - changelog. -
- -
- The fields are:
-
-
-
- If several versions are being returned (due to the use - of -v), the urgency value should be of the - highest urgency code listed at the start of any of the - versions requested followed by the concatenated - (space-separated) comments from all the versions - requested; the maintainer, version, distribution and - date should always be from the most recent version. -
- -- For the format of the Changes field see - . -
- -- If the changelog format which is being parsed always or - almost always leaves a blank line between individual - change notes these blank lines should be stripped out, - so as to make the resulting output compact. -
- -- If the changelog format does not contain date or package - name information this information should be omitted from - the output. The parser should not attempt to synthesize - it or find it from other sources. -
- -- If the changelog does not have the expected format the - parser should exit with a nonzero exit status, rather - than trying to muddle through and possibly generating - incorrect output. -
- -- A changelog parser may not interact with the user at - all. -
-Apply the diff using patch -p0.
Untar the tarfile again if you want a copy of the original - source code alongside the Debianised version.
+ source code alongside the Debian version.
The source packaging tools manage the changes between the
- original and Debianised source using