separate patches: the patch files are shipped within the Debian patch file
(<filename>.diff.gz</filename>), usually within the
<filename>debian/</filename> directory. The only difference is that they
-aren't applied immediately by dpkg-source, but by the <literal>build</literal>
-rule of <filename>debian/rules</filename>. Conversely, they are reverted in
-the <literal>clean</literal> rule.
+aren't applied immediately by dpkg-source,
+but by the <literal>build</literal>
+rule of <filename>debian/rules</filename>,
+through a dependency on the <literal>patch</literal> rule.
+Conversely, they are reverted in
+the <literal>clean</literal> rule,
+through a dependency on the <literal>unpatch</literal> rule.
</para>
<para>
-<command>dbs</command> is one of the more popular approaches to this. It does
-all of the above, and provides a facility for creating new and updating old
-patches. See the package <systemitem role="package">dbs</systemitem> for more
-information and <systemitem role="package">hello-dbs</systemitem> for an
-example.
+<command>quilt</command> is the recommended tool for this.
+It does all of the above, and also allows to manage patch series.
+See the
+<systemitem role="package">quilt</systemitem> package for more information.
</para>
<para>
-<command>dpatch</command> also provides these facilities, but it's intended to
-be even easier to use. See the package <systemitem
-role="package">dpatch</systemitem> for documentation and examples (in
-<filename>/usr/share/doc/dpatch</filename>).
+There are other tools to manage patches, like <command>dpatch</command>,
+and the patch system integrated with
+<systemitem role="package">cdbs</systemitem>.
</para>
</section>
<section id="bpp-pkg-synopsis">
<title>The package synopsis, or short description</title>
<para>
-The synopsis line (the short description) should be concise. It must not
-repeat the package's name (this is policy).
+Policy says the synopsis line (the short description) must be concise, not
+repeating the package name, but also informative.
</para>
<para>
-It's a good idea to think of the synopsis as an appositive clause, not a full
-sentence. An appositive clause is defined in WordNet as a grammatical relation
-between a word and a noun phrase that follows, e.g., Rudolph the red-nosed
-reindeer. The appositive clause here is red-nosed reindeer. Since the
-synopsis is a clause, rather than a full sentence, we recommend that it neither
-start with a capital nor end with a full stop (period). It should also not
-begin with an article, either definite (the) or indefinite (a or an).
-</para>
-<para>
-It might help to imagine that the synopsis is combined with the package name in
-the following way:
+The synopsis functions as a phrase describing the package, not a complete
+sentence, so sentential punctuation is inappropriate: it does not need extra
+capital letters or a final period (full stop). It should also omit any initial
+indefinite or definite article - "a", "an", or "the". Thus for instance:
</para>
<screen>
-<replaceable>package-name</replaceable> is a <replaceable>synopsis</replaceable>.
+Package: libeg0
+Description: exemplification support library
</screen>
<para>
-Alternatively, it might make sense to think of it as
+Technically this is a noun phrase minus articles, as opposed to a verb phrase.
+A good heuristic is that it should be possible to substitute the package name
+and synopsis into this formula:
</para>
-<screen>
-<replaceable>package-name</replaceable> is <replaceable>synopsis</replaceable>.
-</screen>
<para>
-or, if the package name itself is a plural (such as developers-tools)
+The package <replaceable>name</replaceable> provides {a,an,the,some}
+<replaceable>synopsis</replaceable>.
+</para>
+<para>
+Sets of related packages may use an alternative scheme that divides the
+synopsis into two parts, the first a description of the whole suite and the
+second a summary of the package's role within it:
</para>
<screen>
-<replaceable>package-name</replaceable> are <replaceable>synopsis</replaceable>.
+Package: eg-tools
+Description: simple exemplification system (utilities)
+
+Package: eg-doc
+Description: simple exemplification system - documentation
</screen>
<para>
-This way of forming a sentence from the package name and synopsis should be
-considered as a heuristic and not a strict rule. There are some cases where it
-doesn't make sense to try to form a sentence.
+These synopses follow a modified formula. Where a package
+"<replaceable>name</replaceable>" has a synopsis
+"<replaceable>suite</replaceable> (<replaceable>role</replaceable>)" or
+"<replaceable>suite</replaceable> - <replaceable>role</replaceable>", the
+elements should be phrased so that they fit into the formula:
+</para>
+<para>
+The package <replaceable>name</replaceable> provides {a,an,the}
+<replaceable>role</replaceable> for the <replaceable>suite</replaceable>.
</para>
</section>
<footnote><para> As a special exception, if the omission of non-free files
would lead to the source failing to build without assistance from the Debian
diff, it might be appropriate to instead edit the files, omitting only the
-non-free parts of them, and/or explain the situation in a README.Debian-source
-<!-- or similarly named -->
+non-free parts of them, and/or explain the situation in a README.source
file in the root of the source tree. But in that case please also urge the
upstream author to make the non-free components easier seperable from the rest
of the source. </para> </footnote>
~ianmdlvl / developers-reference.git / blobdiff