In addition, the packages in <em>main</em>
<list compact="compact">
<item>
- must not require a package outside of <em>main</em>
- for compilation or execution (thus, the package must
- not declare a "Depends", "Recommends", or
+ 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),
</item>
lines. The first line of the value, the part on the same line as
the field name, often has special significance or may have to be
empty. Other lines are added following the same syntax as the
- continuation lines the folded fields. Whitespace, including newlines,
+ continuation lines of the folded fields. Whitespace, including newlines,
is significant in the values of multiline fields.
</item>
</taglist>
Those starting with a single space are part of a paragraph.
Successive lines of this form will be word-wrapped when
displayed. The leading space will usually be stripped off.
+ The line must contain at least one non-whitespace character.
</item>
<item>
will be allowed to trail off to the right. None, one or two
initial spaces may be deleted, but the number of spaces
deleted from each line will be the same (so that you can have
- indenting work correctly, for example).
+ indenting work correctly, for example). The line must
+ contain at least one non-whitespace character.
</item>
<item>
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
+ 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
prepended with exclamation marks while others aren't.)
<p>
Relationships may also be restricted to a certain set of
- architectures using architecture wildcards. The syntax for
+ architectures using architecture wildcards in the format
+ described in <ref id="arch-wildcard-spec">. The syntax for
declaring such restrictions is the same as declaring
restrictions using a certain set of architectures without
architecture wildcards. For example:
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
+if [ ! -e /usr/local/share/emacs ]; then
+ if mkdir /usr/local/share/emacs 2>/dev/null; then
+ if chown root:staff /usr/local/share/emacs; then
+ chmod 2775 /usr/local/share/emacs || true
+ fi
fi
fi
</example>
package that provides online documentation (other than just
manual pages) to register these documents with
<package>doc-base</package> by installing a
- <package>doc-base</package> control file via the
- <prgn/install-docs/ script at installation time and
- de-register the manuals again when the package is removed.
+ <package>doc-base</package> control file in
+ <file>/usr/share/doc-base/</file>.
</p>
<p>
Please refer to the documentation that comes with the
<heading>Symbolic links</heading>
<p>
- In general, symbolic links within a top-level directory
- should be relative, and symbolic links pointing from one
- top-level directory into another should be absolute. (A
- top-level directory is a sub-directory of the root
- directory <file>/</file>.)
+ In general, symbolic links within a top-level directory should
+ be relative, and symbolic links pointing from one top-level
+ directory to or into another should be absolute. (A top-level
+ directory is a sub-directory of the root
+ directory <file>/</file>.) For example, a symbolic link
+ from <file>/usr/lib/foo</file> to <file>/usr/share/bar</file>
+ should be relative (<file>../share/bar</file>), but a symbolic
+ link from <file>/var/run</file> to <file>/run</file> should be
+ absolute.<footnote>
+ This is necessary to allow top-level directories to be
+ symlinks. If linking <file>/var/run</file>
+ to <file>/run</file> were done with the relative symbolic
+ link <file>../run</file>, but <file>/var</file> were a
+ symbolic link to <file>/srv/disk1</file>, the symbolic link
+ would point to <file>/srv/run</file> rather than the intended
+ target.
+ </footnote>
</p>
<p>
<file>/usr/share/doc/<var>package</var></file> may be a symbolic
link to another directory in <file>/usr/share/doc</file> only if
the two packages both come from the same source and the
- first package Depends on the second. These rules are
- important because copyrights must be extractable by
+ first package Depends on the second. These rules are important
+ because <file>copyright</file> files must be extractable by
mechanical means.
</p>
projects / debian / debian-policy.git / blobdiff