<item>
must not require a package outside of <em>main</em>
for compilation or execution (thus, the package must
- not declare a <tt>Pre-Depends</tt>, <tt>Depends</tt>,
- <tt>Recommends</tt>, <tt>Build-Depends</tt>,
- or <tt>Build-Depends-Indep</tt> relationship on a
- non-<em>main</em> package unless a package
- in <em>main</em> is listed as an alternative),
+ not declare a "Depends", "Recommends", or
+ "Build-Depends" relationship on a non-<em>main</em>
+ package),
</item>
<item>
must not be so buggy that we refuse to support them,
<p>
In general, Debian packages should use the same version
- numbers as the upstream sources.
- </p>
-
- <p>
- However, in some cases where the upstream version number is
- based on a date (e.g., a development "snapshot" release) the
- package management system cannot handle these version
- numbers without epochs. For example, dpkg will consider
- "96May01" to be greater than "96Dec24".
+ numbers as the upstream sources. However, upstream version
+ numbers based on some date formats (sometimes used for
+ development or "snapshot" releases) will not be ordered
+ correctly by the package management software. For
+ example, <prng>dpkg</prng> will consider "96May01" to be
+ greater than "96Dec24".
</p>
<p>
To prevent having to use epochs for every new upstream
- version, the date based portion of the version number
- should be changed to the following format in such cases:
- "19960501", "19961224". It is up to the maintainer whether
- they want to bother the upstream maintainer to change
- the version numbers upstream, too.
- </p>
-
- <p>
- Note that other version formats based on dates which are
- parsed correctly by the package management system should
- <em>not</em> be changed.
+ version, the date-based portion of any upstream version number
+ should be given in a way that sorts correctly: four-digit year
+ first, followed by a two-digit numeric month, followed by a
+ two-digit numeric date, possibly with punctuation between the
+ components.
</p>
<p>
- Native Debian packages (i.e., packages which have been
- written especially for Debian) whose version numbers include
- dates should always use the "YYYYMMDD" format.
+ Native Debian packages (i.e., packages which have been written
+ especially for Debian) whose version numbers include dates
+ should also follow these rules. If punctuation is desired
+ between the date components, remember that hyphen (<tt>-</tt>)
+ cannot be used in native package versions. Period
+ (<tt>.</tt>) is normally a good choice.
</p>
</sect1>
<heading>The maintainer of a package</heading>
<p>
- Every package must have a Debian maintainer. The maintainer may
- be one person or a group of people reachable from a common email
+ Every package must have a maintainer. The maintainer may be one
+ person or a group of people reachable from a common email
address, such as a mailing list. The maintainer is responsible
for maintaining the Debian packaging files, evaluating and
responding appropriately to reported bugs, uploading new
- versions of the package, ensuring that the package is placed in
- the appropriate archive area and included in Debian releases as
- appropriate for the stability and utility of the package, and
- requesting removal of the package from the Debian distribution
- if it is no longer useful or maintainable.
+ versions of the package (either directly or through a sponsor),
+ ensuring that the package is placed in the appropriate archive
+ area and included in Debian releases as appropriate for the
+ stability and utility of the package, and requesting removal of
+ the package from the Debian distribution if it is no longer
+ useful or maintainable.
</p>
<p>
<p>
If the maintainer of a package no longer has time or desire to
- maintain a package, it is orphaned. The maintainer then becomes
- <tt>Debian QA Group <packages@qa.debian.org></tt>. These
- packages are considered maintained by the Debian project as a
- whole until someone else volunteers to take over maintenance.
- <footnote>
- The detailed procedure for doing this gracefully can be found
- in the Debian Developer's Reference, see <ref id="related">.
- </footnote>
+ maintain a package, it will be orphaned according to the
+ procedure described in the Debian Developer's Reference
+ (see <ref id="related">). The maintainer then
+ becomes <tt>Debian QA Group <packages@qa.debian.org></tt>.
+ These packages are considered maintained by the Debian project
+ as a whole until someone else volunteers to take over
+ maintenance.
</p>
</sect>
<p>
List of the names and email addresses of co-maintainers of the
- package, if any. If the package has other maintainers beside
+ package, if any. If the package has other maintainers besides
the one named in the <qref id="f-Maintainer">Maintainer
field</qref>, their names and email addresses should be listed
here. The format of each entry is the same as that of the
<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
+ <tt>build-indep</tt> and <tt>binary-indep</tt> targets is
assumed to be building the whole package, and therefore
installation of all build dependencies is required.
</p>
for C files) will need to be compiled twice, for the normal
case.
</p>
+
<p>
- You must specify the gcc option <tt>-D_REENTRANT</tt>
- when building a library (either static or shared) to make
- the library compatible with LinuxThreads.
+ Libraries should be built with threading support and to be
+ thread-safe if the library supports this.
</p>
<p>
<example compact="compact">
/usr/lib/cgi-bin/<var>cgi-bin-name</var>
</example>
- and should be referred to as
+ or a subdirectory of that directory, and should be
+ referred to as
<example compact="compact">
http://localhost/cgi-bin/<var>cgi-bin-name</var>
</example>
-
+ (possibly with a subdirectory name
+ before <var>cgi-bin-name</var>).
</item>
<item>
projects / debian / debian-policy.git / blobdiff