Michael Alan Dorman
Philip Hands
Julian Gilbey
Every package must be accompanied by a verbatim copy of
its copyright and distribution license in the file
- /usr/share/doc/
@@ -679,13 +673,13 @@
-
-
These packages provide a reasonably small but not too
- limited character-mode system. This is what will
- install by default if the user doesn't select anything
+ limited character-mode system. This is what will be
+ installed by default if the user doesn't select anything
else. It doesn't include many large applications, but
it does include Emacs (this is more of a piece of
infrastructure than an application) and a reasonable
@@ -1187,7 +1181,7 @@
@@ -1464,29 +1458,40 @@
Many of the tools in the package management suite manipulate
- data in a common format, known as control files. Binary and
- source packages have control data as do the .changes
- files which control the installation of uploaded files, and
-
- A file consists of one or more paragraphs of fields. The
- paragraphs are separated by blank lines. Some control files
- only allow one paragraph; others allow several, in which
- case each paragraph often refers to a different package.
+ A control file consists of one or more paragraphs of fields.
+ The paragraphs are separated by blank lines. Some control
+ files allow only one paragraph; others allow several, in
+ which case each paragraph usually refers to a different
+ package. (For example, in source packages, the first
+ paragraph refers to the source package, and later paragraphs
+ refer to binary packages generated from the source.)
- Each paragraph is a series of fields and values; each field
- consists of a name, followed by a colon and the value. It
- ends at the end of the line. Horizontal whitespace (spaces
- and tabs) may occur immediately before or after the value
- and is ignored there; it is conventional to put a single
- space after the colon.
+ Each paragraph consists of a series of data fields; each
+ field consists of the field name, followed by a colon and
+ then the data/value associated with that field. It ends at
+ the end of the line. Horizontal whitespace (spaces and
+ tabs) may occur immediately before or after the value and is
+ ignored there; it is conventional to put a single space
+ after the colon. For example, a field might be:
+
@@ -1499,9 +1504,9 @@
Except where otherwise stated only a single line of data is
allowed and whitespace is not significant in a field body.
- Whitespace may never appear inside names (of packages,
- architectures, files or anything else), version numbers or
- in between the characters of multi-character version
+ Whitespace must not appear inside names (of packages,
+ architectures, files or anything else) or version numbers,
+ or between the characters of multi-character version
relationships.
- It is important to note that there are several fields which
- are optional as far as
This list here is not supposed to be exhaustive. Most fields
- are dealt with elsewhere in this document and in the
- packaging manual.
+ are dealt with elsewhere in this document.
They must be at least two characters long and must start
- with an alphanumeric character. The use of lowercase
- package names is strongly recommended unless the package
- you're building (or referring to, in other fields) is
- already using uppercase.
- Its format is the same as that of a version number except - that no epoch or Debian revision is allowed - see .
+ be installed. Valid distributions are determined by the
+ archive maintainers.
This is the current `released' version of Debian
- GNU/Linux. Once the
- distribution is stable only major bug fixes
- are allowed. When changes are made to this
- distribution, the release number is increased
- (for example: 1.2r1 becomes 1.2r2 then 1.2r3, etc).
+ 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).
+ 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. +
+- From time to time, the unstable + From time to time, the frozen 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. + be allowed. The exact details of this stage are + determined by the Release Manager.
- 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 + 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 in this section are those in the - main Debian distribution. They are all free - (according to the Debian free software - guidelines) and meet any other criteria for - inclusion described in this manual.
-- The packages in this section do not meet the - criteria for inclusion in the main Debian - distribution as defined by this manual, but are - otherwise free, as defined by the Debian free - software guidelines.
-- Packages in non-free do not meet the - criteria of free software, as defined by the - Debian free software guidelines. Again, use your - best judgment in downloading from this - Distribution.
-- Every package has a version number, in its Version - control file field. + Every package has a version number recorded in its + Version control file field.
@@ -1709,7 +1680,7 @@
The version number format is: - &lsqbepoch:]upstream-version[-debian-revision] + &lsqbepoch:]upstream_version[-debian_revision]
@@ -1721,7 +1692,7 @@
This is a single (generally small) unsigned integer. It may be omitted, in which case zero is assumed. If it is - omitted then the upstream-version may not + omitted then the upstream_version may not contain any colons.
@@ -1733,81 +1704,81 @@ -- This is the main part of the version. It is usually the - version number of the original (`upstream') package from - which the .deb file has been made, if this is - applicable. Usually this will be in the same format as - that specified by the upstream author(s); however, it - may need to be reformatted to fit into the package - management system's format and comparison scheme. + This is the main part of the version number. It is + usually the version number of the original (`upstream') + package from which the .deb file has been made, + if this is applicable. Usually this will be in the same + format as that specified by the upstream author(s); + however, it may need to be reformatted to fit into the + package management system's format and comparison + scheme.
The comparison behavior of the package management system - with respect to the upstream-version is - described below. The upstream-version + with respect to the upstream_version is + described below. The upstream_version portion of the version number is mandatory.
- The upstream-version may contain only
- alphanumerics and the characters . +
- - : (full stop, plus, hyphen, colon)
- and should start with a digit. If there is no
- debian-revision then hyphens are not allowed;
+ The upstream_version may contain only
+ alphanumerics
+ Alphanumerics are A-Za-z0-9 only.
- This part of the version represents the version of the - modifications that were made to the package to make it a - Debian binary package. It is in the same format as the - upstream-version and is compared in the same - way. + This part of the version number specifies the version of + the Debian package based on the upstream version. It + may contain only alphanumerics and the characters + + and . (plus and full stop) and is + compared in the same way as the + upstream_version is.
It is optional; if it isn't present then the - upstream-version may not contain a hyphen. + upstream_version may not contain a hyphen. This format represents the case where a piece of software was written specifically to be turned into a - Debian binary package, and so there is only one - `debianization' of it and therefore no revision - indication is required. + Debian package, and so there is only one `debianization' + of it and therefore no revision indication is required.
It is conventional to restart the - debian-revision at 1 each time the - upstream-version is increased. -
- -- The package management system will break the - upstream-version and - debian-revision apart at the last hyphen in - the string. The absence of a debian-revision - compares earlier than the presence of one (but note that - the debian-revision is the least significant - part of the version number). + debian_revision at 1 each time the + upstream_version is increased.
- The debian-revision may contain only - alphanumerics and the characters + and - . (plus and full stop). + The package management system will break the version + number apart at the last hyphen in the string (if there + is one) to determine the upstream_version and + debian_revision. The absence of a + debian_revision compares earlier than the + presence of one (but note that the + debian_revision is the least significant part + of the version number).
- These two steps are repeated (chopping initial non-digit - strings and initial digit strings off from the start) until a + These two steps (comparing and removing initial non-digit + strings and initial digit strings) are repeated until a difference is found or both strings are exhausted.
Note that the purpose of epochs is to allow us to leave behind mistakes in version numbering, and to cope with situations - where the version numbering changes. It is not there - 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). + where the version numbering scheme changes. It is + 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).
@@ -1881,7 +1853,7 @@ too.
- Note, that other version formats based on dates which are + Note that other version formats based on dates which are parsed correctly by the package management system should not be changed.
@@ -1896,10 +1868,9 @@
- Maintainers are encouraged to preserve the modification
- times of the upstream source files in a package, as far as
- is reasonably possible. Even though this is optional, this
- is still a good idea.
+ Maintainers should preserve the modification times of the
+ upstream source files in a package, as far as is reasonably
+ possible.
The rationale is that there is some information conveyed
@@ -1914,12 +1885,12 @@
This file must be an executable makefile, and contains the package-specific recipes for compiling the package and - building binary package(s) out of the source. + building binary package(s) from the source.
@@ -1932,7 +1903,7 @@
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
+ package, all required targets MUST be
non-interactive. At a minimum, required targets are the
ones called by
- The targets which must be present are:
+ The required and optional targets are as follows:
- This should perform all non-interactive
- configuration and compilation of the package. If a
- package has an interactive pre-build configuration
- routine, the Debianised source package should be
- built after this has taken place, so that it can be
- built without rerunning the configuration.
+ This should perform all non-interactive 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.)
@@ -1975,19 +1950,35 @@
- The
- When a package has a configuration routine that
- takes a long time, or when the makefiles are poorly
- designed, or when
+ Another common way to do this is for
The
- Both
- If one of the
The
+ The
- This must undo any effects that the
-
- If a
The
- The architecture we build on and build for is determined by
- make variables via dpkg-architecture. You can get the Debian
- architecture and the GNU style architecture specification
- string for the build machine as well as the host
- machine. Here is a list of supported make variables:
+ The architectures we build on and build for are determined
+ by DEB_*_ARCH (the Debian architecture)
DEB_*_GNU_CPU (the CPU part of DEB_*_GNU_TYPE)
+DEB_*_GNU_CPU (the CPU part of + DEB_*_GNU_TYPE)
DEB_*_GNU_SYSTEM (the System part of - DEB_*_GNU_TYPE)
+ DEB_*_GNU_TYPE) - - -where * is either BUILD for specification of - the build machine or HOST for specification of the machine - we build for. + 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.
+ values; please refer to the documentation of
+
@@ -2165,8 +2163,9 @@ Though there is nothing stopping an author who is also the Debian maintainer from using it for all their changes, it will have to be renamed if the Debian and - upstream maintainers become different - people. + upstream maintainers become different people. In such a + case, however, it might be better to maintain the + package as a non-native package.
. @@ -2180,13 +2179,13 @@
That format is a series of entries like this:
+ Usual urgency values are low, medium, + high and critical. They have an + effect on how quickly a package will be considered for + inclusion into the testing distribution, and + give an indication of the importance of any fixes + included in this upload. +
+@@ -2223,13 +2232,31 @@
- The maintainer name and email address need not
- necessarily be those of the usual package maintainer.
- They should be the details of the person doing
- this version. The information here will be
- copied to the .changes file, and then later used
- to send an acknowledgement when the upload has been
- installed.
+ If this upload resolves bugs recorded in the 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.
+
+ To be precise, the string should match the following
+ Perl regular expression:
+ /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
+ Then all of the bug numbers listed will be closed by the
+ archive maintenance script (
+ 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, and then later used to send an + acknowledgement when the upload has been installed.
@@ -2241,7 +2268,7 @@
; it should include the time zone specified numerically, with the time zone name or abbreviation - optionally present as a comment. + optionally present as a comment in parentheses.@@ -2272,21 +2299,22 @@
When
- The is usually generated and modified dynamically by
- debian/rules targets; in this case it must be
- removed by the
@@ -2325,11 +2353,12 @@
-
@@ -2352,8 +2381,6 @@ packages, but only when extracting them.
- -Hard links may be permitted at some point in the future, but would require a fair amount of @@ -2461,10 +2488,10 @@
- These scripts should be the files preinst, + These scripts are the files preinst, postinst, prerm and postrm in the control area of the package. They must be proper executable - files; if they are scripts (which is recommended) they must + files; if they are scripts (which is recommended), they must start with the usual #! convention. They should be readable and executable by anyone, and not world-writable.
@@ -2481,22 +2508,12 @@ well. -- It is necessary for the error recovery procedures that the - scripts be idempotent: i.e., invoking the same script several - times in the same situation should do no harm. If the first - call failed, or aborted half way through for some reason, - the second call should merely do the things that were left - undone the first time, if any, and exit with a success - status. -
-When a package is upgraded a combination of the scripts from - the old and new packages is called in amongst the other - steps of the upgrade procedure. If your scripts are going - to be at all complicated you need to be aware of this, and - may need to check the arguments to your scripts. + the old and new packages is called during the upgrade + procedure. If your scripts are going to be at all + complicated you need to be aware of this, and may need to + check the arguments to your scripts.
@@ -2507,39 +2524,47 @@
Programs called from maintainer scripts should not
- normally have a path prepended to them. Before installation
- is started the package management system checks to see if
- the programs
+ Programs called from maintainer scripts should not normally
+ have a path prepended to them. Before installation is
+ started, the package management system checks to see if the
+ programs
- It is very important to make maintainer scripts
- idempotent.
-
- That means that if it runs successfully or fails
- and then you call it again it doesn't bomb out,
- but just ensures that everything is the way it
- ought to be.
+ This is so that if an error occurs, the user interrupts
+
old-postinst abort-upgrade - new version
+ new-versionconflictor's-postinst abort-remove
@@ -2689,10 +2714,11 @@
The procedure on installation/upgrade/overwrite/disappear
(i.e., when running dpkg --unpack, or the unpack
stage of dpkg --install) is as follows. In each
- case if an error occurs the actions are, in general, run
- backwards - this means that the maintainer scripts are run
- with different arguments in reverse order. These are the
- `error unwind' calls listed below.
+ case, if a major error occurs (unless listed below) the
+ actions are, in general, run backwards - this means that the
+ maintainer scripts are run with different arguments in
+ reverse order. These are the `error unwind' calls listed
+ below.
It is an error for a package to contains files which are on the system in another package, unless Replaces is used (see ). - Currently the --force-overwrite flag is +
@@ -2827,7 +2856,7 @@
Packages which overwrite each other's files produce - behavior which though deterministic is hard for the + behavior which, though deterministic, is hard for the system administrator to understand. It can easily lead to `missing' programs if, for example, a package is installed which overwrites a file from another @@ -2841,7 +2870,7 @@
- A directory will never be replaced by a symbolic links
+ A directory will never be replaced by a symbolic link
to a directory or vice versa; instead, the existing
state (symlink or not) will be left alone and
Any packages all of whose files have been overwritten during the
installation, and which aren't required for
dependencies, are considered to have been removed.
- For each such package,
+ For each such package
The new package's status is now sane, and recorded as
- `unpacked'. Here is another point of no return - if
- the conflicting package's removal fails we do not
- unwind the rest of the installation; the conflicting
- package is left in a half-removed limbo.
+ `unpacked'.
+
+ Here is another point of no return - if the
+ conflicting package's removal fails we do not unwind
+ the rest of the installation; the conflicting package
+ is left in a half-removed limbo.
If there was a conflicting package we go and do the
@@ -2967,7 +3001,7 @@
When we configure a package (this happens with dpkg
--install, or with --configure), we first
- update the conffiles and then call:
+ update any conffiles and then call:
- The package's files are removed (except conffiles).
+ The package's files are removed (except conffiles).
All the maintainer scripts except the postrm are removed.
+
+ All the maintainer scripts except the postrm
+ are removed.
If we aren't purging the package we stop here. Note
- that packages which have no postrm and no conffiles
- are automatically purged when removed, as there is no
- difference except for the
@@ -3036,13 +3072,14 @@
Packages can declare in their control file that they have @@ -3054,9 +3091,10 @@
- This is done using the Depends, Recommends, - Suggests, Enhances, Conflicts, - Provides and Replaces control file fields. + This is done using the Depends, Pre-Depends, + Recommends, Suggests, Enhances, + Conflicts, Provides and Replaces + control file fields.
@@ -3067,7 +3105,7 @@
This is done using the Build-Depends, - Build-Depends-Indep, Build-Conflicts, and + Build-Depends-Indep, Build-Conflicts and Build-Conflicts-Indep control file fields.
@@ -3086,18 +3124,17 @@ control file fields of the package, which declare dependencies on other packages, the package names listed may also include lists of alternative package names, separated - by vertical bar symbols | (pipe symbols). In such - a case, the presence of any one of the alternative packages - is installed, that part of the dependency is considered to - be satisfied. + by vertical bar (pipe) symbols |. In such a case, + if any one of the alternative packages is installed, that + part of the dependency is considered to be satisfied.- All the fields except Provides may restrict their - applicability to particular versions of each named package. - This is done in parentheses after each individual package - name; the parentheses should contain a relation from the - list below followed by a version number, in the format + All of the fields except for Provides may restrict + their applicability to particular versions of each named + package. This is done in parentheses after each individual + package name; the parentheses should contain a relation from + the list below followed by a version number, in the format described in .
@@ -3105,8 +3142,8 @@ The relations allowed are <<, <=, =, >= and >> for strictly earlier, earlier or equal, exactly equal, later or - equal and strictly later, respectively. The forms - < and > were used to mean + equal and strictly later, respectively. The deprecated + forms < and > were used to mean earlier/later or equal, rather than strictly earlier/later, so they should not appear in new packages (though
Whitespace may appear at any point in the version
- specification, and must appear where it's necessary to
+ specification subject to the rules in , and must appear where it's necessary to
disambiguate; it is not otherwise significant. For
consistency and in case of future changes to
- For example:
+ For example, a list of dependencies might appear as:
@@ -3173,17 +3213,22 @@
- All but Pre-Depends and Conflicts
- (discussed below) take effect only when a package
- is to be configured. They do not prevent a package being on
- the system in an unconfigured state while its dependencies
- are unsatisfied, and it is possible to replace a package
- whose dependencies are satisfied and which is properly
- installed with a different version whose dependencies are
- not and cannot be satisfied; when this is done the depending
- package will be left unconfigured (since attempts to
- configure it will give errors) and will not function
- properly.
+ A Depends field takes effect only when a
+ package is to be configured. It does not prevent a package
+ being on the system in an unconfigured state while its
+ dependencies are unsatisfied, and it is possible to replace
+ a package whose dependencies are satisfied and which is
+ properly installed with a different version whose
+ dependencies are not and cannot be satisfied; when this is
+ done the depending package will be left unconfigured (since
+ attempts to configure it will give errors) and will not
+ function properly. If it is necessary, a
+ Pre-Depends field can be used, which has a partial
+ effect even when a package is being unpacked, as explained
+ in detail below. (The other three dependency fields,
+ Recommends, Suggests and
+ Enhances, are only used by the various front-ends
+ to
@@ -3195,20 +3240,37 @@
- Thus Depends allows package maintainers to impose - an order in which packages should be configured. + The Depends field thus allows package maintainers + to impose an order in which packages should be configured. +
+ +
+ The meaning of the five dependency fields is as follows:
This declares an absolute dependency.
+
+ This declares an absolute dependency. A package will
+ not be configured unless all of the packages listed in
+ its Depends field have been correctly
+ configured.
The Depends field should be used if the
depended-on package is required for the depending
package to provide a significant amount of
- functionality.
+ The Depends field should also be used if the
+
- Pre-Depends should be used sparingly, - preferably only by packages whose premature upgrade or - installation would hamper the ability of the system to - continue with any upgrade that might be in progress. + When a package declaring a pre-dependency is about to + 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 + previously-configured and currently unpacked or + half-configured versions must satisfy any version + clause in the Pre-Depends field.
- When the package declaring it is being configured, a - Pre-Dependency will be considered satisfied - only if the depending package has been correctly - configured, just as if an ordinary Depends - had been used. + When the package declaring a pre-dependency is about + to be configured, the pre-dependency will be + treated as a normal Depends, that is, it will + be considered satisfied only if the depended-on + package has been correctly configured.
- However, when a package declaring a Pre-dependency is - being unpacked the predependency can be satisfied 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 previously-configured and currently unpacked - or half-configured versions must satisfy any version - clause in the Pre-Depends field. + Pre-Depends should be used sparingly, + preferably only by packages whose premature upgrade or + installation would hamper the ability of the system to + continue with any upgrade that might be in progress.
+ +
+ Pre-Depends are also required if the
+
When one binary package declares a conflict with another
-
If one package is to be installed, the other must be removed
first - if the package being installed is marked as
- replacing () the one on the system, or
- the one on the system is marked as deselected, or both
+ 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 @@ -3336,7 +3406,7 @@ prevent their installation, and allows a package to conflict with others providing a replacement for it. You use this feature when you want the package in question to be the only - package providing something. + package providing some feature.
@@ -3354,14 +3424,15 @@
As well as the names of actual (`concrete') packages, the package relationship fields Depends, + Recommends, Suggests, Enhances, + Pre-Depends, Conflicts, Build-Depends, Build-Depends-Indep, - Recommends, Suggests, Conflicts, - Build-Conflicts and Build-Conflicts-Indep may - mention virtual packages. + Build-Conflicts and Build-Conflicts-Indep + may mention `virtual packages'.
- A virtual package is one which appears in the
+ A virtual package is one which appears in the
Provides control file field of another package.
The effect is as if the package(s) which provide a
particular virtual package name had been listed by name
@@ -3375,16 +3446,18 @@
packages which provide it. This is so that, for example,
supposing we have
@@ -3409,87 +3482,101 @@
- 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. + 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.
- The Replaces control file field has two purposes, - which come into play in different situations. + The Replaces control file field has two distinct + purposes, which come into play in different situations.
-- Virtual packages () are not considered - when looking at a Replaces field - the packages - declared as being replaced must be mentioned by their real - names. -
- -Firstly, as mentioned before, it is usually an error for a package to contain files which are on the system in - another package, though currently the - --force-overwrite flag is enabled by default, - downgrading the error to a warning, + another package.
- If the overwriting package declares that it replaces the
- one containing the file being overwritten then
-
If a package is completely replaced in this way, so that
+ If an installed package, foo say, declares that
+ it replaces another, bar, and an attempt is made
+ to install bar,
- In the future
- 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.
+ 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. + +Secondly, 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 effects do not interfere with each other. + so that the two usages of this field do not interfere with + each other.
+ +
+ In this situation, the package declared as being replaced
+ can be a virtual package, so for example, all mail
+ transport agents (MTAs) would have the following fields in
+ their control files:
+
A source package may declare a dependency or a conflict on a
- binary package. This is done with the control file fields
- Build-Depends, Build-Depends-Indep,
- Build-Conflicts, and
- Build-Conflicts-Indep. Their semantics are that
- the dependencies and conflicts they define must be satisfied
- (as defined earlier for binary packages), when one of the
- targets in debian/rules that the particular field
- applies to is invoked.
+ binary package, indicating which packages are required to be
+ present on the system in order to build the binary packages
+ from the source package. This is done with the control file
+ fields Build-Depends, Build-Depends-Indep,
+ Build-Conflicts and Build-Conflicts-Indep.
+ The dependencies and conflicts they define must be satisfied
+ (as defined earlier for binary packages) in order to invoke
+ the targets in debian/rules, as follows:
The Build-Depends and
- Build-Conflicts fields apply to the targets
+ Build-Conflicts fields must be satisfied when
+ any of the following targets is invoked:
build, binary, binary-arch
and binary-indep.
The Build-Depends-Indep and
- Build-Conflicts-Indep fields apply to the
- targets binary and binary-indep.
+ Build-Conflicts-Indep fields must be
+ satisfied when any of the following targets is
+ invoked: binary and binary-indep.
-
- Whether this mechanism is appropriate depends on a number of - factors, but basically there are two approaches to any - particular configuration file. + This chapter has been superseded by .
-
- The easy method is to ship a best-effort configuration in the
- package, and use
- The hard method is to build the configuration file from
- scratch in the
Packages containing shared libraries must be constructed with a little care to make sure that the shared library is always available. This is especially important for packages whose - shared libraries are vitally important, such as the libc. + shared libraries are vitally important, such as the C library + (currently libc6).
- Firstly, your package should install the shared libraries
- under their normal names. For example, the
-
- Secondly, your package should include the symlink that
+ Secondly, the package should include the symbolic link that
+ The package management system requires the library to be
+ placed before the symbolic link pointing to it in the
+ .deb file. This is so that when
+
- Thirdly, the development package should contain a symlink for
- the shared library without a version number. For example, the
- libgdbm1-dev package should include a symlink from
- /usr/lib/libgdm.so to libgdm.so.1.7.3. This
- symlink is needed by
- Any package installing shared libraries in a directory that's listed
- in /etc/ld.so.conf or in one of the default library
- directories of
It used to do this by calling
+ The system-wide mail directory is /var/mail. This
+ directory is part of the base system and should not owned
+ 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
If a certain job has to be executed more frequently than
daily, the package should install a file
- /etc/cron.d/package-name. This file uses
+ /etc/cron.d/package. This file uses
the same syntax as /etc/crontab and is processed by
You should follow the directions in the Debian Packaging - Manual for putting the shared library in its package, - and you must include a shlibs control area - file with details of the dependencies for packages which - use the library.
+ Manual (or other documentation of the Debian + packaging tools) for putting the shared library in its + package, and you must include a shlibs control area + file with details of the dependencies for packages which use + the library.Shared libraries should not be installed @@ -5496,8 +5592,9 @@ upgrading conffiles.
+ -+
The other way to do it is via the maintainer scripts. In this case, the configuration file must not be listed as a conffile and must not be part of the package @@ -5521,17 +5618,20 @@ have to do any configuration other than that done (semi-)automatically by the postinst script.
-
- A common practice is to create a script called
- package-configure and have the
- package's postinst call it if and only if the
- configuration file does not already exist. In certain
- cases it is useful for there to be an example or template
- file which the maintainer scripts use. Such files should
- be in /usr/share/doc if they are examples or
- /usr/lib if they are templates, and should be
- perfectly ordinary
+ A common practice is to create a script called
+ package-configure and have the
+ package's postinst call it if and only if the
+ configuration file does not already exist. In certain
+ cases it is useful for there to be an example or template
+ file which the maintainer scripts use. Such files should
+ be in /usr/share/<package> or
+ /usr/lib/<package> with a symbolic link
+ from /usr/share/doc/<package>/examples
+ if they are examples, and should be
+ perfectly ordinary
These two styles of configuration file handling must @@ -5803,7 +5903,7 @@
@@ -6005,10 +6105,14 @@ serious brain damage!
- The mail spool is /var/spool/mail and the interface + The mail spool is /var/mail and the interface to send a mail message is /usr/sbin/sendmail (as - per the FHS). The mail spool is part of the base system - and not part of the MTA package.
+ per the FHS). On older systems, the mail spool may be + physically located in /var/spool/mail, but all access to the + mail spool should be via the /var/mail symlink. The mail + spool is part of the base system and not part of the MTA + package. +
All Debian MUAs, MTAs, MDAs and other mailbox accessing
@@ -6211,7 +6315,7 @@
@@ -6411,6 +6515,17 @@
+ Perl programs and modules should follow the current Perl
+ policy as defined in the file found on
+
Every package must be accompanied by a verbatim copy of its copyright and distribution license in the file - /usr/share/doc/<package-name>/copyright. This file must + /usr/share/doc/<package>/copyright. This file must neither be compressed nor be a symbolic link.
@@ -6695,7 +6810,7 @@
- /usr/share/doc/<package-name> may be a symbolic link to a + /usr/share/doc/<package> may be a symbolic link to a directory in /usr/share/doc only if two packages both come from the same source and the first package has a "Depends" relationship on the second. These rules are important