<p>
Informally, the criteria used for inclusion is that the
material meet one of the following requirements:
- <taglist>
+ <taglist compact="compact">
<tag>Standard interfaces</tag>
<item>
<p>
interfaces not changing, and the package
management software authors need to ensure
compatibility with these interface
- definitions. (Control file and and changelog file
+ definitions. (Control file and changelog file
formats are examples.)
</p>
</item>
<em>may</em>, and the adjectives <em>required</em>,
<em>recommended</em> and <em>optional</em>, are used to
distinguish the significance of the various guidelines in
- this policy document. Packages that do not conform the the
+ this policy document. Packages that do not conform to the
guidelines denoted by <em>must</em> (or <em>required</em>)
will generally not be considered acceptable for the Debian
distribution. Non-conformance with guidelines denoted by
</p>
</sect>
</chapt>
+
<chapt>
<heading>The Debian Archive</heading>
<p>
<p>
Every package must be accompanied by a verbatim copy of
its copyright and distribution license in the file
- <tt>/usr/share/doc/<em><package-name></em>/copyright</tt>
+ <tt>/usr/share/doc/<em><package></em>/copyright</tt>
(see <ref id="copyrightfile"> for further details).
</p>
<p>
<item>
<p>
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
archive.</p>
<p>
- Package names must consist 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
- contain at least one letter.
+ Package names must consist of lower case letters
+ (<tt>a-z</tt>), digits (<tt>0-9</tt>), plus (<tt>+</tt>)
+ and minus (<tt>-</tt>) signs, and periods (<tt>.</tt>).
+ They must be at least two characters long and must contain
+ at least one letter.
</p>
<p>
to install the package. This description should not just
be copied verbatim from the program's documentation.
Instructions for configuring or using the package should
- not be included -- that is what installation scripts,
- manual pages, info files, etc., are for. Copyright
+ not be included (that is what installation scripts,
+ manual pages, info files, etc., are for). Copyright
statements and other administrivia should not be included
- either -- that is what the copyright file is for.</p>
+ either (that is what the copyright file is for).
+ </p>
</sect1>
more-or-less the same functionality. In this case, it's
useful to define a <em>virtual package</em> whose name
describes that common functionality. (The virtual
- packages only exist logically, not physically--that's why
+ packages only exist logically, not physically; that's why
they are called <em>virtual</em>.) The packages with this
particular function will then <em>provide</em> the virtual
package. Thus, any other package requiring that function
specify an extra <em>force option</em> to
<prgn>dpkg</prgn> to do so), this flag must not be used
unless absolutely necessary. A shared library package
- must not be tagged <tt>essential</tt>--dependencies will
+ must not be tagged <tt>essential</tt>; dependencies will
prevent its premature removal, and we need to be able to
remove it when it has been superseded.
</p>
de-installed. (In this case, it may be appropriate to
specify a conflict against earlier versions of something
that previously did not use
- <prgn>update-alternatives</prgn> - this is an exception to
+ <prgn>update-alternatives</prgn>; this is an exception to
the usual rule that versioned conflicts should be
avoided).
</p>
</p>
<p>
- The version number has four components--major and minor
+ The version number has four components: major and minor
version number and major and minor patch level. When the
standards change in a way that requires every package to
change the major number will be changed. Significant
package).
<footnote>
<p>Rationale:
- <list>
+ <list compact="compact">
<item>
<p>This allows maintaining the list separately
from the policy documents (the list does not
format.
</p>
- <sect><heading>Syntax of control files</heading>
+ <sect id="controlsyntax"><heading>Syntax of control files</heading>
<p>
A control file consists of one or more paragraphs of fields.
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:
- <example>
- Package: libc6
+ <example compact="compact">
+Package: libc6
</example>
the field name is <tt>Package</tt> and the field value
<tt>libc6</tt>.
archive maintainers.
<footnote>
Current distribution names are:
- <taglist>
+ <taglist compact="compact">
<tag><em>stable</em></tag>
<item>
<p>
<p>
The version number format is:
- &lsqb<var>epoch</var><tt>:</tt>]<var>upstream_version</var>[<tt>-</tt><var>debian_revision</var>]
+ <example compact="compact">
+&lsqb<var>epoch</var><tt>:</tt>]<var>upstream_version</var>[<tt>-</tt><var>debian_revision</var>]
+ </example>
</p>
<p>
</p>
</item>
</taglist>
+ </p>
+
+ <p>
The <var>upstream_version</var> and <var>debian_revision</var>
parts are compared by the package management system using the
same algorithm:
<p>
That format is a series of entries like this:
- <example>
+ <example compact="compact">
<var>package</var> (<var>version</var>) <var>distribution(s)</var>; urgency=<var>urgency</var>
* <var>change details</var>
<var>more change details</var>
* <var>even more change details</var>
- -- <var>maintainer name and email address</var> <var>date</var>
+ -- <var>maintainer name</var> <<var>email address</var>> <var>date</var>
</example>
</p>
<footnote>
<p>
To be precise, the string should match the following
- Perl regular expression (where $pound=<tt>#</tt>;):
+ Perl regular expression:
<example>
-/closes:\s*(?:bug)?${pound}?\s?\d+(?:,\s*(?:bug)?\${pound}?\s?\d+)*/i
+/closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
</example>
- <footnote>
- <p>We had to introduce the $pound variable in the
- regexp above because otherwise the utilities
- rendering the policy documents gor confused by a
- backslashed "#" symbol.
- </p>
- </footnote>
Then all of the bug numbers listed will be closed by the
archive maintenance script (<prgn>katie</prgn>), or in
the case of an NMU, marked as fixed.
<p>
When <prgn>dpkg-gencontrol</prgn> is run for a binary
package, it adds an entry to <tt>debian/files</tt> for the
- <tt>.deb</tt> file that will be created when <prgn>dpkg-deb
- --build</prgn> is run for that binary package. So for most
+ <tt>.deb</tt> file that will be created when <tt>dpkg-deb
+ --build</tt> is run for that binary package. So for most
packages all that needs to be done with this file is to
delete it in the <prgn>clean</prgn> target.
</p>
<item>
<p>If a version of the package is already
installed, call
- <example>
- <var>old-prerm</var> upgrade <var>new-version</var>
+ <example compact="compact">
+<var>old-prerm</var> upgrade <var>new-version</var>
</example></p>
</item>
<item>
<p>
If the script runs but exits with a non-zero
exit status, <prgn>dpkg</prgn> will attempt:
- <example>
- <var>new-prerm</var> failed-upgrade <var>old-version</var>
+ <example compact="compact">
+<var>new-prerm</var> failed-upgrade <var>old-version</var>
</example>
Error unwind, for both the above cases:
- <example>
- <var>old-postinst</var> abort-upgrade <var>new-version</var>
+ <example compact="compact">
+<var>old-postinst</var> abort-upgrade <var>new-version</var>
</example>
</p>
</item>
If any packages depended on that conflicting
package and <tt>--auto-deconfigure</tt> is
specified, call, for each such package:
- <example>
- <var>deconfigured's-prerm</var> deconfigure \
- in-favour <var>package-being-installed</var> <var>version</var> \
- removing <var>conflicting-package</var> <var>version</var>
+ <example compact="compact">
+<var>deconfigured's-prerm</var> deconfigure \
+ in-favour <var>package-being-installed</var> <var>version</var> \
+ removing <var>conflicting-package</var> <var>version</var>
</example>
Error unwind:
- <example>
- <var>deconfigured's-postinst</var> abort-deconfigure \
- in-favour <var>package-being-installed-but-failed</var> <var>version</var> \
- removing <var>conflicting-package</var> <var>version</var>
+ <example compact="compact">
+<var>deconfigured's-postinst</var> abort-deconfigure \
+ in-favour <var>package-being-installed-but-failed</var> <var>version</var> \
+ removing <var>conflicting-package</var> <var>version</var>
</example>
The deconfigured packages are marked as
requiring configuration, so that if
</item>
<item>
<p>To prepare for removal of the conflicting package, call:
- <example>
- <var>conflictor's-prerm</var> remove in-favour <var>package</var> <var>new-version</var>
+ <example compact="compact">
+<var>conflictor's-prerm</var> remove \
+ in-favour <var>package</var> <var>new-version</var>
</example>
Error unwind:
- <example>
- <var>conflictor's-postinst</var> abort-remove \
- in-favour <var>package</var> <var>new-version</var>
+ <example compact="compact">
+<var>conflictor's-postinst</var> abort-remove \
+ in-favour <var>package</var> <var>new-version</var>
</example>
</p>
</item>
<enumlist>
<item>
<p>If the package is being upgraded, call:
- <example>
- <var>new-preinst</var> upgrade <var>old-version</var>
+ <example compact="compact">
+<var>new-preinst</var> upgrade <var>old-version</var>
</example></p>
</item>
<item>
Otherwise, if the package had some configuration
files from a previous version installed (i.e., it
is in the `configuration files only' state):
- <example>
- <var>new-preinst</var> install <var>old-version</var>
+ <example compact="compact">
+<var>new-preinst</var> install <var>old-version</var>
</example></p>
<item>
<p>Otherwise (i.e., the package was completely purged):
- <example>
- <var>new-preinst</var> install
+ <example compact="compact">
+<var>new-preinst</var> install
</example>
Error unwind actions, respectively:
- <example>
- <var>new-postrm</var> abort-upgrade <var>old-version</var>
- <var>new-postrm</var> abort-install <var>old-version</var>
- <var>new-postrm</var> abort-install
+ <example compact="compact">
+<var>new-postrm</var> abort-upgrade <var>old-version</var>
+<var>new-postrm</var> abort-install <var>old-version</var>
+<var>new-postrm</var> abort-install
</example>
</p>
</item>
<p><enumlist>
<item>
<p>If the package is being upgraded, call
- <example>
- <var>old-postrm</var> upgrade <var>new-version</var>
+ <example compact="compact">
+<var>old-postrm</var> upgrade <var>new-version</var>
</example></p>
</item>
<item>
<p>If this fails, <prgn>dpkg</prgn> will attempt:
- <example>
- <var>new-postrm</var> failed-upgrade <var>old-version</var>
+ <example compact="compact">
+<var>new-postrm</var> failed-upgrade <var>old-version</var>
</example>
Error unwind, for both cases:
- <example>
- <var>old-preinst</var> abort-upgrade <var>new-version</var>
+ <example compact="compact">
+<var>old-preinst</var> abort-upgrade <var>new-version</var>
</example>
</p>
</item>
<enumlist>
<item>
<p><prgn>dpkg</prgn> calls:
- <example>
- <var>disappearer's-postrm</var> disappear \
- <var>overwriter</var> <var>overwriter-version</var>
+ <example compact="compact">
+<var>disappearer's-postrm</var> disappear \
+ <var>overwriter</var> <var>overwriter-version</var>
</example>
</p>
</item>
When we configure a package (this happens with <tt>dpkg
--install</tt>, or with <tt>--configure</tt>), we first
update any <tt>conffile</tt>s and then call:
- <example>
- <var>postinst</var> configure <var>most-recently-configured-version</var>
+ <example compact="compact">
+<var>postinst</var> configure <var>most-recently-configured-version</var>
</example>
</p>
<enumlist>
<item>
<p>
- <example>
- <var>prerm</var> remove
+ <example compact="compact">
+<var>prerm</var> remove
</example>
</p>
</item>
</p>
</item>
<item>
- <p><example>
- <var>postrm</var> remove
- </example></p>
+ <p>
+ <example compact="compact">
+<var>postrm</var> remove
+ </example>
+ </p>
</item>
<item>
<p>
<tt>.dpkg-{old,new,tmp}</tt>, etc.) are removed.</p>
</item>
<item>
- <p><example>
- <var>postrm</var> purge
- </example></p>
+ <p>
+ <example compact="compact">
+<var>postrm</var> purge
+ </example>
+ </p>
</item>
<item>
<p>The package's file list is removed.</p>
<chapt id="relationships"><heading>Declaring relationships between
- packages </heading>
+ packages</heading>
<p>
Packages can declare in their control file that they have
</p>
<p>
- This is done using the <tt>Depends</tt>, <tt>Recommends</tt>,
- <tt>Suggests</tt>, <tt>Enhances</tt>, <tt>Conflicts</tt>,
- <tt>Provides</tt> and <tt>Replaces</tt> control file fields.
+ This is done using the <tt>Depends</tt>, <tt>Pre-Depends</tt>,
+ <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Enhances</tt>,
+ <tt>Conflicts</tt>, <tt>Provides</tt> and <tt>Replaces</tt>
+ control file fields.
</p>
<p>
<p>
This is done using the <tt>Build-Depends</tt>,
- <tt>Build-Depends-Indep</tt>, <tt>Build-Conflicts</tt>, and
+ <tt>Build-Depends-Indep</tt>, <tt>Build-Conflicts</tt> and
<tt>Build-Conflicts-Indep</tt> control file fields.
</p>
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 <tt>|</tt> (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 <tt>|</tt>. In such a case,
+ if any one of the alternative packages is installed, that
+ part of the dependency is considered to be satisfied.
</p>
<p>
- All the fields except <tt>Provides</tt> 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 <tt>Provides</tt> 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 <ref id="versions">.
</p>
The relations allowed are <tt><<</tt>, <tt><=</tt>,
<tt>=</tt>, <tt>>=</tt> and <tt>>></tt> for
strictly earlier, earlier or equal, exactly equal, later or
- equal and strictly later, respectively. The forms
- <tt><</tt> and <tt>></tt> were used to mean
+ equal and strictly later, respectively. The deprecated
+ forms <tt><</tt> and <tt>></tt> were used to mean
earlier/later or equal, rather than strictly earlier/later,
so they should not appear in new packages (though
<prgn>dpkg</prgn> still supports them).
<p>
Whitespace may appear at any point in the version
- specification, and must appear where it's necessary to
+ specification subject to the rules in <ref
+ id="controlsyntax">, and must appear where it's necessary to
disambiguate; it is not otherwise significant. For
consistency and in case of future changes to
<prgn>dpkg</prgn> it is recommended that a single space be
used after a version relationship and before a version
- number; it is usual also to put a single space after each
- comma, on either side of each vertical bar, and before each
- open parenthesis.
+ number; it is also conventional to put a single space after
+ each comma, on either side of each vertical bar, and before
+ each open parenthesis.
</p>
<p>
- For example:
- <example>
- Package: metamail
- Version: 2.7-3
- Depends: libc5 (>= 5.2.18-4), mime-support, csh | tcsh
+ For example, a list of dependencies might appear as:
+ <example compact="compact">
+Package: mutt
+Version: 1.3.17-1
+Depends: libc6 (>= 2.2.1), exim | mail-transport-agent
</example>
</p>
(<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
<tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt>)
may be restricted to a certain set of architectures. This
- is done in brackets after each individual package name and
+ is indicated in brackets after each individual package name and
the optional version specification. The brackets enclose a
list of Debian architecture names separated by whitespace.
Exclamation marks may be prepended to each of the names.
<p>
For example:
- <example>
- Source: glibc
- Build-Depends-Indep: texinfo
- Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
- hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
+ <example compact="compact">
+Source: glibc
+Build-Depends-Indep: texinfo
+Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
+hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
</example>
</p>
</sect>
</p>
<p>
- All but <tt>Pre-Depends</tt> and <tt>Conflicts</tt>
- (discussed below) take effect <em>only</em> 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 <tt>Depends</tt> field takes effect <em>only</em> 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
+ <tt>Pre-Depends</tt> 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,
+ <tt>Recommends</tt>, <tt>Suggests</tt> and
+ <tt>Enhances</tt>, are only used by the various front-ends
+ to <prgn>dpkg</prgn> such as <prgn>dselect</prgn>.)
</p>
<p>
</p>
<p>
- Thus <tt>Depends</tt> allows package maintainers to impose
- an order in which packages should be configured.
+ The <tt>Depends</tt> field thus allows package maintainers
+ to impose an order in which packages should be configured.
+ </p>
+
+ <p>
+ The meaning of the five dependency fields is as follows:
<taglist>
<tag><tt>Depends</tt></tag>
<item>
- <p>This declares an absolute dependency.
+ <p>
+ This declares an absolute dependency. A package will
+ not be configured unless all of the packages listed in
+ its <tt>Depends</tt> field have been correctly
+ configured.
</p>
<p>
The <tt>Depends</tt> field should be used if the
depended-on package is required for the depending
package to provide a significant amount of
- functionality.</p>
+ functionality.
+ </p>
+ <p>
+ The <tt>Depends</tt> field should also be used if the
+ <prgn>postinst</prgn>, <prgn>prerm</prgn> or
+ <prgn>postrm</prgn> scripts require the package to be
+ present in order to run. Note, however, that the
+ <prgn>postrm</prgn> cannot rely on any non-essential
+ packages to be present during the <tt>purge</tt>
+ phase.
</item>
<tag><tt>Recommends</tt></tag>
also forces <prgn>dpkg</prgn> to complete installation
of the packages named before even starting the
installation of the package which declares the
- Pre-dependency.
+ pre-dependency, as follows:
</p>
<p>
- <tt>Pre-Depends</tt> 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 <em>unpacked</em> the pre-dependency can be
+ satisfied if the depended-on package is either fully
+ configured, <em>or even if</em> 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 <tt>Pre-Depends</tt> field.
</p>
<p>
- When the package declaring it is being configured, a
- <tt>Pre-Dependency</tt> will be considered satisfied
- only if the depending package has been correctly
- configured, just as if an ordinary <tt>Depends</tt>
- had been used.
+ When the package declaring a pre-dependency is about
+ to be <em>configured</em>, the pre-dependency will be
+ treated as a normal <tt>Depends</tt>, that is, it will
+ be considered satisfied only if the depended-on
+ package has been correctly configured.
</p>
<p>
- 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 <tt>Pre-Depends</tt> field.
+ <tt>Pre-Depends</tt> 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.
</p>
+
+ <p>
+ <tt>Pre-Depends</tt> are also required if the
+ <prgn>preinst</prgn> script depends on the named
+ package. It is best to avoid this situation if
+ possible.
</item>
</taglist>
</p>
</p>
- <sect id="conflicts"><heading>Alternative binary packages -
- <tt>Conflicts</tt> and <tt>Replaces</tt>
- </heading>
+ <sect id="conflicts"><heading>Conflicting binary packages -
+ <tt>Conflicts</tt></heading>
<p>
When one binary package declares a conflict with another
- <prgn>dpkg</prgn> will refuse to allow them to be installed
- on the system at the same time.
+ using a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will
+ refuse to allow them to be installed on the system at the
+ same time.
</p>
<p>
If one package is to be installed, the other must be removed
first - if the package being installed is marked as
- replacing (<ref id="replaces">) the one on the system, or
- the one on the system is marked as deselected, or both
+ replacing (see <ref id="replaces">) the one on the system,
+ or the one on the system is marked as deselected, or both
packages are marked <tt>Essential</tt>, then
<prgn>dpkg</prgn> will automatically remove the package
which is causing the conflict, otherwise it will halt the
- installation of the new package with an error. This
- mechanism specifically doesn't work when the installed
- package is <tt>Essential</tt>, but the new package is not.
+ installation of the new package with an error. This
+ mechanism is specifically designed to produce an error when
+ the installed package is <tt>Essential</tt>, but the new
+ package is not.
</p>
-
<p>
A package will not cause a conflict merely because its
configuration files are still installed; it must be at least
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.
</p>
<p>
<p>
As well as the names of actual (`concrete') packages, the
package relationship fields <tt>Depends</tt>,
+ <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Enhances</tt>,
+ <tt>Pre-Depends</tt>, <tt>Conflicts</tt>,
<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
- <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Conflicts</tt>,
- <tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt> may
- mention virtual packages.
+ <tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt>
+ may mention `virtual packages'.
</p>
<p>
- A virtual package is one which appears in the
+ A <em>virtual package</em> is one which appears in the
<tt>Provides</tt> 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
caused) by either the real package or any of the virtual
packages which provide it. This is so that, for example,
supposing we have
- <example>
- Package: vm
- Depends: emacs
+ <example compact="compact">
+Package: foo
+Depends: bar
+ </example>
+ and someone else releases an enhanced version of the
+ <tt>bar</tt> package (for example, a non-US variant), they
+ can say:
+ <example compact="compact">
+Package: bar-plus
+Provides: bar
</example>
- and someone else releases an xemacs package they can say
- <example>
- Package: xemacs
- Provides: emacs
- </example> and all will work in the interim (until a purely
- virtual package name is decided on and the <tt>emacs</tt>
- and <tt>vm</tt> packages are changed to use it).
+ and the <tt>bar-plus</tt> package will now also satisfy the
+ dependency for the <tt>foo</tt> package.
</p>
<p>
</p>
<p>
- 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.
</p>
</sect>
- <sect id="replaces"><heading><tt>Replaces</tt> - overwriting
- files and replacing packages
- </heading>
+ <sect id="replaces"><heading>Overwriting files and replacing
+ packages - <tt>Replaces</tt></heading>
<p>
- The <tt>Replaces</tt> control file field has two purposes,
- which come into play in different situations.
+ The <tt>Replaces</tt> control file field has two distinct
+ purposes, which come into play in different situations.
</p>
- <p>
- Virtual packages (<ref id="virtual">) are not considered
- when looking at a <tt>Replaces</tt> field - the packages
- declared as being replaced must be mentioned by their real
- names.
- </p>
-
- <sect1><heading>Overwriting files in other packages
- </heading>
+ <sect1><heading>Overwriting files in other packages</heading>
<p>
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
- <tt>--force-overwrite</tt> flag is enabled by default,
- downgrading the error to a warning,
+ another package.
</p>
<p>
- If the overwriting package declares that it replaces the
- one containing the file being overwritten then
- <prgn>dpkg</prgn> will proceed, and replace the file from
- the old package with that from the new. The file will no
- longer be listed as `owned' by the old package.
+ However, if the overwriting package declares that it
+ <tt>Replaces</tt> the one containing the file being
+ overwritten, then <prgn>dpkg</prgn> will replace the file
+ from the old package with that from the new. The file
+ will no longer be listed as `owned' by the old package.
</p>
<p>
If a package is completely replaced in this way, so that
<prgn>dpkg</prgn> does not know of any files it still
- contains, it is considered to have disappeared. It will
+ contains, it is considered to have `disappeared'. It will
be marked as not wanted on the system (selected for
- removal) and not installed. Any conffiles details noted
- in the package will be ignored, as they will have been
- taken over by the replacing package(s). The package's
- <prgn>postrm</prgn> script will be run to allow the
- package to do any final cleanup required. See <ref
- id="mscriptsinstact">.
+ removal) and not installed. Any <tt>conffile</tt>s
+ details noted for the package will be ignored, as they
+ will have been taken over by the overwriting package. The
+ package's <prgn>postrm</prgn> script will be run with a
+ special argument to allow the package to do any final
+ cleanup required. See <ref id="mscriptsinstact">.
</p>
<p>
- In the future <prgn>dpkg</prgn> will discard files which
- would overwrite those from an already installed package
- which declares that it replaces the package being
- installed. This is so that you can install an older
- version of a package without problems.
+ If an installed package, <tt>foo</tt> say, declares that
+ it replaces another, <tt>bar</tt>, and an attempt is made
+ to install <tt>bar</tt>, <prgn>dpkg</prgn> will discard
+ files in the <tt>bar</tt> package which would overwrite
+ those already present in <tt>foo</tt>. This is so that
+ you can install an older version of a package without
+ problems.
</p>
<p>
- This usage of <tt>Replaces</tt> 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.</p>
+ For this usage of <tt>Replaces</tt>, virtual packages (see
+ <ref id="virtual">) are not considered when looking at a
+ <tt>Replaces</tt> field - the packages declared as being
+ replaced must be mentioned by their real names.
+ </p>
+
+ <p>
+ Furthermore, this usage of <tt>Replaces</tt> 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.
+ </p>
+
</sect1>
<sect1><heading>Replacing whole packages, forcing their
- removal
- </heading>
+ removal</heading>
<p>
Secondly, <tt>Replaces</tt> allows the packaging system to
resolve which package should be removed when there is a
conflict - see <ref id="conflicts">. This usage only
takes effect when the two packages <em>do</em> 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.
</p>
+
+ <p>
+ 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:
+ <example compact="compact">
+Provides: mail-transport-agent
+Conflicts: mail-transport-agent
+Replaces: mail-transport-agent
+ </example>
+ ensuring that only one MTA can be installed at any one
+ time.
</sect1>
</sect>
<p>
A source package may declare a dependency or a conflict on a
- binary package. This is done with the control file fields
- <tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
- <tt>Build-Conflicts</tt>, and
- <tt>Build-Conflicts-Indep</tt>. 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 <tt>debian/rules</tt> 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 <tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
+ <tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt>.
+ The dependencies and conflicts they define must be satisfied
+ (as defined earlier for binary packages) in order to invoke
+ the targets in <tt>debian/rules</tt>, as follows:
<taglist>
<tag><tt>Build-Depends</tt>, <tt>Build-Conflicts</tt></tag>
<item>
<p>
The <tt>Build-Depends</tt> and
- <tt>Build-Conflicts</tt> fields apply to the targets
+ <tt>Build-Conflicts</tt> fields must be satisfied when
+ any of the following targets is invoked:
<tt>build</tt>, <tt>binary</tt>, <tt>binary-arch</tt>
and <tt>binary-indep</tt>.
</p>
<item>
<p>
The <tt>Build-Depends-Indep</tt> and
- <tt>Build-Conflicts-Indep</tt> fields apply to the
- targets <tt>binary</tt> and <tt>binary-indep</tt>.
+ <tt>Build-Conflicts-Indep</tt> fields must be
+ satisfied when any of the following targets is
+ invoked: <tt>binary</tt> and <tt>binary-indep</tt>.
</p>
</item>
</taglist>
</heading>
<p>
- <prgn>dpkg</prgn> can do a certain amount of automatic
- handling of package configuration files.
+ This chapter has been superseded by <ref id="config files">.
</p>
- <p>
- Whether this mechanism is appropriate depends on a number of
- factors, but basically there are two approaches to any
- particular configuration file.
- </p>
- <p>
- The easy method is to ship a best-effort configuration in the
- package, and use <prgn>dpkg</prgn>'s conffile mechanism to
- handle updates. If the user is unlikely to want to edit the
- file, but you need them to be able to without losing their
- changes, and a new package with a changed version of the file
- is only released infrequently, this is a good approach.
- </p>
-
- <p>
- The hard method is to build the configuration file from
- scratch in the <prgn>postinst</prgn> script, and to take the
- responsibility for fixing any mistakes made in earlier
- versions of the package automatically. This will be
- appropriate if the file is likely to need to be different on
- each system.
- </p>
-
-
- <chapt id="sharedlibs"><heading>Shared libraries
- </heading>
+ <chapt id="sharedlibs"><heading>Shared libraries</heading>
<p>
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 <tt>libc6</tt>).
</p>
<p>
- Firstly, your package should install the shared libraries
- under their normal names. For example, the
- <prgn>libgdbm1</prgn> package should install
- <tt>libgdbm.so.1.7.3</tt> as
+ Firstly, the package should install the shared libraries under
+ their normal names. For example, the <tt>libgdbmg1</tt>
+ package should install <tt>libgdbm.so.1.7.3</tt> as
<tt>/usr/lib/libgdbm.so.1.7.3</tt>. The files should not be
- renamed or re-linked by any prerm or postrm scripts;
- <prgn>dpkg</prgn> will take care of renaming things safely
- without affecting running programs, and attempts to interfere
- with this are likely to lead to problems.
+ renamed or re-linked by any <prgn>prerm</prgn> or
+ <prgn>postrm</prgn> scripts; <prgn>dpkg</prgn> will take care
+ of renaming things safely without affecting running programs,
+ and attempts to interfere with this are likely to lead to
+ problems.
</p>
<p>
- Secondly, your package should include the symlink that
+ Secondly, the package should include the symbolic link that
<prgn>ldconfig</prgn> would create for the shared libraries.
- For example, the <prgn>libgdbm1</prgn> package should include
- a symlink from <tt>/usr/lib/libgdbm.so.1</tt> to
- <tt>libgdbm.so.1.7.3</tt>. This is needed so that
- <prgn>ld.so</prgn> can find the library in between the time
- <prgn>dpkg</prgn> installs it and <prgn>ldconfig</prgn> is run
- in the <prgn>postinst</prgn> script. Furthermore, older
- versions of the package management system required the library
- must be placed before the symlink pointing to it in the
- <tt>.deb</tt> file. This is so that by the time
- <prgn>dpkg</prgn> comes to install the symlink (overwriting
- the previous symlink pointing at an older version of the
- library) the new shared library is already in place.
- Unfortunately, this was not not always possible, since it
- highly depends on the behavior of the file system. Some
- file systems (such as reiserfs) will reorder the files so it
- doesn't matter in what order you create them. Starting with
- release <tt>1.7.0</tt> <prgn>dpkg</prgn> will reorder the
- files itself when building a package.
+ For example, the <prgn>libgdbmg1</prgn> package should include
+ a symbolic link from <tt>/usr/lib/libgdbm.so.1</tt> to
+ <tt>libgdbm.so.1.7.3</tt>. This is needed so that the dynamic
+ linker (for example <prgn>ld.so</prgn> or
+ <prgn>ld-linux.so.*</prgn>) can find the library between the
+ time that <prgn>dpkg</prgn> installs it and the time that
+ <prgn>ldconfig</prgn> is run in the <prgn>postinst</prgn>
+ script.
+ <footnote>
+ <p>
+ The package management system requires the library to be
+ placed before the symbolic link pointing to it in the
+ <tt>.deb</tt> file. This is so that when
+ <prgn>dpkg</prgn> comes to install the symlink
+ (overwriting the previous symlink pointing at an older
+ version of the library), the new shared library is already
+ in place. In the past, this was achieved by creating the
+ library in the temporary packaging directory before
+ creating the symlink. Unfortunately, this was not always
+ effective, since the building of the tar file in the
+ <tt>.deb</tt> depended on the behavior of the underlying
+ file system. Some file systems (such as reiserfs) reorder
+ the files so that the order of creation is forgotten.
+ Starting with release <tt>1.7.0</tt>, <prgn>dpkg</prgn>
+ will reorder the files itself as necessary when building a
+ package. Thus it is no longer important to concern
+ oneself with the order of file creation.
+ </p>
+ </footnote>
+ </p>
+
+ <p>
+ Thirdly, the associated development package should contain a
+ symlink for the shared library without a version number. For
+ example, the <tt>libgdbmg1-dev</tt> package should include a
+ symlink from <tt>/usr/lib/libgdbm.so</tt> to
+ <tt>libgdbm.so.1.7.3</tt>. This symlink is needed by the
+ linker (<prgn>ld</prgn>) when compiling packages, as it will
+ only look for <tt>libgdbm.so</tt> when compiling dynamically.
</p>
<p>
- Thirdly, the development package should contain a symlink for
- the shared library without a version number. For example, the
- <tt>libgdbm1-dev</tt> package should include a symlink from
- <tt>/usr/lib/libgdm.so</tt> to <tt>libgdm.so.1.7.3</tt>. This
- symlink is needed by <prgn>ld</prgn> when compiling packages
- as it will only look for <tt>libgdm.so</tt> and
- <tt>libgdm.a</tt> when compiling dynamically or statically,
- respectively.
+ Any package installing shared libraries in one of the default
+ library directories of the dynamic linker (which are currently
+ <tt>/usr/lib</tt> and <tt>/lib</tt>) or a directory that is
+ listed in <tt>/etc/ld.so.conf</tt>
+ <footnote>
+ <p>
+ These are currently
+ <list compact="compact">
+ <item><p>/usr/X11R6/lib/Xaw3d</p></item>
+ <item><p>/usr/local/lib</p></item>
+ <item><p>/usr/lib/libc5-compat</p></item>
+ <item><p>/lib/libc5-compat</p></item>
+ <item><p>/usr/X11R6/lib</p></item>
+ </list>
+ </p>
+ </footnote>
+ must call <prgn>ldconfig</prgn> in its <prgn>postinst</prgn>
+ script if and only if the first argument is <tt>configure</tt>
+ and should call it in the <prgn>postrm</prgn> script if the
+ first argument is <tt>remove</tt>.
</p>
<p>
- Any package installing shared libraries in a directory that's listed
- in <tt>/etc/ld.so.conf</tt> or in one of the default library
- directories of <prgn>ld.so</prgn> (currently, these are <tt>/usr/lib</tt>
- and <tt>/lib</tt>) must call <prgn>ldconfig</prgn> in its <prgn>postinst</prgn>
- script if and only if the first argument is `configure'. However, it
- is important not to call <prgn>ldconfig</prgn> in the postrm or preinst
- scripts in the case where the package is being upgraded (see <ref
- id="unpackphase">), as <prgn>ldconfig</prgn> will see the temporary names
- that <prgn>dpkg</prgn> uses for the files while it is
+ However, <prgn>postrm</prgn> and <prgn>preinst</prgn> scripts
+ <em>must not</em> call <prgn>ldconfig</prgn> in the case where
+ the package is being upgraded (see <ref id="unpackphase"> for
+ details), as <prgn>ldconfig</prgn> will see the temporary
+ names that <prgn>dpkg</prgn> uses for the files while it is
installing them and will make the shared library links point
to them, just before <prgn>dpkg</prgn> continues the
- installation and removes the links!
+ installation and renames the temporary files!
</p>
- <sect id="shlibs"><heading>The <tt>shlibs</tt> File Format
- </heading>
+ <sect>
+ <heading>Handling shared library dependencies - the
+ <tt>shlibs</tt> system</heading>
+
+ <p>
+ If a package contains a binary or library which links to a
+ shared library, we must ensure that when the package is
+ installed on the system, all of the libraries needed are
+ also installed. This requirement led to the creation of the
+ <tt>shlibs</tt> system, which is very simple in its design:
+ any package which <em>provides</em> a shared library also
+ provides information on the package dependencies required to
+ ensure the presence of this library, and any package which
+ <em>uses</em> a shared library uses this information to
+ determine the dependencies it requires. The files which
+ contain the mapping from shared libraries to the necessary
+ dependency information are called <tt>shlibs</tt> files.
+ </p>
+
+ <p>
+ Thus, when a package is built which contains any shared
+ libraries, it must provide a <tt>shlibs</tt> file for other
+ packages to use, and when a package is built which contains
+ any shared libraries or compiled binaries, it must run
+ <prgn>dpkg-shlibdeps</prgn> on these to determine the
+ libraries used and hence the dependencies needed by this
+ package.
+ <footnote>
+ <p>
+ In the past, the shared libraries linked to were
+ determined by calling <prgn>ldd</prgn>, but now
+ <prgn>objdump</prgn> to do this. The only change this
+ makes to package building is that
+ <prgn>dpkg-shlibdeps</prgn> must also be run on shared
+ libraries, whereas in the past this was unnecessary.
+ The rest of this footnote explains the advantage that
+ this method gives.
+ </p>
- <p>
- This file is for use by <prgn>dpkg-shlibdeps</prgn> and is
- required when your package provides shared libraries.
- </p>
+ <p>
+ We say that a binary <tt>foo</tt> <em>directly</em> uses
+ a library <tt>libbar</tt> if it is explicitly linked
+ with that library (that is, it uses the flag
+ <tt>-lbar</tt> during the linking stage). Other
+ libraries that are needed by <tt>libbar</tt> are linked
+ <em>indirectly</em> to <tt>foo</tt>, and the dynamic
+ linker will load them automatically when it loads
+ <tt>libbar</tt>. A package should needs to depend on
+ the libraries it directly uses, and the dependencies for
+ those libraries should automatically pull in the other
+ libraries.
+ </p>
- <p>
- Each line is of the form:
- <example>
- <var>library-name</var> <var>version-or-soname</var> <var>dependencies ...</var>
- </example>
- </p>
+ <p>
+ Unfortunately, the <prgn>ldd</prgn> program shows both
+ the directly and indirectly used libraries, meaning that
+ the dependencies determined included both direct and
+ indirect dependencies. The use of <prgn>objdump</prgn>
+ avoids this problem by determining only the directly
+ used libraries.
+ </p>
- <p>
- <var>library-name</var> is the name of the shared library,
- for example <tt>libc5</tt>.
+ <p>
+ A good example of where this helps is the following. We
+ could update <tt>libimlib</tt> with a new version that
+ supports a new graphics format called dgf (but retaining
+ the same major version number). If we used the old
+ <prgn>ldd</prgn> method, every package that uses
+ <tt>libimlib</tt> would need to be recompiled so it
+ would also depend on <tt>libdgf</tt> or it wouldn't run
+ due to missing symbols. However with the new system,
+ packages using <tt>libimlib</tt> can rely on
+ <tt>libimlib</tt> itself having the dependency on
+ <tt>libdgf</tt> and so they would not need rebuilding.
+ </p>
+ </footnote>
</p>
<p>
- <var>version-or-soname</var> is the soname of the library -
- i.e., the thing that must exactly match for the library to be
- recognized by <prgn>ld.so</prgn>. Usually this is the major
- version number of the library.
+ In the following sections, we will first describe where the
+ various <tt>shlibs</tt> files are to be found, then how to
+ use <prgn>dpkg-shlibdeps</prgn>, and finally the
+ <tt>shlibs</tt> file format and how to create them if your
+ package contains a shared library.
</p>
+ </sect>
- <p>
- <var>dependencies</var> has the same syntax as a dependency
- field in a binary package control file. It should give
- details of which package(s) are required to satisfy a binary
- built against the version of the library contained in the
- package. See <ref id="depsyntax">.
- </p>
+ <sect><heading>The <tt>shlibs</tt> files present on the system
+ </heading>
<p>
- For example, if the package <tt>foo</tt> contains
- <tt>libfoo.so.1.2.3</tt>, where the soname of the library is
- <tt>libfoo.so.1</tt>, and the first version of the package
- which contained a minor number of at least <tt>2.3</tt> was
- <var>1.2.3-1</var>, then the package's <var>shlibs</var>
- could say:
- <example>
- libfoo 1 foo (>= 1.2.3-1)
- </example>
+ There are several places where <tt>shlibs</tt> files are
+ found. The following list gives them in the order in which
+ they are read by <prgn>dpkg-shlibdeps</prgn>. (The first
+ one which gives the required information is used.)
</p>
<p>
- The version-specific dependency is to avoid warnings from
- <prgn>ld.so</prgn> about using older shared libraries with
- newer binaries.</p>
- </sect>
-
- <sect><heading>Further Technical information on
- <tt>shlibs</tt></heading>
-
- <sect1><heading><em>What</em> are the <tt>shlibs</tt> files?
- </heading>
-
- <p>
- The <tt>debian/shlibs</tt> file provides a way of checking
- for shared library dependencies on packaged binaries.
- They are intended to be used by package maintainers to
- make their lives easier.
- </p>
-
- <p>
- Other <tt>shlibs</tt> files that exist on a Debian system are
- <list>
- <item> <p><tt>/etc/dpkg/shlibs.default</tt></p></item>
- <item> <p><tt>/etc/dpkg/shlibs.override</tt></p></item>
- <item> <p><tt>/var/lib/dpkg/info/*.shlibs</tt></p></item>
- <item> <p><tt>debian/shlibs.local</tt></p></item>
- </list>
- These files are used by <prgn>dpkg-shlibdeps</prgn> when
- creating a binary package.</p>
- </sect1>
-
- <sect1><heading><em>How</em> does <prgn>dpkg-shlibdeps</prgn>
- work?
- </heading>
- <p>
- <prgn>dpkg-shlibdeps</prgn>
- determines the shared libraries directly
- <footnote>
+ <list>
+ <item>
+ <p><tt>debian/shlibs.local</tt></p>
<p>
- It used to do this by calling <prgn>ldd</prgn>, but it
- now calls <prgn>objdump</prgn> to do this. This
- requires a couple of changes in the way that packages
- are built.
+ This lists overrides for this package. Its use is
+ described below (see <ref id="shlibslocal">).
</p>
+ </item>
+
+ <item>
+ <p><tt>/etc/dpkg/shlibs.override</tt></p>
<p>
- A binary <tt>foo</tt> directly uses a library
- <tt>libbar</tt> if it is linked with that
- library. Other libraries that are needed by
- <tt>libbar</tt> are linked indirectly to <tt>foo</tt>,
- and the dynamic linker will load them automatically
- when it loads <tt>libbar</tt>. Running<prgn>ldd</prgn>
- lists all of the libraries used, both directly and
- indirectly; but <prgn>objdump</prgn> only lists the
- directly linked libraries. A package only needs to
- depend on the libraries it is directly linked to,
- since the dependencies for those libraries should
- automatically pull in the other libraries.
+ This lists global overrides. This list is normally
+ empty. It is maintained by the local system
+ administrator.
</p>
+ </item>
+
+ <item>
+ <p><tt>DEBIAN/shlibs</tt> files in the `build directory'</p>
<p>
- This change does mean a change in the way packages are
- build though: currently <prgn>dpkg-shlibdeps</prgn> is
- only run on binaries. But since we will now rely on the
- libraries depending on the libraries they themselves
- need, the packages containing those libraries will
- need to run <prgn>dpkg-shlibdeps</prgn> on the
- libraries.
+ When packages are being built, any
+ <tt>debian/shlibs</tt> files are copied into the
+ control file area of the temporary build directory and
+ given the name <tt>shlibs</tt>. These files give
+ details of any shared libraries included in the
+ package.
+ <footnote>
+ <p>
+ An example may help here. Let us say that the
+ source package <tt>foo</tt> generates two binary
+ packages, <tt>libfoo2</tt> and
+ <tt>foo-runtime</tt>. When building the binary
+ packages, the two packages are created in the
+ directories <tt>debian/libfoo2</tt> and
+ <tt>debian/foo-runtime</tt> respectively.
+ (<tt>debian/tmp</tt> could be used instead of one
+ of these.) Since <tt>libfoo2</tt> provides the
+ <tt>libfoo</tt> shared library, it will require a
+ <tt>shlibs</tt> file, which will be installed in
+ <tt>debian/libfoo2/DEBIAN/shlibs</tt>, eventually
+ to become
+ <tt>/var/lib/dpkg/info/libfoo2.shlibs</tt>. Then
+ when <prgn>dpkg-shlibdeps</prgn> is run on the
+ executable
+ <tt>debian/foo-runtime/usr/bin/foo-prog</tt>, it
+ will examine the
+ <tt>debian/libfoo2/DEBIAN/shlibs</tt> file to
+ determine whether <tt>foo-prog</tt>'s library
+ dependencies are satisfied by any of the libraries
+ provided by <tt>libfoo2</tt>. For this reason,
+ <prgn>dpkg-shlibdeps</prgn> must only be run once
+ all of the individual binary packages'
+ <tt>shlibs</tt> files have been installed into the
+ build directory.
+ </p>
+ </footnote>
</p>
+ </item>
+
+ <item>
+ <p><tt>/var/lib/dpkg/info/*.shlibs</tt></p>
<p>
- A good example where this would help us is the current
- mess with multiple version of the <tt>mesa</tt>
- library. With the <prgn>ldd</prgn>-based system, every
- package that uses <tt>mesa</tt> needs to add a
- dependency on <tt>svgalib|svgalib-dummy</tt> in order
- to handle the glide <tt>mesa</tt> variant. With an
- <prgn>objdump</prgn>-based system this isn't necessary
- anymore and would have saved everyone a lot of work.
+ These are the <tt>shlibs</tt> files corresponding to
+ all of the packages installed on the system, and are
+ maintained by the relevant package maintainers.
</p>
+ </item>
+
+ <item>
+ <p><tt>/etc/dpkg/shlibs.default</tt></p>
<p>
- Another example: we could update <tt>libimlib</tt>
- with a new version that supports a new graphics format
- called dgf. If we use the old <prgn>ldd</prgn> method,
- every package that uses <tt>libimlib</tt> would need
- to be recompiled so it would also depend on
- <tt>libdgf</tt> or it wouldn't run due to missing
- symbols. However with the new system, packages using
- <tt>libimlib</tt> can rely on <tt>libimlib</tt> itself
- having the dependency on <tt>libdgf</tt> and wouldn't
- need to be updated.
+ This file lists any shared libraries whose packages
+ have failed to provide correct <tt>shlibs</tt> files.
+ It was used when the <tt>shlibs</tt> setup was first
+ introduced, but it is now normally empty. It is
+ maintained by the <tt>dpkg</tt> maintainer.
</p>
- </footnote>
- used by the compiled binaries and libraries passed through
- on its command line.
- </p>
+ </item>
+ </list>
+ </p>
+ </sect>
- <p>
- For each shared library linked to,
- <prgn>dpkg-shlibdeps</prgn> needs to know
- <list compact="compact">
- <item><p>the package containing the library, and</p></item>
- <item><p>the library version number,</p></item>
- </list>
- and it scans the following files in this order:
- <enumlist compact="compact">
- <item><p><tt>debian/shlibs.local</tt></p></item>
- <item><p><tt>/etc/dpkg/shlibs.override</tt></p></item>
- <item><p><tt>/var/lib/dpkg/info/*.shlibs</tt></p></item>
- <item><p><tt>/etc/dpkg/shlibs.default</tt></p></item>
- </enumlist>
- </p>
- </sect1>
+ <sect>
+ <heading>How to use <prgn>dpkg-shlibdeps</prgn> and the
+ <tt>shlibs</tt> files</heading>
- <sect1><heading><em>Who</em> maintains the various
- <tt>shlibs</tt> files?
- </heading>
+ <p>
+ Put a call to <prgn>dpkg-shlibdeps</prgn> into your
+ <tt>debian/rules</tt> file. If your package contains only
+ compiled binaries and libraries (but no scripts), you can
+ use a command such as:
+ <example compact="compact">
+dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/* \
+ debian/tmp/usr/lib/*
+ </example>
+ Otherwise, you will need to explicitly list the compiled
+ binaries and libraries.
+ <footnote>
+ <p>
+ If you are using <tt>debhelper</tt>, the
+ <prgn>dh_shlibdeps</prgn> program will do this work for
+ you. It will also correctly handle multi-binary
+ packages.
+ </p>
+ </footnote>
+ </p>
- <p>
- <list compact="compact">
- <item>
- <p><tt>/etc/dpkg/shlibs.default</tt> - the maintainer
- of dpkg</p>
- </item>
- <item>
- <p>
- <tt>/var/lib/dpkg/info/<var>package</var>.shlibs</tt>
- - the maintainer of each package</p>
- </item>
- <item>
- <p>
- <tt>/etc/dpkg/shlibs.override</tt> - the local
- system administrator</p>
- </item>
- <item>
- <p><tt>debian/shlibs.local</tt> - the maintainer of
- the package
- </p>
- </item>
- </list>
- The <tt>shlibs.default</tt> file is managed by
- <prgn>dpkg</prgn>. The entries in <tt>shlibs.default</tt>
- that are provided by <prgn>dpkg</prgn> are just there to
- fix things until the shared library packages all have
- <tt>shlibs</tt> files.
- </p>
- </sect1>
+ <p>
+ This command puts the dependency information into the
+ <tt>debian/substvars</tt> file, which is then used by
+ <prgn>dpkg-gencontrol</prgn>. You will need to place a
+ <tt>${shlib:Depends}</tt> variable in the <tt>Depends</tt>
+ field in the control file for this to work.
+ </p>
- <sect1><heading><em>How</em> to use <prgn>dpkg-shlibdeps</prgn> and
- the <tt>shlibs</tt> files
- </heading>
+ <p>
+ If <prgn>dpkg-shlibdeps</prgn> doesn't complain, you're
+ done. If it does complain you might need to create your own
+ <tt>debian/shlibs.local</tt> file, as explained below (see
+ <ref id="shlibslocal">).
+ </p>
- <sect2><heading>If your package doesn't provide a shared
- library
- </heading>
+ <p>
+ If you have multiple binary packages, you will need to call
+ <prgn>dpkg-shlibdeps</prgn> on each one which contains
+ compiled libraries or binaries. In such a case, you will
+ need to use the <tt>-T</tt> option to the <tt>dpkg</tt>
+ utilities to specify a different <tt>substvars</tt> file.
+ For more details on this and other options, see <manref
+ name="dpkg-shlibdeps" section="1">.
+ </p>
+ </sect>
+ <sect id="shlibs"><heading>The <tt>shlibs</tt> File Format
+ </heading>
+
+ <p>
+ Each <tt>shlibs</tt> file has the same format. Lines
+ beginning with <tt>#</tt> are considered to be commments and
+ are ignored. Each line is of the form:
+ <example compact="compact">
+<var>library-name</var> <var>soname-version-number</var> <var>dependencies ...</var>
+ </example>
+ </p>
+
+ <p>
+ We will explain this by reference to the example of the
+ <tt>zlib1g</tt> package, which (at the time of writing)
+ installs the shared library <tt>/usr/lib/libz.so.1.1.3</tt>.
+ </p>
+
+ <p>
+ <var>library-name</var> is the name of the shared library,
+ in this case <tt>libz</tt>. (This must match the name part
+ of the soname, see below.)
+ </p>
+
+ <p>
+ <var>soname-version-number</var> is the version part of the
+ soname of the library. The soname is the thing that must
+ exactly match for the library to be recognized by the
+ dynamic linker, and is usually of the form
+ <tt><var>name</var>.so.<var>major-version</var></tt>, in our
+ example, <tt>libz.so.1</tt>.
+ <footnote>
<p>
- Put a call to <prgn>dpkg-shlibdeps</prgn> into your
- <tt>debian/rules</tt> file. If your package contains
- only binaries (e.g. no scripts) use:
- <example>
- dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/*
+ This can be determined using the command
+ <example compact="compact">
+objdump -p /usr/lib/libz.so.1.1.3 | grep SONAME
</example>
- If <prgn>dpkg-shlibdeps</prgn> doesn't complain, you're
- done. If it does complain you might need to create your
- own <tt>debian/shlibs.local</tt> file.</p>
- </sect2>
+ </p>
+ </footnote>
+ The version part is the part which comes after
+ <tt>.so.</tt>, so in our case, it is <tt>1</tt>.
+ </p>
- <sect2><heading>If your package provides a shared library
- </heading>
+ <p>
+ <var>dependencies</var> has the same syntax as a dependency
+ field in a binary package control file. It should give
+ details of which packages are required to satisfy a binary
+ built against the version of the library contained in the
+ package. See <ref id="depsyntax"> for details.
+ </p>
+ <p>
+ In our example, if the first version of the <tt>zlib1g</tt>
+ package which contained a minor number of at least
+ <tt>1.3</tt> was <var>1:1.1.3-1</var>, then the
+ <tt>shlibs</tt> entry for this library could say:
+ <example compact="compact">
+libz 1 zlib1g (>= 1:1.1.3)
+ </example>
+ The version-specific dependency is to avoid warnings from
+ the dynamic linker about using older shared libraries with
+ newer binaries.
+ </p>
+ </sect>
+
+ <sect>
+ <heading>Providing a <tt>shlibs</tt> file</heading>
+
+ <p>
+ If your package provides a shared library, you should create
+ a <tt>shlibs</tt> file following the format described above.
+ It is usual to call this file <tt>debian/shlibs</tt> (but if
+ you have multiple binary packages, you might want to call it
+ <tt>debian/shlibs.<var>package</var></tt> instead). Then
+ let <tt>debian/rules</tt> install it in the control area:
+ <example compact="compact">
+install -m644 debian/shlibs debian/tmp/DEBIAN
+ </example>
+ or, in the case of a multi-binary package:
+ <example compact="compact">
+install -m644 debian/shlibs.<var>package</var> debian/<var>package</var>/DEBIAN/shlibs
+ </example>
+ An alternative way of doing this is to create the
+ <tt>shlibs</tt> file in the control area directly from
+ <tt>debian/rules</tt> without using a <tt>debian/shlibs</tt>
+ file at all,
+ <footnote>
<p>
- Create a <tt>debian/shlibs</tt> file and let
- <tt>debian/rules</tt> install it in the control area:
- <example>
- install -m644 debian/shlibs debian/tmp/DEBIAN
- </example>
- If your package contains additional binaries see above.
+ This is what <prgn>dh_makeshlibs</prgn> in the
+ <tt>debhelper</tt> suite does.
</p>
- </sect2>
- </sect1>
+ </footnote>
+ since the <tt>debian/shlibs</tt> file itself is ignored by
+ <prgn>dpkg-shlibdeps</prgn>.
+ </p>
- <sect1><heading><em>How</em> to write
- <tt>debian/shlibs.local</tt>
- </heading>
+ <p>
+ As <prgn>dpkg-shlibdeps</prgn> reads the
+ <tt>DEBIAN/shlibs</tt> files in all of the binary packages
+ being built from this source package, all of the
+ <tt>DEBIAN/shlibs</tt> files should be installed before
+ <prgn>dpkg-shlibdeps</prgn> is called on any of the binary
+ packages.
+ </p>
+ </sect>
- <p>
- This file is intended only as a <em>temporary</em> fix if
- your binaries depend on a library which doesn't provide
- its own <tt>/var/lib/dpkg/info/*.shlibs</tt> file yet.
- </p>
+ <sect id="shlibslocal">
+ <heading>Writing the <tt>debian/shlibs.local</tt> file</heading>
- <p>
- Let's assume you are packaging a binary <tt>foo</tt>. Your
- output in building the package might look like this.
- <example>
- $ ldd foo
- libbar.so.1 => /usr/X11R6/lib/libbar.so.1.0 (0x4001e000)
- libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4002c000)
- libc.so.6 => /lib/libc.so.6 (0x40114000)
- /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
- </example>
- And when you ran <prgn>dpkg-shlibdeps</prgn>
- <example>
- $ dpkg-shlibdeps -O foo
- dpkg-shlibdeps: warning: unable to find dependency information for shared library libbar
- (soname 1, path /usr/X11R6/lib/libbar.so.1.0, dependency field Depends)
- shlibs:Depends=libc6 (>= 2.2.1), xlibs (>= 4.0.1-11)
- </example>
- The <prgn>foo</prgn> binary depends on the
- <prgn>libbar</prgn> shared library, but no package seems
- to provide a <tt>*.shlibs</tt> file in
- <tt>/var/lib/dpkg/info/</tt>. Let's determine the package
- responsible:
- </p>
+ <p>
+ This file is intended only as a <em>temporary</em> fix if
+ your binaries or libraries depend on a library whose package
+ does not yet provide a correct <tt>shlibs</tt> file.
+ </p>
- <p>
- <example>
- $ dpkg -S /usr/X11R6/lib/libbar.so.1.0
- bar1: /usr/X11R6/lib/libbar.so.1.0
- $ dpkg -s bar1 | grep Version
- Version: 1.0-1
- </example>
- This tells us that the <prgn>bar1</prgn> package, version
- 1.0-1 is the one we are using. Now we can create our own
- <tt>debian/shlibs.local</tt> to temporarily fix the above
- problem. Include the following line into your
- <tt>debian/shlibs.local</tt> file.
- <example>
- libbar 1 bar1 (>= 1.0-1)
- </example>
- Now your package build should work. As soon as the
- maintainer of <prgn>libbar1</prgn> provides a
- <tt>shlibs</tt> file, you can remove your
- <tt>debian/shlibs.local</tt> file.
- </p>
- </sect1>
+ <p>
+ We will assume that you are trying to package a binary
+ <tt>foo</tt>. When you try running
+ <prgn>dpkg-shlibdeps</prgn> you get the following error
+ message (<tt>-O</tt> displays the dependency information on
+ <tt>stdout</tt> instead of writing it to
+ <tt>debian/substvars</tt>, and the lines have been wrapped
+ for ease of reading):
+ <example compact="compact">
+$ dpkg-shlibdeps -O debian/tmp/usr/bin/foo
+dpkg-shlibdeps: warning: unable to find dependency
+ information for shared library libbar (soname 1,
+ path /usr/lib/libbar.so.1, dependency field Depends)
+shlibs:Depends=libc6 (>= 2.2.2-2)
+ </example>
+ You can then run <prgn>ldd</prgn> on the binary to find the
+ full location of the library concerned:
+ <example compact="compact">
+$ ldd foo
+libbar.so.1 => /usr/lib/libbar.so.1 (0x4001e000)
+libc.so.6 => /lib/libc.so.6 (0x40032000)
+/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
+ </example>
+ So the <prgn>foo</prgn> binary depends on the
+ <prgn>libbar</prgn> shared library, but no package seems to
+ provide a <tt>*.shlibs</tt> file handling
+ <tt>libbar.so.1</tt> in <tt>/var/lib/dpkg/info/</tt>. Let's
+ determine the package responsible:
+ <example compact="compact">
+$ dpkg -S /usr/lib/libbar.so.1
+bar1: /usr/lib/libbar.so.1
+$ dpkg -s bar1 | grep Version
+Version: 1.0-1
+ </example>
+ This tells us that the <tt>bar1</tt> package, version 1.0-1,
+ is the one we are using. Now we can file a bug against the
+ <tt>bar1</tt> package and create our own
+ <tt>debian/shlibs.local</tt> to locally fix the problem.
+ Including the following line into your
+ <tt>debian/shlibs.local</tt> file:
+ <example compact="compact">
+libbar 1 bar1 (>= 1.0-1)
+ </example>
+ should allow the package build to work.
+ </p>
+
+ <p>
+ As soon as the maintainer of <tt>bar1</tt> provides a
+ correct <tt>shlibs</tt> file, you should remove this line
+ from your <tt>debian/shlibs.local</tt> file. (You should
+ probably also then have a versioned <tt>Build-Depends</tt>
+ on <tt>bar1</tt> to help ensure that others do not have the
+ same problem building your package.)
+ </p>
</sect>
</chapt>
<chapt><heading>The Operating System</heading>
-
<sect>
<heading>File system hierarchy</heading>
<p>
For example, the <prgn>emacs</prgn> package will contain
- <example>
- mkdir -p /usr/local/lib/emacs/site-lisp || true
+ <example compact="compact">
+mkdir -p /usr/local/lib/emacs/site-lisp || true
</example>
in the <tt>postinst</tt> script, and
- <example>
- rmdir /usr/local/lib/emacs/site-lisp || true
- rmdir /usr/local/lib/emacs || true
+ <example compact="compact">
+rmdir /usr/local/lib/emacs/site-lisp || true
+rmdir /usr/local/lib/emacs || true
</example>
in the <tt>prerm</tt> script.</p>
<p>
Apart from this we should have dynamically allocated ids,
which should by default be arranged in some sensible
- order--but the behavior should be configurable.</p>
+ order, but the behavior should be configurable.</p>
<p>
Packages other than <tt>base-passwd</tt> must not modify
<p>
The two-digit number <var>mm</var> is used to decide which
- order to start and stop things in--low-numbered links have
+ order to start and stop things in: low-numbered links have
their scripts run first. For example, the <tt>K20</tt>
scripts will be executed before the <tt>K30</tt> scripts.
This is used when a certain service must be started before
access lists. In this case, the script that starts
<prgn>bind</prgn> would have a lower number than the
script that starts <prgn>inn</prgn> so that it runs first:
- <example>
- /etc/rc2.d/S17bind
- /etc/rc2.d/S70inn
+ <example compact="compact">
+/etc/rc2.d/S17bind
+/etc/rc2.d/S70inn
</example>
</p>
</sect1>
the package is removed but not purged. Therefore, you
should include a <tt>test</tt> statement at the top of the
script, like this:
- <example>
- test -f <var>program-executed-later-in-script</var> || exit 0
+ <example compact="compact">
+test -f <var>program-executed-later-in-script</var> || exit 0
</example></p>
<p>
<p>
To get the default behavior for your package, put in your
<tt>postinst</tt> script
- <example>
- update-rc.d <var>package</var> defaults >/dev/null
+ <example compact="compact">
+update-rc.d <var>package</var> defaults >/dev/null
</example>
and in your <tt>postrm</tt>
- <example>
- if [ purge = "$1" ]; then
- update-rc.d <var>package</var> remove >/dev/null
- fi
+ <example compact="compact">
+if [ purge = "$1" ]; then
+ update-rc.d <var>package</var> remove >/dev/null
+fi
</example></p>
<p>
correctly in the maintainer scripts (see
<ref id="config files">). (This is important since we want
to give the local system administrator the chance to adapt
- the scripts to the local system--e.g., to disable a
+ the scripts to the local system, e.g., to disable a
service without de-installing the package, or to specify
some special command line options when starting a
- service--while making sure her changes aren't lost during
+ service, while making sure her changes aren't lost during
the next package upgrade.)</p>
</sect1>
</p>
<p>
- <example>
- #!/bin/sh
- #
- # Original version by Robert Leslie
- # <rob@mars.org>, edited by iwj and cs
-
- test -x /usr/sbin/named || exit 0
-
- # Source defaults file.
- PARAMS=''
- if [ -f /etc/default/bind ]; then
- . /etc/default/bind
- fi
-
-
- case "$1" in
- start)
- echo -n "Starting domain name service: named"
- start-stop-daemon --start --quiet --exec /usr/sbin/named \
- -- $PARAMS
- echo "."
- ;;
- stop)
- echo -n "Stopping domain name service: named"
- start-stop-daemon --stop --quiet \
- --pidfile /var/run/named.pid --exec /usr/sbin/named
- echo "."
- ;;
- restart)
- echo -n "Restarting domain name service: named"
- start-stop-daemon --stop --quiet \
- --pidfile /var/run/named.pid --exec /usr/sbin/named
- start-stop-daemon --start --verbose --exec /usr/sbin/named \
- -- $PARAMS
- echo "."
- ;;
- force-reload|reload)
- echo -n "Reloading configuration of domain name service: named"
- start-stop-daemon --stop --signal 1 --quiet \
- --pidfile /var/run/named.pid --exec /usr/sbin/named
- echo "."
- ;;
- *)
- echo "Usage: /etc/init.d/bind {start|stop|restart|reload|force-reload}" >&2
- exit 1
- ;;
- esac
-
- exit 0
+ <example compact="compact">
+#!/bin/sh
+#
+# Original version by Robert Leslie
+# <rob@mars.org>, edited by iwj and cs
+
+test -x /usr/sbin/named || exit 0
+
+# Source defaults file.
+PARAMS=''
+if [ -f /etc/default/bind ]; then
+ . /etc/default/bind
+fi
+
+
+case "$1" in
+start)
+ echo -n "Starting domain name service: named"
+ start-stop-daemon --start --quiet --exec /usr/sbin/named \
+ -- $PARAMS
+ echo "."
+ ;;
+stop)
+ echo -n "Stopping domain name service: named"
+ start-stop-daemon --stop --quiet \
+ --pidfile /var/run/named.pid --exec /usr/sbin/named
+ echo "."
+ ;;
+restart)
+ echo -n "Restarting domain name service: named"
+ start-stop-daemon --stop --quiet \
+ --pidfile /var/run/named.pid --exec /usr/sbin/named
+ start-stop-daemon --start --verbose --exec /usr/sbin/named \
+ -- $PARAMS
+ echo "."
+ ;;
+force-reload|reload)
+ echo -n "Reloading configuration of domain name service: named"
+ start-stop-daemon --stop --signal 1 --quiet \
+ --pidfile /var/run/named.pid --exec /usr/sbin/named
+ echo "."
+ ;;
+*)
+ echo "Usage: /etc/init.d/bind {start|stop|restart|reload|force-reload}" >&2
+ exit 1
+ ;;
+esac
+
+exit 0
</example>
</p>
parameters used by the script.
</p>
<p>
- <example>
- # Specified parameters to pass to named. See named(8).
- # You may uncomment the following line, and edit to taste.
- #PARAMS="-u nobody"
+ <example compact="compact">
+# Specified parameters to pass to named. See named(8).
+# You may uncomment the following line, and edit to taste.
+#PARAMS="-u nobody"
</example>
</p>
<prgn>update-rc.d</prgn>, namely an ordering number of 20
and having named running in all runlevels, it can say in
its <tt>postinst</tt>:
- <example>
- update-rc.d bind defaults >/dev/null
+ <example compact="compact">
+update-rc.d bind defaults >/dev/null
</example>
And in its <tt>postrm</tt>, to remove the links when the
package is purged:
- <example>
- if [ purge = "$1" ]; then
- update-rc.d bind remove >/dev/null
- fi
+ <example compact="compact">
+if [ purge = "$1" ]; then
+ update-rc.d bind remove >/dev/null
+fi
</example></p>
</sect1></sect>
If a package wants to install a job that has to be executed
via cron, it should place a file with the name of the
package in one of the following directories:
- <example>
- /etc/cron.daily
- /etc/cron.weekly
- /etc/cron.monthly
+ <example compact="compact">
+/etc/cron.daily
+/etc/cron.weekly
+/etc/cron.monthly
</example>
As these directory names imply, the files within them are
executed on a daily, weekly, or monthly basis,
<p>
If a certain job has to be executed more frequently than
daily, the package should install a file
- <tt>/etc/cron.d/<var>package-name</var></tt>. This file uses
+ <tt>/etc/cron.d/<var>package</var></tt>. This file uses
the same syntax as <tt>/etc/crontab</tt> and is processed by
<prgn>cron</prgn> automatically. The file must also be
treated as a configuration file. (Note, that entries in the
what he is doing (let him be polite :-) but don't
mention ``him'' directly. For example, if you think
of saying
- <example>
- I'm starting network daemons: nfsd mountd.
+ <example compact="compact">
+I'm starting network daemons: nfsd mountd.
</example>
just say
- <example>
- Starting network daemons: nfsd mountd.
- </example></p></item>
- </list></p>
+ <example compact="compact">
+Starting network daemons: nfsd mountd.
+ </example>
+ </p>
+ </item>
+ </list>
+ </p>
<p>
The following formats should be used</p>
Use this format if your script starts one or more
daemons. The output should look like this (a single
line, no leading spaces):
- <example>
- Starting <description>: <daemon-1> <daemon-2> <...> <daemon-n>.
+ <example compact="compact">
+Starting <description>: <daemon-1> ... <daemon-n>.
</example>
The <description> should describe the subsystem
the daemon or set of daemons are part of, while
<p>
For example, the output of /etc/init.d/lpd would look like:
- <example>
- Starting printer spooler: lpd.
+ <example compact="compact">
+Starting printer spooler: lpd.
</example></p>
<p>
This can be achieved by saying
- <example>
- echo -n "Starting printer spooler: lpd"
- start-stop-daemon --start --quiet lpd
- echo "."
+ <example compact="compact">
+echo -n "Starting printer spooler: lpd"
+start-stop-daemon --start --quiet lpd
+echo "."
</example>
in the script. If you have more than one daemon to
start, you should do the following:
- <example>
- echo -n "Starting remote file system services:"
- echo -n " nfsd"; start-stop-daemon --start --quiet nfsd
- echo -n " mountd"; start-stop-daemon --start --quiet mountd
- echo -n " ugidd"; start-stop-daemon --start --quiet ugidd
- echo "."
+ <example compact="compact">
+echo -n "Starting remote file system services:"
+echo -n " nfsd"; start-stop-daemon --start --quiet nfsd
+echo -n " mountd"; start-stop-daemon --start --quiet mountd
+echo -n " ugidd"; start-stop-daemon --start --quiet ugidd
+echo "."
</example>
This makes it possible for the user to see what takes
so long and when the final daemon has been
example above the system administrator can easily
comment out a line if he don't wants to start a
specific daemon, while the displayed message still
- looks good.</p></item>
-
+ looks good.
+ </p>
+ </item>
<item>
<p>when something needs to be configured.</p>
<p>
If you have to set up different parameters of the
system upon boot up, you should use this format:
- <example>
- Setting <parameter> to `<value>'.
- </example></p>
+ <example compact="compact">
+Setting <parameter> to `<value>'.
+ </example>
+ </p>
<p>
You can use the following echo statement to get the quotes right:
- <example>
- echo "Setting DNS domainname to \`"value"'."
- </example></p>
+ <example compact="compact">
+echo "Setting DNS domainname to \`"value"'."
+ </example>
+ </p>
<p>
Note that the left quotation mark (`) is different
- from the right (').</p></item>
+ from the right (').
+ </p>
+ </item>
<item>
<p>when a daemon is stopped.</p>
<p>
So stopping the printer daemon will like like this:
- <example>
- Stopping printer spooler: lpd.
+ <example compact="compact">
+Stopping printer spooler: lpd.
</example></p></item>
<item>
specific task. For example, setting the system's clock
via `netdate' or killing all processes when the system
comes down. Your message should like this:
- <example>
- Doing something very useful...done.
+ <example compact="compact">
+Doing something very useful...done.
</example>
You should print the `done.' right after the job has been completed,
so that the user gets informed why he has to wait. You can get this
behavior by saying
- <example>
- echo -n "Doing something very useful..."
- do_something
- echo "done."
+ <example compact="compact">
+echo -n "Doing something very useful..."
+do_something
+echo "done."
</example>
- in your script.</p></item>
+ in your script.
+ </p>
+ </item>
<item>
<p>when the configuration is reloaded.</p>
<p>
When a daemon is forced to reload its configuration
files you should use the following format:
- <example>
- Reloading <daemon's-name> configuration...done.
- </example></p></item>
+ <example compact="compact">
+Reloading <daemon's-name> configuration...done.
+ </example>
+ </p>
+ </item>
<item>
<p>when none of the above rules apply.</p>
If you have to print a message that doesn't fit into
the styles described above, you can use something
appropriate, but please have a look at the overall
- rules listed above.</p></item>
- </list></p></sect>
-
+ rules listed above.
+ </p>
+ </item>
+ </list>
+ </p>
+ </sect>
<sect>
<heading>Menus</heading>
should be set up to achieve this:</p>
<p>
- <list compact="compact">
+ <list>
<item><p>`<tt><--</tt>' generates KB_Backspace in
X.</p></item>
This will solve the problem except for:</p>
<p>
- <list compact="compact">
+ <list>
<item><p>
Some terminals have a <tt><--</tt> key that cannot
be made to produce anything except <tt>^H</tt>. On
<p>
Here is an example of a wrapper script for this purpose:
- <example>
- #!/bin/sh
- BAR=${BAR:-/var/lib/fubar}
- export BAR
- exec /usr/lib/foo/foo "$@"
+ <example compact="compact">
+#!/bin/sh
+BAR=${BAR:-/var/lib/fubar}
+export BAR
+exec /usr/lib/foo/foo "$@"
</example></p>
<p>
<p>
Generally the following compilation parameters should be used:
- <example>
- CC = gcc
- CFLAGS = -O2 -Wall # sane warning options vary between programs
- LDFLAGS = # none
- install -s # (or use strip on the files in debian/tmp)
+ <example compact="compact">
+CC = gcc
+CFLAGS = -O2 -Wall # sane warning options vary between programs
+LDFLAGS = # none
+install -s # (or use strip on the files in debian/tmp)
</example></p>
<p>
compiling that package.
</p>
<p>Now this has several added benefits:
- <list>
+ <list compact="compact">
<item>
<p>
It is actually easier to build debugging bins and
</footnote>
- <example>
- CFLAGS = -O2 -Wall
- INSTALL = install
- INSTALL_FILE = $(INSTALL) -p -o root -g root -m 644
- INSTALL_PROGRAM = $(INSTALL) -p -o root -g root -m 755
- INSTALL_SCRIPT = $(INSTALL) -p -o root -g root -m 755
- INSTALL_DIR = $(INSTALL) -p -d -o root -g root -m 755
-
- ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
- CFLAGS += -g
- endif
- ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
- INSTALL_PROGRAM += -s
- endif
+ <example compact="compact">
+CFLAGS = -O2 -Wall
+INSTALL = install
+INSTALL_FILE = $(INSTALL) -p -o root -g root -m 644
+INSTALL_PROGRAM = $(INSTALL) -p -o root -g root -m 755
+INSTALL_SCRIPT = $(INSTALL) -p -o root -g root -m 755
+INSTALL_DIR = $(INSTALL) -p -d -o root -g root -m 755
+
+ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
+CFLAGS += -g
+endif
+ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
+INSTALL_PROGRAM += -s
+endif
</example>
Please note that the above example is merely informative,
here. Don't use flags for the sake of it; only use them
if there is good reason to do so. Feel free to override
the upstream author's ideas about which compilation
- options are best--they are often inappropriate for our
+ options are best: they are often inappropriate for our
environment.</p></sect>
<p>
Note that all installed shared libraries should be
stripped with
- <example>
- strip --strip-unneeded <your-lib>
+ <example compact="compact">
+strip --strip-unneeded <your-lib>
</example>
- (The option `--strip-unneeded' makes <tt>strip</tt> remove
- only the symbols which aren't needed for relocation
- processing.) Shared libraries can function perfectly well
- when stripped, since the symbols for dynamic linking are
- in a separate part of the ELF object file.</p>
+ (The option <tt>--strip-unneeded</tt> makes
+ <prgn>strip</prgn> remove only the symbols which aren't
+ needed for relocation processing.) Shared libraries can
+ function perfectly well when stripped, since the symbols for
+ dynamic linking are in a separate part of the ELF object
+ file.</p>
<p>
Note that under some circumstances it may be useful to
libraries you need to create two packages:
<tt><var>libraryname</var><var>soname</var></tt>
(<var>soname</var> is the shared object name of the shared
- library--it's the thing that has to match exactly between
+ library: it's the thing that has to match exactly between
building an executable and running it for the dynamic
linker to be able run the program; usually the
<var>soname</var> is the major number of the library) and
without getting filename clashes. Instead, either create
a third package for the runtime binaries (this package
might typically be named
- <tt><var>libraryname</var>-runtime</tt>--note the absence
+ <tt><var>libraryname</var>-runtime</tt>; note the absence
of the <var>soname</var> in the package name) or if the
development package is small include them in there.</p>
<p>
For example, in your <prgn>Makefile</prgn> or
<tt>debian/rules</tt>, do things like:
- <example>
- ln -fs gcc $(prefix)/bin/cc
- ln -fs gcc debian/tmp/usr/bin/cc
- ln -fs ../sbin/sendmail $(prefix)/bin/runq
- ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
+ <example compact="compact">
+ln -fs gcc $(prefix)/bin/cc
+ln -fs gcc debian/tmp/usr/bin/cc
+ln -fs ../sbin/sendmail $(prefix)/bin/runq
+ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
</example></p>
<p>
<p>
Configuration file handling must conform to the following
behavior:
- <list>
+ <list compact="compact">
<item>
<p>local changes must be preserved during a package
upgrade</p>
logrotate. Here is a good example for a logrotate config
file (for more information see <manref name="logrotate"
section="8">):
- <example>
- /var/log/foo/* {
- rotate 12
- weekly
- compress
- postrotate
- /etc/init.d/foo force-reload
- endscript
- }
+ <example compact="compact">
+/var/log/foo/* {
+rotate 12
+weekly
+compress
+postrotate
+/etc/init.d/foo force-reload
+endscript
+}
</example>
Which rotates all files under `/var/log/foo', saves 12
compressed generations, and sends a HUP signal at the end of
<p>
Directories should be mode 755 or (for group-writability)
mode 2775. The ownership of the directory should be
- consistent with its mode--if a directory is mode 2775, it
+ consistent with its mode: if a directory is mode 2775, it
should be owned by the group that needs write access to
it.</p>
They should not be made unreadable (modes like 4711 or
2711 or even 4111); doing so achieves no extra security,
because anyone can find the binary in the freely available
- Debian package--it is merely inconvenient. For the same
+ Debian package, it is merely inconvenient. For the same
reason you should not restrict read or execute permissions
on non-set-id executables.</p>
<p>
If a program needs to specify an <em>architecture specification
string</em> in some place, the following format should be used:
- <example>
- <arch>-<os>
+ <example compact="compact">
+<arch>-<os>
</example>
where `<arch>' is one of the following: i386, alpha, arm, m68k,
powerpc, sparc and `<os>' is one of: linux, gnu. Use
<item>
<p>Cgi-bin executable files are installed in the
directory
- <example>
- /usr/lib/cgi-bin/<cgi-bin-name>
+ <example compact="compact">
+/usr/lib/cgi-bin/<cgi-bin-name>
</example>
and should be referred to as
- <example>
- http://localhost/cgi-bin/<cgi-bin-name>
- </example></p></item>
-
+ <example compact="compact">
+http://localhost/cgi-bin/<cgi-bin-name>
+ </example>
+ </p>
+ </item>
<item><p>Access to html documents</p>
<tt>/usr/doc/<var>package</var></tt><footnote> for
backward compatibility, see <ref id="usrdoc"></footnote>
and can be referred to as
- <example>
- http://localhost/doc/<package>/<filename>
- </example></p></item>
-
+ <example compact="compact">
+http://localhost/doc/<package>/<filename>
+ </example>
+ </p>
+ </item>
<item><p>Web Document Root</p>
/usr/share/doc/<package> directory for documents and
register the Web Application via the menu package. If
access to the web-root is unavoidable then use
- <example>
- /var/www
+ <example compact="compact">
+/var/www
</example>
as the Document Root. This might be just a
symbolic link to the location where the sysadmin has
<p>
<tt>/etc/aliases</tt> is the source file for the system mail
- aliases (e.g., postmaster, usenet, etc.)--it is the one
+ aliases (e.g., postmaster, usenet, etc.), it is the one
which the sysadmin and <tt>postinst</tt> scripts may edit.
After <tt>/etc/aliases</tt> is edited the program or human
editing it must call <prgn>newaliases</prgn>. All MTA
configuration. The prompt should make it clear that the
name will not just be used by that package. For example, in
this situation the INN package says:
- <example>
- Please enter the `mail name' of your system. This is the
- hostname portion of the address to be shown on outgoing
- news and mail messages. The default is
- <var>syshostname</var>, your system's host name. Mail
- name [`<var>syshostname</var>']:
+ <example compact="compact">
+Please enter the `mail name' of your system. This is the
+hostname portion of the address to be shown on outgoing
+news and mail messages. The default is
+<var>syshostname</var>, your system's host name. Mail
+name [`<var>syshostname</var>']:
</example>
where <var>syshostname</var> is the output of <tt>hostname
- --fqdn</tt>.</p></sect>
-
+ --fqdn</tt>.
+ </p>
+ </sect>
<sect>
<heading>News system configuration</heading>
<tt>x-window-manager</tt>. They should also register themselves as an
alternative for <tt>/usr/bin/x-window-manager</tt>, with a priority
calculated as follows:
- <list>
+ <list compact="compact">
<item>Start with a priority of 20.</item>
<item>If the window manager supports the Debian menu system,
add 20 points if this support is available in the
<item>
BDF fonts should be converted to PCF fonts with the
<tt>bdftopcf</tt> utility (available in the
- <tt>xutils</tt> package, <tt>gzip</tt>ped, and
+ <tt>xutils</tt> package), <tt>gzip</tt>ped, and
placed in a directory that corresponds to their
resolution:
- <list>
+ <list compact="compact">
<item>
100 dpi fonts should be placed in
<tt>/usr/X11R6/lib/X11/fonts/100dpi/</tt>.
Font packages <em>must not</em> provide the files
<tt>fonts.dir</tt>, <tt>fonts.alias</tt>, or
<tt>fonts.scale</tt> in a font directory.
- <list>
+ <list compact="compact">
<item>
<tt>fonts.dir</tt> files must not be provided at
all.
</p>
<p>
- <em>Packages using the X Window System should abide by the FHS
- standard whenever possible</em>; they should install binaries,
- libraries, manual pages, and other files in FHS-mandated
- locations wherever possible. This means that files must
- not be installed into <tt>/usr/X11R6/bin/</tt>,
- <tt>/usr/X11R6/lib/</tt>, or <tt>/usr/X11R6/man/</tt> unless
- this is necessary for the package to operate properly.
- Configuration files for window managers and display managers
- should be placed in a subdirectory of <tt>/etc/X11/</tt>
- corresponding to the package name due to these programs'
- tight integration with the mechanisms of the X Window
- System. Application-level programs should use the
- <tt>/etc/</tt> directory unless otherwise mandated by
- policy. The installation of files into subdirectories of
- <tt>/usr/X11R6/include/X11/</tt> and
- <tt>/usr/X11R6/lib/X11/</tt> is permitted but discouraged;
- package maintainers should determine if subdirectories of
- <tt>/usr/lib/</tt> and <tt>/usr/share/</tt> can be used
- instead (symlinks from the X11R6 directories to
- FHS-compliant locations is encouraged if the program is not
- easily configured to look elsewhere for its files).
- Packages must not provide -- or install files into -- the
- directories <tt>/usr/bin/X11/</tt>,
- <tt>/usr/include/X11/</tt>, or <tt>/usr/lib/X11/</tt>.
- Files within a package should, however, make reference to
- these directories, rather than their X11R6-named
- counterparts <tt>/usr/X11R6/bin/</tt>,
- <tt>/usr/X11R6/include/X11/</tt>, and
- <tt>/usr/X11R6/lib/X11/</tt>, if the resources being
- referred to have not been moved to FHS-compliant locations.
+ <em>Packages using the X Window System should abide by the
+ FHS standard whenever possible</em>; they should install
+ binaries, libraries, manual pages, and other files in
+ FHS-mandated locations wherever possible. This means that
+ files must not be installed into <tt>/usr/X11R6/bin/</tt>,
+ <tt>/usr/X11R6/lib/</tt>, or <tt>/usr/X11R6/man/</tt>
+ unless this is necessary for the package to operate
+ properly. Configuration files for window managers and
+ display managers should be placed in a subdirectory of
+ <tt>/etc/X11/</tt> corresponding to the package name due
+ to these programs' tight integration with the mechanisms
+ of the X Window System. Application-level programs should
+ use the <tt>/etc/</tt> directory unless otherwise mandated
+ by policy. The installation of files into subdirectories
+ of <tt>/usr/X11R6/include/X11/</tt> and
+ <tt>/usr/X11R6/lib/X11/</tt> is permitted but discouraged;
+ package maintainers should determine if subdirectories of
+ <tt>/usr/lib/</tt> and <tt>/usr/share/</tt> can be used
+ instead (symlinks from the X11R6 directories to
+ FHS-compliant locations is encouraged if the program is
+ not easily configured to look elsewhere for its files).
+ Packages must not provide or install files into the
+ directories <tt>/usr/bin/X11/</tt>,
+ <tt>/usr/include/X11/</tt>, or <tt>/usr/lib/X11/</tt>.
+ Files within a package should, however, make reference to
+ these directories, rather than their X11R6-named
+ counterparts <tt>/usr/X11R6/bin/</tt>,
+ <tt>/usr/X11R6/include/X11/</tt>, and
+ <tt>/usr/X11R6/lib/X11/</tt>, if the resources being
+ referred to have not been moved to FHS-compliant
+ locations.
</p>
<p>
to the <manref name="undocumented" section="7"> manual page
may be provided. This symbolic link can be created from
<tt>debian/rules</tt> like this:
- <example>
- ln -s ../man7/undocumented.7.gz \
- debian/tmp/usr/share/man/man[1-9]/the_requested_manpage.[1-9].gz
+ <example compact="compact">
+ln -s ../man7/undocumented.7.gz \
+debian/tmp/usr/share/man/man[1-9]/the_requested_manpage.[1-9].gz
</example>
This manpage claims that the lack of a manpage has been
reported as a bug, so you may only do this if it really has
upstream authors, and mark the bug as forwarded in the
Debian bug tracking system. Even though the GNU Project do
not in general consider the lack of a manpage to be a bug,
- we do--if they tell you that they don't consider it a bug
+ we do; if they tell you that they don't consider it a bug
you should leave the bug in our bug tracking system open
anyway.</p>
is better to use a symbolic link than the <tt>.so</tt>
feature, but there is no need to fiddle with the relevant
parts of the upstream source to change from <tt>.so</tt> to
- symlinks--don't do it unless it's easy. You should not create hard
+ symlinks: don't do it unless it's easy. You should not create hard
links in the manual page directories, nor put
absolute filenames in <tt>.so</tt> directives. The filename
in a <tt>.so</tt> in a manpage should be relative to the
Your package should call <prgn>install-info</prgn> to update the Info
<tt>dir</tt>
file, in its post-installation script:
- <example>
- install-info --quiet --section Development Development \
- /usr/share/info/foobar.info
+ <example compact="compact">
+install-info --quiet --section Development Development \
+/usr/share/info/foobar.info
</example></p>
<p>
<p>
You should remove the entries in the pre-removal script:
- <example>
- install-info --quiet --remove /usr/share/info/foobar.info
+ <example compact="compact">
+install-info --quiet --remove /usr/share/info/foobar.info
</example></p>
<p>
with <prgn>dpkg</prgn>. One reasonable way to accomplish
this is to put the following in the package's
<prgn>postinst</prgn>:
- <example>
- if [ "$1" = "configure" ]; then
- if [ -d /usr/doc -a ! -e /usr/doc/#PACKAGE# \
- -a -d /usr/share/doc/#PACKAGE# ]; then
- ln -sf ../share/doc/#PACKAGE# /usr/doc/#PACKAGE#
- fi
- fi
+ <example compact="compact">
+if [ "$1" = "configure" ]; then
+ if [ -d /usr/doc -a ! -e /usr/doc/#PACKAGE# \
+ -a -d /usr/share/doc/#PACKAGE# ]; then
+ ln -sf ../share/doc/#PACKAGE# /usr/doc/#PACKAGE#
+ fi
+fi
</example>
And the following in the package's <prgn>prerm</prgn>:
- <example>
- if [ \( "$1" = "upgrade" -o "$1" = "remove" \) \
- -a -L /usr/doc/#PACKAGE# ]; then
- rm -f /usr/doc/#PACKAGE#
- fi
+ <example compact="compact">
+if [ \( "$1" = "upgrade" -o "$1" = "remove" \) \
+ -a -L /usr/doc/#PACKAGE# ]; then
+ rm -f /usr/doc/#PACKAGE#
+fi
</example>
</p>
</sect>
<p>
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.</p>
<p>
<p>
- /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
Any examples (configurations, source files, whatever),
should be installed in a directory
<tt>/usr/share/doc/<var>package</var>/examples</tt>. These
- files should not be referenced by any program--they're there
+ files should not be referenced by any program: they're there
for the benefit of the system administrator and users, as
documentation only. Architecture-specific example files
should be installed in a directory
projects / debian / debian-policy.git / blobdiff