<item>
must not require or recommend a package outside
of <em>main</em> for compilation or execution (thus, the
- package must not declare a "Depends", "Recommends", or
- "Build-Depends" relationship on a non-<em>main</em>
- package),
+ package must not declare a "Pre-Depends", "Depends",
+ "Recommends", "Build-Depends", or "Build-Depends-Indep"
+ relationship on a non-<em>main</em> package),
</item>
<item>
must not be so buggy that we refuse to support them,
Relationships 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
+ The brackets enclose a non-empty list of Debian architecture names
in the format described in <ref id="arch-spec">,
separated by whitespace. Exclamation marks may be prepended to
each of the names. (It is not permitted for some names to be
installed on the system, all of the libraries needed are also
installed. These dependencies must be added to the binary
package when it is built, since they may change based on which
- version of a shared library the binary or library was linnked
+ version of a shared library the binary or library was linked
with. To allow these dependencies to be constructed, shared
libraries must provide either a <file>symbols</file> file or
a <file>shlibs</file> file, which provide information on the
libraries, put a call to <prgn>dpkg-shlibdeps</prgn> into
your <file>debian/rules</file> file in the source package.
List all of the compiled binaries, libraries, or loadable
- modules in your package. If your source package builds only a
- single binary package that contains only compiled binaries and
- libraries (but no scripts) and is not multiarch, 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>
- but normally finding all of the binaries is more
- complex.<footnote>
+ modules in your package.<footnote>
The easiest way to do this is to use a package helper
framework such as <tt>debhelper</tt>. If you are
using <tt>debhelper</tt>, the <prgn>dh_shlibdeps</prgn>
binary package.<footnote>
Again, <prgn>dh_shlibdeps</prgn>
and <prgn>dh_gencontrol</prgn> will handle all of this for
- you if you're using <tt>debhelper</tt>.
+ you if you're using <tt>debhelper</tt>, including generating
+ separate <file>substvars</file> files for each binary
+ package and calling <prgn>dpkg-gencontrol</prgn> with the
+ appropriate flags.
</footnote>
</p>
following <file>symbols</file> file:
<example>
libGL.so.1 libgl1
-| libgl1-mesa-glx #MINVER#
+ | libgl1-mesa-glx #MINVER#
publicGlSymbol@Base 6.3-1
[...]
implementationSpecificSymbol@Base 6.5.2-7 1
<example compact="compact">
* Build-Depends-Package: zlib1g-dev
</example>
- (Don't forget the leading space.)
+ (Don't forget the space before the <tt>*</tt> so that it will
+ be parsed as part of the entry for that library.)
</p>
<p>
directory"</p>
<p>
- When packages are being built,
- any <file>debian/shlibs</file> files are copied into the
- control information 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 same package.
+ These files are generated as part of the package build
+ process and staged for inclusion as control files in the
+ binary packages being built. They provide details of
+ any shared libraries included in the same package.
</p>
</item>
<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/<var>package</var>.shlibs</file> instead).
- Then let <file>debian/rules</file> install it in the control
- information file 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/<var>package</var>.shlibs debian/<var>package</var>/DEBIAN/shlibs
- </example>
- An alternative way of doing this is to create
- the <file>shlibs</file> file in the control information file
- area directly from <file>debian/rules</file> without using
- a <file>debian/shlibs</file> file at all,<footnote>
+ To provide a <file>shlibs</file> file for a shared library
+ binary package, create a <file>shlibs</file> file following
+ the format described above and place it in
+ the <file>DEBIAN</file> directory for that package during the
+ build. It will then be included as a control file for that
+ package<footnote>
This is what <prgn>dh_makeshlibs</prgn> in
the <package>debhelper</package> 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>.
+ </footnote>.
</p>
<p>
symlinked there, is relaxed to a recommendation.
</p>
</item>
+ <item>
+ <p>
+ The additional directory <file>/run</file> in the root
+ file system is allowed. <file>/run</file>
+ replaces <file>/var/run</file>, and the
+ subdirectory <file>/run/lock</file>
+ replaces <file>/var/lock</file>, with
+ the <file>/var</file> directories replaced by symlinks
+ for backwards compatibility. <file>/run</file>
+ and <file>/run/lock</file> must follow all of the
+ requirements in the FHS for <file>/var/run</file>
+ and <file>/var/lock</file>, respectively, such as file
+ naming conventions, file format requirements, or the
+ requirement that files be cleared during the boot
+ process. Files and directories residing
+ in <file>/run</file> should be stored on a temporary
+ file system.
+ </p>
+ </item>
<item>
<p>
The following directories in the root filesystem are
though the spool may still be physically located there.
</p>
</sect1>
+
+ <sect1 id="fhs-run">
+ <heading><file>/run</file> and <file>/run/lock</file></heading>
+
+ <p>
+ The directory <file>/run</file> is cleared at boot, normally
+ by being a mount point for a temporary file system. Packages
+ therefore must not assume that any files or directories
+ under <file>/run</file> other than <file>/run/lock</file>
+ exist unless the package has arranged to create those files or
+ directories since the last reboot. Normally, this is done by
+ the package via an init script. See <ref id="writing-init">
+ for more information.
+ </p>
+
+ <p>
+ Packages must not include files or directories
+ under <file>/run</file>, or under the
+ older <file>/var/run</file> and <file>/var/lock<file> paths.
+ The latter paths will normally be symlinks or other
+ redirections to <file>/run</file> for backwards compatibility.
+ </p>
+ </sect1>
</sect>
<sect>
</p>
<p>
- <file>/var/run</file> and <file>/var/lock</file> may be mounted
- as temporary filesystems<footnote>
- For example, using the <tt>RAMRUN</tt> and <tt>RAMLOCK</tt>
- options in <file>/etc/default/rcS</file>.
- </footnote>, so the <file>init.d</file> scripts must handle this
- correctly. This will typically amount to creating any required
- subdirectories dynamically when the <file>init.d</file> script
- is run, rather than including them in the package and relying on
- <prgn>dpkg</prgn> to create them.
+ Files and directories under <file>/run</file>, including ones
+ referred to via the compatibility paths <file>/var/run</file>
+ and <file>/var/lock</file>, are normally stored on a temporary
+ filesystem and are normally not persistent across a reboot.
+ The <file>init.d</file> scripts must handle this correctly.
+ This will typically mean creating any required subdirectories
+ dynamically when the <file>init.d</file> script is run.
+ See <ref id="fhs-run"> for more information.
</p>
</sect1>
dpkg-divert --package smailwrapper --remove --rename \
--divert /usr/sbin/smail.real /usr/sbin/smail
fi
- </example> where <tt>1.02-2</tt> is the version at which the
+ </example> where <tt>1.0-2</tt> is the version at which the
diversion was first added to the package. The postrm should not
remove the diversion on upgrades both because there's no reason to
remove the diversion only to immediately re-add it and since the
projects / debian / debian-policy.git / blobdiff