+ <item>
+ <var>old-postinst</var> <tt>abort-upgrade</tt>
+ <var>new-version</var>
+ </item>
+ <item>
+ <var>conflictor's-postinst</var> <tt>abort-remove</tt>
+ <tt>in-favour</tt> <var>package</var>
+ <var>new-version</var>
+ </item>
+ <item>
+ <var>postinst</var> <tt>abort-remove</tt>
+ </item>
+ <item>
+ <var>deconfigured's-postinst</var>
+ <tt>abort-deconfigure</tt> <tt>in-favour</tt>
+ <var>failed-install-package</var> <var>version</var>
+ [<tt>removing</tt> <var>conflicting-package</var>
+ <var>version</var>]
+ </item>
+ </list>
+
+ <p>
+ <list compact="compact">
+ <item>
+ <var>prerm</var> <tt>remove</tt>
+ </item>
+ <item>
+ <var>old-prerm</var> <tt>upgrade</tt>
+ <var>new-version</var>
+ </item>
+ <item>
+ <var>new-prerm</var> <tt>failed-upgrade</tt>
+ <var>old-version</var>
+ </item>
+ <item>
+ <var>conflictor's-prerm</var> <tt>remove</tt>
+ <tt>in-favour</tt> <var>package</var>
+ <var>new-version</var>
+ </item>
+ <item>
+ <var>deconfigured's-prerm</var> <tt>deconfigure</tt>
+ <tt>in-favour</tt> <var>package-being-installed</var>
+ <var>version</var> [<tt>removing</tt>
+ <var>conflicting-package</var>
+ <var>version</var>]
+ </item>
+ </list>
+
+ <p>
+ <list compact="compact">
+ <item>
+ <var>postrm</var> <tt>remove</tt>
+ </item>
+ <item>
+ <var>postrm</var> <tt>purge</tt>
+ </item>
+ <item>
+ <var>old-postrm</var> <tt>upgrade</tt>
+ <var>new-version</var>
+ </item>
+ <item>
+ <var>new-postrm</var> <tt>failed-upgrade</tt>
+ <var>old-version</var>
+ </item>
+ <item>
+ <var>new-postrm</var> <tt>abort-install</tt>
+ </item>
+ <item>
+ <var>new-postrm</var> <tt>abort-install</tt>
+ <var>old-version</var>
+ </item>
+ <item>
+ <var>new-postrm</var> <tt>abort-upgrade</tt>
+ <var>old-version</var>
+ </item>
+ <item>
+ <var>disappearer's-postrm</var> <tt>disappear</tt>
+ <var>overwriter</var>
+ <var>overwriter-version</var>
+ </item>
+ </list>
+ </p>
+
+
+ <sect id="unpackphase">
+ <heading>Details of unpack phase of installation or upgrade</heading>
+
+ <p>
+ The procedure on installation/upgrade/overwrite/disappear
+ (i.e., when running <tt>dpkg --unpack</tt>, or the unpack
+ stage of <tt>dpkg --install</tt>) is as follows. In each
+ 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.
+
+ <enumlist>
+ <item>
+ <enumlist>
+ <item>
+ If a version of the package is already installed, call
+ <example compact="compact">
+<var>old-prerm</var> upgrade <var>new-version</var>
+ </example>
+ </item>
+ <item>
+ If the script runs but exits with a non-zero
+ exit status, <prgn>dpkg</prgn> will attempt:
+ <example compact="compact">
+<var>new-prerm</var> failed-upgrade <var>old-version</var>
+ </example>
+ If this works, the upgrade continues. If this
+ does not work, the error unwind:
+ <example compact="compact">
+<var>old-postinst</var> abort-upgrade <var>new-version</var>
+ </example>
+ If this works, then the old-version is
+ "Installed", if not, the old version is in a
+ "Failed-Config" state.
+ </item>
+ </enumlist>
+ </item>
+
+ <item>
+ If a "conflicting" package is being removed at the same time,
+ or if any package will be broken (due to <tt>Breaks</tt>):
+ <enumlist>
+ <item>
+ If <tt>--auto-deconfigure</tt> is
+ specified, call, for each package to be deconfigured
+ due to <tt>Breaks</tt>:
+ <example compact="compact">
+<var>deconfigured's-prerm</var> deconfigure \
+ in-favour <var>package-being-installed</var> <var>version</var>
+ </example>
+ Error unwind:
+ <example compact="compact">
+<var>deconfigured's-postinst</var> abort-deconfigure \
+ in-favour <var>package-being-installed-but-failed</var> <var>version</var>
+ </example>
+ The deconfigured packages are marked as
+ requiring configuration, so that if
+ <tt>--install</tt> is used they will be
+ configured again if possible.
+ </item>
+ <item>
+ If any packages depended on a conflicting
+ package being removed and <tt>--auto-deconfigure</tt> is
+ specified, call, for each such package:
+ <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 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
+ <tt>--install</tt> is used they will be
+ configured again if possible.
+ </item>
+ <item>
+ To prepare for removal of each conflicting package, call:
+ <example compact="compact">
+<var>conflictor's-prerm</var> remove \
+ in-favour <var>package</var> <var>new-version</var>
+ </example>
+ Error unwind:
+ <example compact="compact">
+<var>conflictor's-postinst</var> abort-remove \
+ in-favour <var>package</var> <var>new-version</var>
+ </example>
+ </item>
+ </enumlist>
+ </item>
+
+ <item>
+ <enumlist>
+ <item>
+ If the package is being upgraded, call:
+ <example compact="compact">
+<var>new-preinst</var> upgrade <var>old-version</var>
+ </example>
+ If this fails, we call:
+ <example>
+<var>new-postrm</var> abort-upgrade <var>old-version</var>
+ </example>
+ <enumlist>
+ <item>
+ <p>
+ If that works, then
+ <example>
+<var>old-postinst</var> abort-upgrade <var>new-version</var>
+ </example>
+ is called. If this works, then the old version
+ is in an "Installed" state, or else it is left
+ in an "Unpacked" state.
+ </p>
+ </item>
+ <item>
+ <p>
+ If it fails, then the old version is left
+ in an "Half-Installed" state.
+ </p>
+ </item>
+ </enumlist>
+
+ </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 compact="compact">
+<var>new-preinst</var> install <var>old-version</var>
+ </example>
+ Error unwind:
+ <example>
+<var>new-postrm</var> abort-install <var>old-version</var>
+ </example>
+ If this fails, the package is left in a
+ "Half-Installed" state, which requires a
+ reinstall. If it works, the packages is left in
+ a "Config Files" state.
+ </item>
+ <item>
+ Otherwise (i.e., the package was completely purged):
+ <example compact="compact">
+<var>new-preinst</var> install
+ </example>
+ Error unwind:
+ <example compact="compact">
+<var>new-postrm</var> abort-install
+ </example>
+ If the error-unwind fails, the package is in a
+ "Half Installed" phase, and requires a
+ reinstall. If the error unwind works, the
+ package is in a not installed state.
+ </item>
+ </enumlist>
+ </item>
+
+ <item>
+ <p>
+ The new package's files are unpacked, overwriting any
+ that may be on the system already, for example any
+ from the old version of the same package or from
+ another package. Backups of the old files are kept
+ temporarily, and if anything goes wrong the package
+ management system will attempt to put them back as
+ part of the error unwind.
+ </p>
+
+ <p>
+ It is an error for a package to contain files which
+ are on the system in another package, unless
+ <tt>Replaces</tt> is used (see <ref id="replaces">).
+ <!--
+ The following paragraph is not currently the case:
+ Currently the <tt>- - force-overwrite</tt> flag is
+ enabled, downgrading it to a warning, but this may not
+ always be the case.
+ -->
+ </p>
+
+ <p>
+ It is a more serious error for a package to contain a
+ plain file or other kind of non-directory where another
+ package has a directory (again, unless
+ <tt>Replaces</tt> is used). This error can be
+ overridden if desired using
+ <tt>--force-overwrite-dir</tt>, but this is not
+ advisable.
+ </p>
+
+ <p>
+ Packages which overwrite each other's files produce
+ 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
+ package, and is then removed again.<footnote>
+ Part of the problem is due to what is arguably a
+ bug in <prgn>dpkg</prgn>.
+ </footnote>
+ </p>
+
+ <p>
+ 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
+ <prgn>dpkg</prgn> will follow the symlink if there is
+ one.
+ </p>
+ </item>
+
+ <item>
+ <p>
+ <enumlist>
+ <item>
+ If the package is being upgraded, call
+ <example compact="compact">
+<var>old-postrm</var> upgrade <var>new-version</var>
+ </example>
+ </item>
+ <item>
+ If this fails, <prgn>dpkg</prgn> will attempt:
+ <example compact="compact">
+<var>new-postrm</var> failed-upgrade <var>old-version</var>
+ </example>
+ If this works, installation continues. If not,
+ Error unwind:
+ <example compact="compact">
+<var>old-preinst</var> abort-upgrade <var>new-version</var>
+ </example>
+ If this fails, the old version is left in an
+ "Half Installed" state. If it works, dpkg now
+ calls:
+ <example compact="compact">
+<var>new-postrm</var> abort-upgrade <var>old-version</var>
+ </example>
+ If this fails, the old version is left in an
+ "Half Installed" state. If it works, dpkg now
+ calls:
+ <example compact="compact">
+<var>old-postinst</var> abort-upgrade <var>new-version</var>
+ </example>
+ If this fails, the old version is in an
+ "Unpacked" state.
+ </item>
+ </enumlist>
+ </p>
+
+ <p>
+ This is the point of no return - if
+ <prgn>dpkg</prgn> gets this far, it won't back off
+ past this point if an error occurs. This will
+ leave the package in a fairly bad state, which
+ will require a successful re-installation to clear
+ up, but it's when <prgn>dpkg</prgn> starts doing
+ things that are irreversible.
+ </p>
+ </item>
+
+ <item>
+ Any files which were in the old version of the package
+ but not in the new are removed.
+ </item>
+
+ <item>
+ The new file list replaces the old.
+ </item>
+
+ <item>
+ The new maintainer scripts replace the old.
+ </item>
+
+ <item>
+ 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
+ <enumlist>
+ <item>
+ <prgn>dpkg</prgn> calls:
+ <example compact="compact">
+<var>disappearer's-postrm</var> disappear \
+ <var>overwriter</var> <var>overwriter-version</var>
+ </example>
+ </item>
+ <item>
+ The package's maintainer scripts are removed.
+ </item>
+ <item>
+ It is noted in the status database as being in a
+ sane state, namely not installed (any conffiles
+ it may have are ignored, rather than being
+ removed by <prgn>dpkg</prgn>). Note that
+ disappearing packages do not have their prerm
+ called, because <prgn>dpkg</prgn> doesn't know
+ in advance that the package is going to
+ vanish.
+ </item>
+ </enumlist>
+ </item>
+
+ <item>
+ Any files in the package we're unpacking that are also
+ listed in the file lists of other packages are removed
+ from those lists. (This will lobotomize the file list
+ of the "conflicting" package if there is one.)
+ </item>
+
+ <item>
+ The backup files made during installation, above, are
+ deleted.
+ </item>
+
+ <item>
+ <p>
+ The new package's status is now sane, and recorded as
+ "unpacked".
+ </p>
+
+ <p>
+ 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.
+ </p>
+ </item>
+
+ <item>
+ If there was a conflicting package we go and do the
+ removal actions (described below), starting with the
+ removal of the conflicting package's files (any that
+ are also in the package being installed have already
+ been removed from the conflicting package's file list,
+ and so do not get removed now).
+ </item>
+ </enumlist>
+ </p>
+ </sect>
+
+ <sect id="configdetails"><heading>Details of configuration</heading>
+
+ <p>
+ When we configure a package (this happens with <tt>dpkg
+ --install</tt> and <tt>dpkg --configure</tt>), we first
+ update any <tt>conffile</tt>s and then call:
+ <example compact="compact">
+<var>postinst</var> configure <var>most-recently-configured-version</var>
+ </example>
+ </p>
+
+ <p>
+ No attempt is made to unwind after errors during
+ configuration. If the configuration fails, the package is in
+ a "Failed Config" state, and an error message is generated.
+ </p>
+
+ <p>
+ If there is no most recently configured version
+ <prgn>dpkg</prgn> will pass a null argument.
+ <footnote>
+ <p>
+ Historical note: Truly ancient (pre-1997) versions of
+ <prgn>dpkg</prgn> passed <tt><unknown></tt>
+ (including the angle brackets) in this case. Even older
+ ones did not pass a second argument at all, under any
+ circumstance. Note that upgrades using such an old dpkg
+ version are unlikely to work for other reasons, even if
+ this old argument behavior is handled by your postinst script.
+ </p>
+ </footnote>
+ </p>
+ </sect>
+
+ <sect id="removedetails"><heading>Details of removal and/or
+ configuration purging</heading>
+
+ <p>
+ <enumlist>
+ <item>
+ <p>
+ <example compact="compact">
+<var>prerm</var> remove
+ </example>
+ </p>
+ <p>
+ If prerm fails during replacement due to conflict
+ <example>
+<var>conflictor's-postinst</var> abort-remove \
+ in-favour <var>package</var> <var>new-version</var>
+ </example>
+ Or else we call:
+ <example>
+<var>postinst</var> abort-remove
+ </example>
+ </p>
+ <p>
+ If this fails, the package is in a "Failed-Config"
+ state, or else it remains "Installed".
+ </p>
+ </item>
+ <item>
+ The package's files are removed (except <tt>conffile</tt>s).
+ </item>
+ <item>
+ <example compact="compact">
+<var>postrm</var> remove
+ </example>
+
+ <p>
+ If it fails, there's no error unwind, and the package is in
+ an "Half-Installed" state.
+ </p>
+ </item>
+ <item>
+ <p>
+ All the maintainer scripts except the <prgn>postrm</prgn>
+ are removed.
+ </p>
+
+ <p>
+ If we aren't purging the package we stop here. Note
+ that packages which have no <prgn>postrm</prgn> and no
+ <tt>conffile</tt>s are automatically purged when
+ removed, as there is no difference except for the
+ <prgn>dpkg</prgn> status.
+ </p>
+ </item>
+ <item>
+ The <tt>conffile</tt>s and any backup files
+ (<tt>~</tt>-files, <tt>#*#</tt> files,
+ <tt>%</tt>-files, <tt>.dpkg-{old,new,tmp}</tt>, etc.)
+ are removed.
+ </item>
+ <item>
+ <p>
+ <example compact="compact">
+<var>postrm</var> purge
+ </example>
+ </p>
+ <p>
+ If this fails, the package remains in a "Config-Files"
+ state.
+ </p>
+ </item>
+ <item>
+ The package's file list is removed.
+ </item>
+ </enumlist>
+
+ </p>
+ </sect>
+ </chapt>
+
+
+ <chapt id="relationships">
+ <heading>Declaring relationships between packages</heading>
+
+ <sect id="depsyntax">
+ <heading>Syntax of relationship fields</heading>
+
+ <p>
+ These fields all have a uniform syntax. They are a list of
+ package names separated by commas.
+ </p>
+
+ <p>
+ In the <tt>Depends</tt>, <tt>Recommends</tt>,
+ <tt>Suggests</tt>, <tt>Pre-Depends</tt>,
+ <tt>Build-Depends</tt> and <tt>Build-Depends-Indep</tt>
+ 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 (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 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="f-Version">.
+ </p>
+
+ <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 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>
+
+ <p>
+ Whitespace may appear at any point in the version
+ specification subject to the rules in <ref
+ id="controlsyntax">, and must appear where it's necessary to
+ disambiguate; it is not otherwise significant. All of the
+ relationship fields may span multiple lines. 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 also conventional to put a single space after
+ each comma, on either side of each vertical bar, and before
+ each open parenthesis. When wrapping a relationship field, it
+ is conventional to do so after a comma and before the space
+ following that comma.
+ </p>
+
+ <p>
+ 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>
+
+ <p>
+ All fields that specify build-time relationships
+ (<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 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.
+ (It is not permitted for some names to be prepended with
+ exclamation marks while others aren't.) If the current Debian
+ host architecture is not in this list and there are no
+ exclamation marks in the list, or it is in the list with a
+ prepended exclamation mark, the package name and the
+ associated version specification are ignored completely for
+ the purposes of defining the relationships.
+ </p>
+
+ <p>
+ For example:
+ <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>
+
+ <p>
+ Note that the binary package relationship fields such as
+ <tt>Depends</tt> appear in one of the binary package
+ sections of the control file, whereas the build-time
+ relationships such as <tt>Build-Depends</tt> appear in the
+ source package section of the control file (which is the
+ first section).
+ </p>
+ </sect>
+
+ <sect id="binarydeps">
+ <heading>Binary Dependencies - <tt>Depends</tt>,
+ <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Enhances</tt>,
+ <tt>Pre-Depends</tt>
+ </heading>
+
+ <p>
+ Packages can declare in their control file that they have
+ certain relationships to other packages - for example, that
+ they may not be installed at the same time as certain other
+ packages, and/or that they depend on the presence of others.
+ </p>
+
+ <p>
+ This is done using the <tt>Depends</tt>, <tt>Pre-Depends</tt>,
+ <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Enhances</tt>,
+ <tt>Breaks</tt> and <tt>Conflicts</tt> control file fields.
+ </p>
+
+ <p>
+ These seven fields are used to declare a dependency
+ relationship by one package on another. Except for
+ <tt>Enhances</tt> and <tt>Breaks</tt>, they appear in the
+ depending (binary) package's control file.
+ (<tt>Enhances</tt> appears in the recommending package's
+ control file, and <tt>Breaks</tt> appears in the version of
+ depended-on package which causes the named package to
+ break).
+ </p>
+
+ <p>
+ 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>apt-get</prgn>,
+ <prgn>aptitude</prgn>, and <prgn>dselect</prgn>.)
+ </p>
+
+ <p>
+ For this reason packages in an installation run are usually
+ all unpacked first and all configured later; this gives
+ later versions of packages with dependencies on later
+ versions of other packages the opportunity to have their
+ dependencies satisfied.
+ </p>
+
+ <p>
+ In case of circular dependencies, since installation or
+ removal order honoring the dependency order can't be
+ established, dependency loops are broken at some point
+ (based on rules below), and some packages may not be able to
+ rely on their dependencies being present when being
+ installed or removed, depending on which side of the break
+ of the circular dependency loop they happen to be on. If one
+ of the packages in the loop has no postinst script, then the
+ cycle will be broken at that package, so as to ensure that
+ all postinst scripts run with the dependencies properly
+ configured if this is possible. Otherwise the breaking point
+ is arbitrary.
+ </p>
+
+ <p>
+ 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. 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>
+
+ <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>
+ <item>
+ <p>
+ This declares a strong, but not absolute, dependency.
+ </p>
+
+ <p>
+ The <tt>Recommends</tt> field should list packages
+ that would be found together with this one in all but
+ unusual installations.
+ </p>
+ </item>
+
+ <tag><tt>Suggests</tt></tag>
+ <item>
+ This is used to declare that one package may be more
+ useful with one or more others. Using this field
+ tells the packaging system and the user that the
+ listed packages are related to this one and can
+ perhaps enhance its usefulness, but that installing
+ this one without them is perfectly reasonable.
+ </item>
+
+ <tag><tt>Enhances</tt></tag>
+ <item>
+ This field is similar to Suggests but works in the
+ opposite direction. It is used to declare that a
+ package can enhance the functionality of another
+ package.
+ </item>
+
+ <tag><tt>Pre-Depends</tt></tag>
+ <item>
+ <p>
+ This field is like <tt>Depends</tt>, except that it
+ 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, as follows:
+ </p>
+
+ <p>
+ 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 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>
+ <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.
+ </p>
+ </item>
+ </taglist>
+ </p>
+
+ <p>
+ When selecting which level of dependency to use you should
+ consider how important the depended-on package is to the
+ functionality of the one declaring the dependency. Some
+ packages are composed of components of varying degrees of
+ importance. Such a package should list using
+ <tt>Depends</tt> the package(s) which are required by the
+ more important components. The other components'
+ requirements may be mentioned as Suggestions or
+ Recommendations, as appropriate to the components' relative
+ importance.
+ </p>
+ </sect>
+
+ <sect id="breaks">
+ <heading>Packages which break other packages - <tt>Breaks</tt></heading>
+
+ <p>
+ Using <tt>Breaks</tt> may cause problems for upgrades from older
+ versions of Debian and should not be used until the stable
+ release of Debian supports <tt>Breaks</tt>.
+ </p>
+
+ <p>
+ When one binary package declares that it breaks another,
+ <prgn>dpkg</prgn> will refuse to allow the package which
+ declares <tt>Breaks</tt> be installed unless the broken
+ package is deconfigured first, and it will refuse to
+ allow the broken package to be reconfigured.
+ </p>
+
+ <p>
+ A package will not be regarded as causing breakage merely
+ because its configuration files are still installed; it must
+ be at least half-installed.
+ </p>
+
+ <p>
+ A special exception is made for packages which declare that
+ they break their own package name or a virtual package which
+ they provide (see below): this does not count as a real
+ breakage.
+ </p>
+
+ <p>
+ Normally a <tt>Breaks</tt> entry will have an "earlier than"
+ version clause; such a <tt>Breaks</tt> is introduced in the
+ version of an (implicit or explicit) dependency which
+ violates an assumption or reveals a bug in earlier versions
+ of the broken package. This use of <tt>Breaks</tt> will
+ inform higher-level package management tools that broken
+ package must be upgraded before the new one.
+ </p>
+
+ <p>
+ If the breaking package also overwrites some files from the
+ older package, it should use <tt>Replaces</tt> (not
+ <tt>Conflicts</tt>) to ensure this goes smoothly.
+ </p>
+ </sect>
+
+ <sect id="conflicts">
+ <heading>Conflicting binary packages - <tt>Conflicts</tt></heading>
+
+ <p>
+ When one binary package declares a conflict with another
+ 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 (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 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
+ half-installed.
+ </p>
+
+ <p>
+ A special exception is made for packages which declare a
+ conflict with their own package name, or with a virtual
+ package which they provide (see below): this does not
+ 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 some feature.
+ </p>
+
+ <p>
+ A <tt>Conflicts</tt> entry should almost never have an
+ "earlier than" version clause. This would prevent
+ <prgn>dpkg</prgn> from upgrading or installing the package
+ which declared such a conflict until the upgrade or removal
+ of the conflicted-with package had been completed. Instead,
+ <tt>Breaks</tt> may be used (once <tt>Breaks</tt> is supported
+ by the stable release of Debian).
+ </p>
+ </sect>
+
+ <sect id="virtual"><heading>Virtual packages - <tt>Provides</tt>
+ </heading>
+
+ <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>Breaks</tt>, <tt>Conflicts</tt>,
+ <tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
+ <tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt>
+ may mention "virtual packages".
+ </p>
+
+ <p>
+ 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
+ everywhere the virtual package name appears. (See also <ref
+ id="virtual_pkg">)
+ </p>
+
+ <p>
+ If there are both concrete and virtual packages of the same
+ name, then the dependency may be satisfied (or the conflict
+ caused) by either the concrete package with the name in
+ question or any other concrete package which provides the
+ virtual package with the name in question. This is so that,
+ for example, supposing we have
+ <example compact="compact">
+Package: foo
+Depends: bar
+ </example> and someone else releases an enhanced version of
+ the <tt>bar</tt> package they can say:
+ <example compact="compact">
+Package: bar-plus
+Provides: bar
+ </example>
+ and the <tt>bar-plus</tt> package will now also satisfy the
+ dependency for the <tt>foo</tt> package.
+ </p>
+
+ <p>
+ If a relationship field has a version number attached
+ then only real packages will be considered to see whether
+ the relationship is satisfied (or the prohibition violated,
+ for a conflict or breakage) - it is assumed that a real
+ package which provides the virtual package is not of the
+ "right" version. So, a <tt>Provides</tt> field may not
+ contain version numbers, and the version number of the
+ concrete package which provides a particular virtual package
+ will not be looked at when considering a dependency on or
+ conflict with the virtual package name.
+ </p>
+
+ <p>
+ It is likely that the ability will be added in a future
+ release of <prgn>dpkg</prgn> to specify a version number for
+ each virtual package it provides. This feature is not yet
+ present, however, and is expected to be used only
+ infrequently.
+ </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 one.
+ </p>
+ </sect>
+
+
+ <sect id="replaces"><heading>Overwriting files and replacing
+ packages - <tt>Replaces</tt></heading>
+
+ <p>
+ Packages can declare in their control file that they should
+ overwrite files in certain other packages, or completely
+ replace other packages. The <tt>Replaces</tt> control file
+ field has these two distinct purposes.
+ </p>
+
+ <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.
+ </p>
+
+ <p>
+ 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
+ be marked as not wanted on the system (selected for
+ 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">.
+ <footnote>
+ <p>
+ Replaces is a one way relationship -- you have to
+ install the replacing package after the replaced
+ package.
+ </p>
+ </footnote>
+ </p>
+
+ <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>
+
+ <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 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>
+
+ <sect id="sourcebinarydeps">
+ <heading>Relationships between source and binary packages -
+ <tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
+ <tt>Build-Conflicts</tt>, <tt>Build-Conflicts-Indep</tt>
+ </heading>
+
+ <p>
+ Source packages that require certain binary packages to be
+ installed or absent at the time of building the package
+ can declare relationships to those binary packages.
+ </p>
+
+ <p>
+ This is done using the <tt>Build-Depends</tt>,
+ <tt>Build-Depends-Indep</tt>, <tt>Build-Conflicts</tt> and
+ <tt>Build-Conflicts-Indep</tt> control file fields.
+ </p>
+
+ <p>
+ Build-dependencies on "build-essential" binary packages can be
+ omitted. Please see <ref id="pkg-relations"> for more information.
+ </p>
+
+ <p>
+ 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:<footnote>
+ <p>
+ If you make "build-arch" or "binary-arch", you need
+ Build-Depends. If you make "build-indep" or
+ "binary-indep", you need Build-Depends and
+ Build-Depends-Indep. If you make "build" or "binary",
+ you need both.
+ </p>
+ <p>
+ There is no Build-Depends-Arch; this role is essentially
+ met with Build-Depends. Anyone building the
+ <tt>build-indep</tt> and binary-indep<tt></tt> targets
+ is basically assumed to be building the whole package
+ anyway and so installs all build dependencies. The
+ autobuilders use <tt>dpkg-buildpackage -B</tt>, which
+ calls <tt>build</tt> (not <tt>build-arch</tt>, since it
+ does not yet know how to check for its existence) and
+ <tt>binary-arch</tt>.
+ </p>
+ <p>
+ The purpose of the original split, I recall, was so that
+ the autobuilders wouldn't need to install extra packages
+ needed only for the binary-indep targets. But without a
+ build-arch/build-indep split, this didn't work, since
+ most of the work is done in the build target, not in the
+ binary target.
+ </p>
+ </footnote>
+
+ <taglist>
+ <tag><tt>Build-Depends</tt>, <tt>Build-Conflicts</tt></tag>
+ <item>
+ The <tt>Build-Depends</tt> and
+ <tt>Build-Conflicts</tt> fields must be satisfied when
+ any of the following targets is invoked:
+ <tt>build</tt>, <tt>clean</tt>, <tt>binary</tt>,
+ <tt>binary-arch</tt>, <tt>build-arch</tt>,
+ <tt>build-indep</tt> and <tt>binary-indep</tt>.
+ </item>
+ <tag><tt>Build-Depends-Indep</tt>,
+ <tt>Build-Conflicts-Indep</tt></tag>
+ <item>
+ The <tt>Build-Depends-Indep</tt> and
+ <tt>Build-Conflicts-Indep</tt> fields must be
+ satisfied when any of the following targets is
+ invoked: <tt>build</tt>, <tt>build-indep</tt>,
+ <tt>binary</tt> and <tt>binary-indep</tt>.
+ </item>
+ </taglist>
+ </p>
+
+ </sect>
+
+ </chapt>
+
+
+ <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 C library
+ (currently <tt>libc6</tt>).
+ </p>
+
+ <p>
+ Packages involving shared libraries should be split up into
+ several binary packages. This section mostly deals with how
+ this separation is to be accomplished; rules for files within
+ the shared library packages are in <ref id="libraries"> instead.
+ </p>
+
+ <sect id="sharedlibs-runtime">
+ <heading>Run-time shared libraries</heading>
+
+ <p>
+ The run-time shared library needs to be placed in a package
+ whose name changes whenever the shared object version
+ changes.<footnote>
+ <p>
+ Since it is common place to install several versions of a
+ package that just provides shared libraries, it is a
+ good idea that the library package should not
+ contain any extraneous non-versioned files, unless they
+ happen to be in versioned directories.</p>
+ </footnote>
+ The most common mechanism is to place it in a package
+ called
+ <package><var>libraryname</var><var>soversion</var></package>,
+ where <file><var>soversion</var></file> is the version number
+ in the soname of the shared library<footnote>
+ The soname is the shared object name: 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. For example, if the soname of the library is
+ <file>libfoo.so.6</file>, the library package would be
+ called <file>libfoo6</file>.
+ </footnote>.
+ Alternatively, if it would be confusing to directly append
+ <var>soversion</var> to <var>libraryname</var> (e.g. because
+ <var>libraryname</var> itself ends in a number), you may use
+ <package><var>libraryname</var>-<var>soversion</var></package> and
+ <package><var>libraryname</var>-<var>soversion</var>-dev</package>
+ instead.
+ </p>
+
+ <p>
+ If your package includes run-time support programs that
+ do not need to be invoked manually by users, but are
+ nevertheless required for the package to function, then it
+ is recommended that these programs are placed
+ (if they are binary) in a subdirectory of
+ <file>/usr/lib</file>, preferably under
+ <file>/usr/lib/</file><var>package-name</var>.
+ If the program is architecture independent, the
+ recommendation is for it to be placed in a subdirectory of
+ <file>/usr/share</file> instead, preferably under
+ <file>/usr/share/</file><var>package-name</var>.
+ </p>
+
+
+ <p>
+ If you have several shared libraries built from the same
+ source tree you may lump them all together into a single
+ shared library package, provided that you change all of
+ their sonames at once (so that you don't get filename
+ clashes if you try to install different versions of the
+ combined shared libraries package).
+ </p>
+
+ <p>
+ The package should install the shared libraries under
+ their normal names. For example, the <package>libgdbm3</package>
+ package should install <file>libgdbm.so.3.0.0</file> as
+ <file>/usr/lib/libgdbm.so.3.0.0</file>. The files should not be
+ 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>
+ Shared libraries should not be installed executable, since
+ the dynamic linker does not require this and trying to
+ execute a shared library usually results in a core dump.
+ </p>
+
+ <p>
+ The run-time library package should include the symbolic link that
+ <prgn>ldconfig</prgn> would create for the shared libraries.
+ For example, the <package>libgdbm3</package> package should include
+ a symbolic link from <file>/usr/lib/libgdbm.so.3</file> to
+ <file>libgdbm.so.3.0.0</file>. 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>
+ The package management system requires the library to be
+ placed before the symbolic link pointing to it in the
+ <file>.deb</file> 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
+ <file>.deb</file> 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.
+ Since version 1.7.0, <prgn>dpkg</prgn>
+ reorders the files itself as necessary when building a
+ package. Thus it is no longer important to concern
+ oneself with the order of file creation.
+ </footnote>
+ </p>
+
+ <sect1 id="ldconfig">
+ <heading><tt>ldconfig</tt></heading>
+
+ <p>
+ Any package installing shared libraries in one of the default
+ library directories of the dynamic linker (which are currently
+ <file>/usr/lib</file> and <file>/lib</file>) or a directory that is
+ listed in <file>/etc/ld.so.conf</file><footnote>
+ These are currently
+ <list compact="compact">
+ <item>/usr/local/lib</item>
+ <item>/usr/lib/libc5-compat</item>
+ <item>/lib/libc5-compat</item>
+ </list>
+ </footnote>
+ must use <prgn>ldconfig</prgn> to update the shared library
+ system.
+ </p>
+
+ <p>
+ The package maintainer scripts must only call
+ <prgn>ldconfig</prgn> under these circumstances:
+ <list compact="compact">
+ <item>When the <prgn>postinst</prgn> script is run with a
+ first argument of <tt>configure</tt>, the script must call
+ <prgn>ldconfig</prgn>, and may optionally invoke
+ <prgn>ldconfig</prgn> at other times.
+ </item>
+ <item>When the <prgn>postrm</prgn> script is run with a
+ first argument of <tt>remove</tt>, the script should call
+ <prgn>ldconfig</prgn>.
+ </item>
+ </list>
+ <footnote>
+ <p>
+ During install or upgrade, the preinst is called before
+ the new files are installed, so calling "ldconfig" is
+ pointless. The preinst of an existing package can also be
+ called if an upgrade fails. However, this happens during
+ the critical time when a shared libs may exist on-disk
+ under a temporary name. Thus, it is dangerous and
+ forbidden by current policy to call "ldconfig" at this
+ time.
+ </p>
+
+ <p>
+ When a package is installed or upgraded, "postinst
+ configure" runs after the new files are safely on-disk.
+ Since it is perfectly safe to invoke ldconfig
+ unconditionally in a postinst, it is OK for a package to
+ simply put ldconfig in its postinst without checking the
+ argument. The postinst can also be called to recover from
+ a failed upgrade. This happens before any new files are
+ unpacked, so there is no reason to call "ldconfig" at this
+ point.
+ </p>
+
+ <p>
+ For a package that is being removed, prerm is
+ called with all the files intact, so calling ldconfig is
+ useless. The other calls to "prerm" happen in the case of
+ upgrade at a time when all the files of the old package
+ are on-disk, so again calling "ldconfig" is pointless.
+ </p>
+
+ <p>
+ postrm, on the other hand, is called with the "remove"
+ argument just after the files are removed, so this is
+ the proper time to call "ldconfig" to notify the system
+ of the fact that the shared libraries from the package
+ are removed. The postrm can be called at several other
+ times. At the time of "postrm purge", "postrm
+ abort-install", or "postrm abort-upgrade", calling
+ "ldconfig" is useless because the shared lib files are
+ not on-disk. However, when "postrm" is invoked with
+ arguments "upgrade", "failed-upgrade", or "disappear", a
+ shared lib may exist on-disk under a temporary filename.
+ </p>
+ </footnote>
+ </p>
+ </sect1>
+
+ </sect>
+
+ <sect id="sharedlibs-runtime-progs">
+ <heading>Run-time support programs</heading>
+
+ <p>
+ If your package has some run-time support programs which use
+ the shared library you must not put them in the shared
+ library package. If you do that then you won't be able to
+ install several versions of the shared library without
+ getting filename clashes.
+ </p>
+
+ <p>
+ Instead, either create another package for the runtime binaries
+ (this package might typically be named
+ <package><var>libraryname</var>-runtime</package>; note the absence
+ of the <var>soversion</var> in the package name), or if the
+ development package is small, include them in there.
+ </p>
+ </sect>
+
+ <sect id="sharedlibs-static">
+ <heading>Static libraries</heading>
+
+ <p>
+ The static library (<file><var>libraryname.a</var></file>)
+ is usually provided in addition to the shared version.
+ It is placed into the development package (see below).
+ </p>
+
+ <p>
+ In some cases, it is acceptable for a library to be
+ available in static form only; these cases include:
+ <list>
+ <item>libraries for languages whose shared library support
+ is immature or unstable</item>
+ <item>libraries whose interfaces are in flux or under
+ development (commonly the case when the library's
+ major version number is zero, or where the ABI breaks
+ across patchlevels)</item>
+ <item>libraries which are explicitly intended to be
+ available only in static form by their upstream
+ author(s)</item>
+ </list>
+ </p>
+
+ <sect id="sharedlibs-dev">
+ <heading>Development files</heading>
+
+ <p>
+ The development files associated to a shared library need to be
+ placed in a package called
+ <package><var>libraryname</var><var>soversion</var>-dev</package>,
+ or if you prefer only to support one development version at a
+ time, <package><var>libraryname</var>-dev</package>.
+ </p>
+
+ <p>
+ In case several development versions of a library exist, you may
+ need to use <prgn>dpkg</prgn>'s Conflicts mechanism (see
+ <ref id="conflicts">) to ensure that the user only installs one
+ development version at a time (as different development versions are
+ likely to have the same header files in them, which would cause a
+ filename clash if both were installed).
+ </p>
+
+ <p>
+ The development package should contain a symlink for the associated
+ shared library without a version number. For example, the
+ <package>libgdbm-dev</package> package should include a symlink
+ from <file>/usr/lib/libgdbm.so</file> to
+ <file>libgdbm.so.3.0.0</file>. This symlink is needed by the linker
+ (<prgn>ld</prgn>) when compiling packages, as it will only look for
+ <file>libgdbm.so</file> when compiling dynamically.
+ </p>
+ </sect>
+
+ <sect id="sharedlibs-intradeps">
+ <heading>Dependencies between the packages of the same library</heading>
+
+ <p>
+ Typically the development version should have an exact
+ version dependency on the runtime library, to make sure that
+ compilation and linking happens correctly. The
+ <tt>${binary:Version}</tt> substitution variable can be
+ useful for this purpose.
+ <footnote>
+ Previously, <tt>${Source-Version}</tt> was used, but its name
+ was confusing and it has been deprecated since dpkg 1.13.19.
+ </footnote>
+ </p>
+ </sect>
+
+ <sect id="sharedlibs-shlibdeps">
+ <heading>Dependencies between the library and other packages -
+ 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 <file>shlibs</file> files.
+ </p>
+
+ <p>
+ Thus, when a package is built which contains any shared
+ libraries, it must provide a <file>shlibs</file> file for other
+ packages to use, and when a package is built which contains
+ any shared libraries or compiled binaries, it must run
+ <qref id="pkg-dpkg-shlibdeps"><prgn>dpkg-shlibdeps</prgn></qref>
+ 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> is used 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>
+ 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 depend on
+ the libraries it directly uses, and the dependencies for
+ those libraries should automatically pull in the other
+ libraries.
+ </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>
+ 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>
+ 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>
+
+ <sect1>
+ <heading>The <tt>shlibs</tt> files present on the system</heading>
+
+ <p>
+ 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
+ <qref id="pkg-dpkg-shlibdeps"><prgn>dpkg-shlibdeps</prgn></qref>.
+ (The first one which gives the required information is used.)
+ </p>
+
+ <p>
+ <list>
+ <item>
+ <p><file>debian/shlibs.local</file></p>
+
+ <p>
+ This lists overrides for this package. Its use is
+ described below (see <ref id="shlibslocal">).
+ </p>
+ </item>
+
+ <item>
+ <p><file>/etc/dpkg/shlibs.override</file></p>
+
+ <p>
+ This lists global overrides. This list is normally
+ empty. It is maintained by the local system
+ administrator.
+ </p>
+ </item>
+
+ <item>
+ <p><file>DEBIAN/shlibs</file> files in the "build directory"</p>
+
+ <p>
+ When packages are being built, any
+ <file>debian/shlibs</file> files are copied into the
+ control file area of the temporary build directory and
+ given the name <file>shlibs</file>. These files give
+ details of any shared libraries included in the
+ package.<footnote>
+ 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 <file>debian/libfoo2</file> and
+ <file>debian/foo-runtime</file> respectively.
+ (<file>debian/tmp</file> 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
+ <file>debian/libfoo2/DEBIAN/shlibs</file>, eventually
+ to become
+ <file>/var/lib/dpkg/info/libfoo2.shlibs</file>. Then
+ when <prgn>dpkg-shlibdeps</prgn> is run on the
+ executable
+ <file>debian/foo-runtime/usr/bin/foo-prog</file>, it
+ will examine the
+ <file>debian/libfoo2/DEBIAN/shlibs</file> 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.
+ </footnote>
+ </p>
+ </item>
+
+ <item>
+ <p><file>/var/lib/dpkg/info/*.shlibs</file></p>
+
+ <p>
+ These are the <file>shlibs</file> files corresponding to
+ all of the packages installed on the system, and are
+ maintained by the relevant package maintainers.
+ </p>
+ </item>
+
+ <item>
+ <p><file>/etc/dpkg/shlibs.default</file></p>
+
+ <p>
+ This file lists any shared libraries whose packages
+ have failed to provide correct <file>shlibs</file> files.
+ It was used when the <file>shlibs</file> setup was first
+ introduced, but it is now normally empty. It is
+ maintained by the <tt>dpkg</tt> maintainer.
+ </p>
+ </item>
+ </list>
+ </p>
+ </sect1>
+
+ <sect1>
+ <heading>How to use <prgn>dpkg-shlibdeps</prgn> and the
+ <file>shlibs</file> files</heading>
+
+ <p>
+ Put a call to
+ <qref id="pkg-dpkg-shlibdeps"><prgn>dpkg-shlibdeps</prgn></qref>
+ into your <file>debian/rules</file> 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>
+ 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.
+ </footnote>
+ </p>
+
+ <p>
+ This command puts the dependency information into the
+ <file>debian/substvars</file> file, which is then used by
+ <prgn>dpkg-gencontrol</prgn>. You will need to place a
+ <tt>${shlibs:Depends}</tt> variable in the <tt>Depends</tt>
+ field in the control file for this to work.
+ </p>
+
+ <p>
+ If <prgn>dpkg-shlibdeps</prgn> doesn't complain, you're
+ done. If it does complain you might need to create your own
+ <file>debian/shlibs.local</file> file, as explained below (see
+ <ref id="shlibslocal">).
+ </p>
+
+ <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 <file>substvars</file> file.
+ </p>
+
+ <p>
+ If you are creating a udeb for use in the Debian Installer, you
+ will need to specify that <prgn>dpkg-shlibdeps</prgn> should use
+ the dependency line of type <tt>udeb</tt> by adding
+ <tt>-tudeb</tt> as option<footnote>
+ <prgn>dh_shlibdeps</prgn> from the <tt>debhelper</tt> suite
+ will automatically add this option if it knows it is
+ processing a udeb.
+ </footnote>. If there is no dependency line of type <tt>udeb</tt>
+ in the <file>shlibs</file> file, <prgn>dpkg-shlibdeps</prgn> will
+ fall back to the regular dependency line.
+ </p>
+
+ <p>
+ For more details on dpkg-shlibdeps, please see
+ <ref id="pkg-dpkg-shlibdeps"> and
+ <manref name="dpkg-shlibdeps" section="1">.
+ </p>
+ </sect1>
+
+ <sect1 id="shlibs">
+ <heading>The <file>shlibs</file> File Format</heading>
+
+ <p>
+ Each <file>shlibs</file> file has the same format. Lines
+ beginning with <tt>#</tt> are considered to be comments and
+ are ignored. Each line is of the form:
+ <example compact="compact">
+[<var>type</var>: ]<var>library-name</var> <var>soname-version</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 <file>/usr/lib/libz.so.1.1.3</file>.
+ </p>
+
+ <p>
+ <var>type</var> is an optional element that indicates the type
+ of package for which the line is valid. The only type currently
+ in use is <tt>udeb</tt>. The colon and space after the type are
+ required.
+ </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</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>
+ This can be determined using the command
+ <example compact="compact">
+objdump -p /usr/lib/libz.so.1.1.3 | grep SONAME
+ </example>
+ </footnote>
+ The version part is the part which comes after
+ <tt>.so.</tt>, so in our case, it is <tt>1</tt>.
+ </p>
+
+ <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>
+
+ <p>
+ As zlib1g also provides a udeb containing the shared library,
+ there would also be a second line:
+ <example compact="compact">
+udeb: libz 1 zlib1g-udeb (>= 1:1.1.3)
+ </example>
+ </p>
+ </sect1>
+
+ <sect1>
+ <heading>Providing a <file>shlibs</file> file</heading>
+
+ <p>
+ If your package provides a shared library, you need to create
+ a <file>shlibs</file> file following the format described above.
+ It is usual to call this file <file>debian/shlibs</file> (but if
+ you have multiple binary packages, you might want to call it
+ <file>debian/shlibs.<var>package</var></file> instead). Then
+ let <file>debian/rules</file> 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
+ <file>shlibs</file> file in the control area directly from
+ <file>debian/rules</file> without using a <file>debian/shlibs</file>
+ file at all,<footnote>
+ This is what <prgn>dh_makeshlibs</prgn> in the
+ <tt>debhelper</tt> suite does. If your package also has a udeb
+ that provides a shared library, <prgn>dh_makeshlibs</prgn> can
+ automatically generate the <tt>udeb:</tt> lines if you specify
+ the name of the udeb with the <tt>--add-udeb</tt> option.
+ </footnote>
+ since the <file>debian/shlibs</file> file itself is ignored by
+ <prgn>dpkg-shlibdeps</prgn>.
+ </p>
+
+ <p>
+ As <prgn>dpkg-shlibdeps</prgn> reads the
+ <file>DEBIAN/shlibs</file> files in all of the binary packages
+ being built from this source package, all of the
+ <file>DEBIAN/shlibs</file> files should be installed before
+ <prgn>dpkg-shlibdeps</prgn> is called on any of the binary
+ packages.
+ </p>
+ </sect1>
+
+ <sect1 id="shlibslocal">
+ <heading>Writing the <file>debian/shlibs.local</file> file</heading>
+
+ <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 <file>shlibs</file> file.
+ </p>
+
+ <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 <file>*.shlibs</file> file handling
+ <file>libbar.so.1</file> in <file>/var/lib/dpkg/info/</file>. 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
+ <file>debian/shlibs.local</file> to locally fix the problem.
+ Including the following line into your
+ <file>debian/shlibs.local</file> 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 <file>shlibs</file> file, you should remove this line
+ from your <file>debian/shlibs.local</file> 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>
+ </sect1>
+
+ </sect>
+
+ </chapt>
+
+
+ <chapt id="opersys"><heading>The Operating System</heading>
+
+ <sect>
+ <heading>File system hierarchy</heading>
+
+
+ <sect1 id="fhs">
+ <heading>File system Structure</heading>
+
+ <p>
+ The location of all installed files and directories must
+ comply with the File system Hierarchy Standard (FHS),
+ version 2.3, with the exceptions noted below, and except
+ where doing so would violate other terms of Debian
+ Policy. The following exceptions to the FHS apply:
+
+ <enumlist>
+ <item>
+ <p>
+ Legacy XFree86 servers are permitted to retain the
+ configuration file location
+ <file>/etc/X11/XF86Config-4</file>.
+ </p>
+ </item>
+ <item>
+ <p>
+ The optional rules related to user specific
+ configuration files for applications are stored in
+ the user's home directory are relaxed. It is
+ recommended that such files start with the
+ '<tt>.</tt>' character (a "dot file"), and if an
+ application needs to create more than one dot file
+ then the preferred placement is in a subdirectory
+ with a name starting with a '.' character, (a "dot
+ directory"). In this case it is recommended the
+ configuration files not start with the '.'
+ character.
+ </p>
+ </item>
+ <item>
+ <p>
+ The requirement for amd64 to use <file>/lib64</file>
+ for 64 bit binaries is removed.
+ </p>
+ </item>
+ <item>
+ <p>
+ The requirement that
+ <file>/usr/local/share/man</file> be "synonymous"
+ with <file>/usr/local/man</file> is relaxed to a
+ recommendation</p>
+ </item>
+ <item>
+ <p>
+ The requirement that windowmanagers with a single
+ configuration file call it <file>system.*wmrc</file>
+ is removed, as is the restriction that the window
+ manager subdirectory be named identically to the
+ window manager name itself.
+ </p>
+ </item>
+ <item>
+ <p>
+ The requirement that boot manager configuration
+ files live in <file>/etc</file>, or at least are
+ symlinked there, is relaxed to a recommendation.
+ </p>
+ </item>
+ </enumlist>
+
+ </p>
+ <p>
+ The version of this document referred here can be
+ found in the <tt>debian-policy</tt> package or on <url
+ id="http://www.debian.org/doc/packaging-manuals/fhs/"
+ name="FHS (Debian copy)"> alongside this manual (or, if
+ you have the <package>debian-policy</package> installed,
+ you can try <url
+ id="file:///usr/share/doc/debian-policy/fhs/" name="FHS
+ (local copy)">). The
+ latest version, which may be a more recent version, may
+ be found on
+ <url id="http://www.pathname.com/fhs/" name="FHS (upstream)">.
+ Specific questions about following the standard may be
+ asked on the <tt>debian-devel</tt> mailing list, or
+ referred to the FHS mailing list (see the
+ <url id="http://www.pathname.com/fhs/" name="FHS web site"> for
+ more information).
+ </p>
+ </sect1>
+
+ <sect1>
+ <heading>Site-specific programs</heading>
+
+ <p>
+ As mandated by the FHS, packages must not place any
+ files in <file>/usr/local</file>, either by putting them in
+ the file system archive to be unpacked by <prgn>dpkg</prgn>
+ or by manipulating them in their maintainer scripts.
+ </p>
+
+ <p>
+ However, the package may create empty directories below
+ <file>/usr/local</file> so that the system administrator knows
+ where to place site-specific files. These are not
+ directories <em>in</em> <file>/usr/local</file>, but are
+ children of directories in <file>/usr/local</file>. These
+ directories (<file>/usr/local/*/dir/</file>)
+ should be removed on package removal if they are
+ empty.
+ </p>
+
+ <p>
+ Note, that this applies only to directories <em>below</em>
+ <file>/usr/local</file>, not <em>in</em> <file>/usr/local</file>.
+ Packages must not create sub-directories in the directory
+ <file>/usr/local</file> itself, except those listed in FHS,
+ section 4.5. However, you may create directories below
+ them as you wish. You must not remove any of the
+ directories listed in 4.5, even if you created them.
+ </p>
+
+ <p>
+ Since <file>/usr/local</file> can be mounted read-only from a
+ remote server, these directories must be created and
+ removed by the <prgn>postinst</prgn> and <prgn>prerm</prgn>
+ maintainer scripts and not be included in the
+ <file>.deb</file> archive. These scripts must not fail if
+ either of these operations fail.
+ </p>
+
+ <p>
+ For example, the <tt>emacsen-common</tt> package could
+ contain something like
+ <example compact="compact">
+if [ ! -e /usr/local/share/emacs ]
+then
+ if mkdir /usr/local/share/emacs 2>/dev/null
+ then
+ chown root:staff /usr/local/share/emacs
+ chmod 2775 /usr/local/share/emacs
+ fi
+fi
+ </example>
+ in its <prgn>postinst</prgn> script, and
+ <example compact="compact">
+rmdir /usr/local/share/emacs/site-lisp 2>/dev/null || true
+rmdir /usr/local/share/emacs 2>/dev/null || true
+ </example>
+ in the <prgn>prerm</prgn> script. (Note that this form is
+ used to ensure that if the script is interrupted, the
+ directory <file>/usr/local/share/emacs</file> will still be
+ removed.)
+ </p>
+
+ <p>
+ If you do create a directory in <file>/usr/local</file> for
+ local additions to a package, you should ensure that
+ settings in <file>/usr/local</file> take precedence over the
+ equivalents in <file>/usr</file>.
+ </p>
+
+ <p>
+ However, because <file>/usr/local</file> and its contents are
+ for exclusive use of the local administrator, a package
+ must not rely on the presence or absence of files or
+ directories in <file>/usr/local</file> for normal operation.
+ </p>
+
+ <p>
+ The <file>/usr/local</file> directory itself and all the
+ subdirectories created by the package should (by default) have
+ permissions 2775 (group-writable and set-group-id) and be
+ owned by <tt>root.staff</tt>.
+ </p>
+ </sect1>
+
+ <sect1>
+ <heading>The system-wide mail directory</heading>
+ <p>
+ The system-wide mail directory is <file>/var/mail</file>. This
+ directory is part of the base system and should not owned
+ by any particular mail agents. The use of the old
+ location <file>/var/spool/mail</file> is deprecated, even
+ though the spool may still be physically located there.
+ To maintain partial upgrade compatibility for systems
+ which have <file>/var/spool/mail</file> as their physical mail
+ spool, packages using <file>/var/mail</file> must depend on
+ either <package>libc6</package> (>= 2.1.3-13), or on
+ <package>base-files</package> (>= 2.2.0), or on later
+ versions of either one of these packages.
+ </p>
+ </sect1>
+ </sect>
+
+ <sect>
+ <heading>Users and groups</heading>
+
+ <sect1>
+ <heading>Introduction</heading>
+ <p>
+ The Debian system can be configured to use either plain or
+ shadow passwords.
+ </p>
+
+ <p>
+ Some user ids (UIDs) and group ids (GIDs) are reserved
+ globally for use by certain packages. Because some
+ packages need to include files which are owned by these
+ users or groups, or need the ids compiled into binaries,
+ these ids must be used on any Debian system only for the
+ purpose for which they are allocated. This is a serious
+ restriction, and we should avoid getting in the way of
+ local administration policies. In particular, many sites
+ allocate users and/or local system groups starting at 100.
+ </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>
+
+ <p>
+ Packages other than <tt>base-passwd</tt> must not modify
+ <file>/etc/passwd</file>, <file>/etc/shadow</file>,
+ <file>/etc/group</file> or <file>/etc/gshadow</file>.
+ </p>
+ </sect1>
+
+ <sect1>
+ <heading>UID and GID classes</heading>
+ <p>
+ The UID and GID numbers are divided into classes as
+ follows:
+ <taglist>
+ <tag>0-99:</tag>
+ <item>
+ <p>
+ Globally allocated by the Debian project, the same
+ on every Debian system. These ids will appear in
+ the <file>passwd</file> and <file>group</file> files of all
+ Debian systems, new ids in this range being added
+ automatically as the <tt>base-passwd</tt> package is
+ updated.
+ </p>
+
+ <p>
+ Packages which need a single statically allocated
+ uid or gid should use one of these; their
+ maintainers should ask the <tt>base-passwd</tt>
+ maintainer for ids.
+ </p>
+ </item>
+
+ <tag>100-999:</tag>
+ <item>
+ <p>
+ Dynamically allocated system users and groups.
+ Packages which need a user or group, but can have
+ this user or group allocated dynamically and
+ differently on each system, should use <tt>adduser
+ --system</tt> to create the group and/or user.
+ <prgn>adduser</prgn> will check for the existence of
+ the user or group, and if necessary choose an unused
+ id based on the ranges specified in
+ <file>adduser.conf</file>.
+ </p>
+ </item>
+
+ <tag>1000-29999:</tag>
+ <item>
+ <p>
+ Dynamically allocated user accounts. By default
+ <prgn>adduser</prgn> will choose UIDs and GIDs for
+ user accounts in this range, though
+ <file>adduser.conf</file> may be used to modify this
+ behavior.
+ </p>
+ </item>
+
+ <tag>30000-59999:</tag>
+ <item>
+ <p>Reserved.</p>
+ </item>
+
+ <tag>60000-64999:</tag>
+ <item>
+ <p>
+ Globally allocated by the Debian project, but only
+ created on demand. The ids are allocated centrally
+ and statically, but the actual accounts are only
+ created on users' systems on demand.
+ </p>
+
+ <p>
+ These ids are for packages which are obscure or
+ which require many statically-allocated ids. These
+ packages should check for and create the accounts in
+ <file>/etc/passwd</file> or <file>/etc/group</file> (using
+ <prgn>adduser</prgn> if it has this facility) if
+ necessary. Packages which are likely to require
+ further allocations should have a "hole" left after
+ them in the allocation, to give them room to
+ grow.
+ </p>
+ </item>
+
+ <tag>65000-65533:</tag>
+ <item>
+ <p>Reserved.</p>
+ </item>
+
+ <tag>65534:</tag>
+ <item>
+ <p>
+ User <tt>nobody</tt>. The corresponding gid refers
+ to the group <tt>nogroup</tt>.
+ </p>
+ </item>
+
+ <tag>65535:</tag>
+ <item>
+ <p>
+ <tt>(uid_t)(-1) == (gid_t)(-1)</tt> <em>must
+ not</em> be used, because it is the error return
+ sentinel value.
+ </p>
+ </item>
+ </taglist>
+ </p>
+ </sect1>
+ </sect>
+
+ <sect id="sysvinit">
+ <heading>System run levels and <file>init.d</file> scripts</heading>
+
+ <sect1 id="/etc/init.d">
+ <heading>Introduction</heading>
+
+ <p>
+ The <file>/etc/init.d</file> directory contains the scripts
+ executed by <prgn>init</prgn> at boot time and when the
+ init state (or "runlevel") is changed (see <manref
+ name="init" section="8">).
+ </p>
+
+ <p>
+ There are at least two different, yet functionally
+ equivalent, ways of handling these scripts. For the sake
+ of simplicity, this document describes only the symbolic
+ link method. However, it must not be assumed by maintainer
+ scripts that this method is being used, and any automated
+ manipulation of the various runlevel behaviors by
+ maintainer scripts must be performed using
+ <prgn>update-rc.d</prgn> as described below and not by
+ manually installing or removing symlinks. For information
+ on the implementation details of the other method,
+ implemented in the <tt>file-rc</tt> package, please refer
+ to the documentation of that package.
+ </p>
+
+ <p>
+ These scripts are referenced by symbolic links in the
+ <file>/etc/rc<var>n</var>.d</file> directories. When changing
+ runlevels, <prgn>init</prgn> looks in the directory
+ <file>/etc/rc<var>n</var>.d</file> for the scripts it should
+ execute, where <tt><var>n</var></tt> is the runlevel that
+ is being changed to, or <tt>S</tt> for the boot-up
+ scripts.
+ </p>
+
+ <p>
+ The names of the links all have the form
+ <file>S<var>mm</var><var>script</var></file> or
+ <file>K<var>mm</var><var>script</var></file> where
+ <var>mm</var> is a two-digit number and <var>script</var>
+ is the name of the script (this should be the same as the
+ name of the actual script in <file>/etc/init.d</file>).
+ </p>
+
+ <p>
+ When <prgn>init</prgn> changes runlevel first the targets
+ of the links whose names start with a <tt>K</tt> are
+ executed, each with the single argument <tt>stop</tt>,
+ followed by the scripts prefixed with an <tt>S</tt>, each
+ with the single argument <tt>start</tt>. (The links are
+ those in the <file>/etc/rc<var>n</var>.d</file> directory
+ corresponding to the new runlevel.) The <tt>K</tt> links
+ are responsible for killing services and the <tt>S</tt>
+ link for starting services upon entering the runlevel.
+ </p>
+
+ <p>
+ For example, if we are changing from runlevel 2 to
+ runlevel 3, init will first execute all of the <tt>K</tt>
+ prefixed scripts it finds in <file>/etc/rc3.d</file>, and then
+ all of the <tt>S</tt> prefixed scripts in that directory.
+ The links starting with <tt>K</tt> will cause the
+ referred-to file to be executed with an argument of
+ <tt>stop</tt>, and the <tt>S</tt> links with an argument
+ of <tt>start</tt>.
+ </p>
+
+ <p>
+ The two-digit number <var>mm</var> is used to determine
+ the order in which to run the scripts: 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 another. For example, the name
+ server <prgn>bind</prgn> might need to be started before
+ the news server <prgn>inn</prgn> so that <prgn>inn</prgn>
+ can set up its 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 compact="compact">
+/etc/rc2.d/S17bind
+/etc/rc2.d/S70inn
+ </example>
+ </p>
+
+ <p>
+ The two runlevels 0 (halt) and 6 (reboot) are slightly
+ different. In these runlevels, the links with an
+ <tt>S</tt> prefix are still called after those with a
+ <tt>K</tt> prefix, but they too are called with the single
+ argument <tt>stop</tt>.
+ </p>
+
+ <p>
+ Also, if the script name ends in <tt>.sh</tt>, the script
+ will be sourced in runlevel <tt>S</tt> rather than being
+ run in a forked subprocess, but will be explicitly run by
+ <prgn>sh</prgn> in all other runlevels.
+ </p>
+ </sect1>
+
+ <sect1>
+ <heading>Writing the scripts</heading>
+
+ <p>
+ Packages that include daemons for system services should
+ place scripts in <file>/etc/init.d</file> to start or stop
+ services at boot time or during a change of runlevel.
+ These scripts should be named
+ <file>/etc/init.d/<var>package</var></file>, and they should
+ accept one argument, saying what to do:
+
+ <taglist>
+ <tag><tt>start</tt></tag>
+ <item>start the service,</item>
+
+ <tag><tt>stop</tt></tag>
+ <item>stop the service,</item>
+
+ <tag><tt>restart</tt></tag>
+ <item>stop and restart the service if it's already running,
+ otherwise start the service</item>
+
+ <tag><tt>reload</tt></tag>
+ <item><p>cause the configuration of the service to be
+ reloaded without actually stopping and restarting
+ the service,</item>
+
+ <tag><tt>force-reload</tt></tag>
+ <item>cause the configuration to be reloaded if the
+ service supports this, otherwise restart the
+ service.</item>
+ </taglist>
+
+ The <tt>start</tt>, <tt>stop</tt>, <tt>restart</tt>, and
+ <tt>force-reload</tt> options should be supported by all
+ scripts in <file>/etc/init.d</file>, the <tt>reload</tt>
+ option is optional.
+ </p>