/closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
</example>
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.
+ archive maintenance script (<prgn>katie</prgn>) using the
+ <var>version</var> of the changelog entry.
</footnote>
This information is conveyed via the <tt>Closes</tt> field
in the <tt>.changes</tt> file (see <ref id="f-Closes">).
number apart at the last hyphen in the string (if there
is one) to determine the <var>upstream_version</var> and
<var>debian_revision</var>. The absence of a
- <var>debian_revision</var> compares earlier than the
- presence of one (but note that the
- <var>debian_revision</var> is the least significant part
- of the version number).
+ <var>debian_revision</var> is equivalent to a
+ <var>debian_revision</var> of <tt>0</tt>.
</p>
</item>
</taglist>
</p>
<p>
- The <var>upstream_version</var> and <var>debian_revision</var>
+ When comparing two version numbers, first the <var>epoch</var>
+ of each are compared, then the <var>upstream_version</var> if
+ <var>epoch</var> is equal, and then <var>debian_revision</var>
+ if <var>upstream_version</var> is also equal.
+ <var>epoch</var> is compared numerically. The
+ <var>upstream_version</var> and <var>debian_revision</var>
parts are compared by the package management system using the
- same algorithm:
+ following algorithm:
</p>
<p>
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
</sect>
- <sect id="sharedlibs-runtime-progs">
- <heading>Run-time support programs</heading>
+ <sect id="sharedlibs-support-files">
+ <heading>Shared library support files</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>
+ If your package contains files whose names do not change with
+ each change in the library shared object version, you must not
+ put them in the shared library package. Otherwise, several
+ versions of the shared library cannot be installed at the same
+ time without filename clashes, making upgrades and transitions
+ unnecessarily difficult.
+ </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>
+ <p>
+ It is recommended that supporting files and run-time support
+ programs that do not need to be invoked manually by users, but
+ are nevertheless required for the package to function, be 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 or file 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>. Following the
+ <var>package-name</var> naming convention ensures that the file
+ names change when the shared object version changes.
+ </p>
+
+ <p>
+ Run-time support programs that use the shared library but are
+ not required for the library to function or files used by the
+ shared library that can be used by any version of the shared
+ library package should instead be put in a separate package.
+ This package might typically be named
+ <package><var>libraryname</var>-tools</package>; note the
+ absence of the <var>soversion</var> in the package name.
+ </p>
+
+ <p>
+ Files and support programs only useful when compiling software
+ against the library should be included in the development
+ package for the library.<footnote>
+ For example, a <file><var>package-name</var>-config</file>
+ script or <package>pkg-config</package> configuration files.
+ </footnote>
+ </p>
</sect>
<sect id="sharedlibs-static">
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>.
+ owned by <tt>root:staff</tt>.
</p>
</sect1>
<p>
The <file>init.d</file> scripts must ensure that they will
- behave sensibly if invoked with <tt>start</tt> when the
- service is already running, or with <tt>stop</tt> when it
- isn't, and that they don't kill unfortunately-named user
- processes. The best way to achieve this is usually to use
- <prgn>start-stop-daemon</prgn>.
+ behave sensibly (i.e., returning success and not starting
+ multiple copies of a service) if invoked with <tt>start</tt>
+ when the service is already running, or with <tt>stop</tt>
+ when it isn't, and that they don't kill unfortunately-named
+ user processes. The best way to achieve this is usually to
+ use <prgn>start-stop-daemon</prgn> with the <tt>--oknodo</tt>
+ option.
</p>
<p>
</p>
<p>
- Files should be owned by <tt>root.root</tt>, and made
+ Files should be owned by <tt>root:root</tt>, and made
writable only by the owner and universally readable (and
executable, if appropriate), that is mode 644 or 755.
</p>
<p>
Mailboxes are generally mode 660
- <tt><var>user</var>.mail</tt> unless the system
+ <tt><var>user</var>:mail</tt> unless the system
administrator has chosen otherwise. A MUA may remove a
mailbox (unless it has nonstandard permissions) in which
case the MTA or another MUA must recreate it if needed.
</p>
<p>
- The mail spool is 2775 <tt>root.mail</tt>, and MUAs should
+ The mail spool is 2775 <tt>root:mail</tt>, and MUAs should
be setgid mail to do the locking mentioned above (and
must obviously avoid accessing other users' mailboxes
using this privilege).</p>
in the <em>X Toolkit Intrinsics - C Language
Interface</em> manual is also permitted). They must be
registered as <tt>conffile</tt>s or handled as
- configuration files. Packages must not provide the
- directory <file>/usr/X11R6/lib/X11/app-defaults/</file>.
+ configuration files.
</p>
<p>
are stored in the X server and affect all connecting
clients.
</footnote>
- <em>Important:</em> packages that install files into the
- <file>/etc/X11/Xresources/</file> directory must conflict with
- <tt>xbase (<< 3.3.2.3a-2)</tt>; if this is not done
- it is possible for the installing package to destroy a
- previously-existing <file>/etc/X11/Xresources</file> file
- which had been customized by the system administrator.
</p>
</sect1>
Games which require protected, privileged access to
high-score files, saved games, etc., may be made
set-<em>group</em>-id (mode 2755) and owned by
- <tt>root.games</tt>, and use files and directories with
- appropriate permissions (770 <tt>root.games</tt>, for
+ <tt>root:games</tt>, and use files and directories with
+ appropriate permissions (770 <tt>root:games</tt>, for
example). They must not be made
set-<em>user</em>-id, as this causes security problems. (If
an attacker can subvert any set-user-id game they can
</p>
<p>
- Its arguments are executables.
+ Its arguments are executables and shared libraries
<footnote>
- <p>
- In a forthcoming dpkg version,
- <prgn>dpkg-shlibdeps</prgn> would be required to be
- called on shared libraries as well.
- </p>
<p>
They may be specified either in the locations in the
source tree where they are created or in the locations
and then in its main control file <file>debian/control</file>:
<example>
<var>...</var>
- Depends: ${shlibs:Pre-Depends}
+ Depends: ${shlibs:Depends}
Recommends: ${shlibs:Recommends}
<var>...</var>
</example>
<p>
This program can be used manually, but is also invoked by
<tt>dpkg-buildpackage</tt> or <file>debian/rules</file> to set
- to set environment or make variables which specify the build and
- host architecture for the package building process.
+ environment or make variables which specify the build and host
+ architecture for the package building process.
</p>
</sect1>
</sect>
projects / debian / debian-policy.git / blobdiff