<p>
Every package must be accompanied by a verbatim copy of
its copyright and distribution license in the file
- <tt>/usr/share/doc/<ital><package-name></ital>/copyright</tt>
+ <tt>/usr/share/doc/<em><package-name></em>/copyright</tt>
(see <ref id="copyrightfile"> for further details).
</p>
<p>
<list compact="compact">
<item>
<p>
- <ital>subsection</ital> if the package is in the
+ <em>subsection</em> if the package is in the
<em>main</em> section,
</p>
</item>
<item>
<p>
- <ital>section/subsection</ital> if the package is in
+ <em>section/subsection</em> if the package is in
the <em>contrib</em> or <em>non-free</em> section,
and
</p>
<sect1>
<heading>Standards conformance</heading>
+ <sect id="standardsversion">
<p>
In the source package's <tt>Standards-Version</tt> control
<p>
Many of the tools in the package management suite manipulate
- data in a common format, known as control files. Binary and
- source packages have control data as do the <tt>.changes</tt>
- files which control the installation of uploaded files, and
- <prgn>dpkg</prgn>'s internal databases are in a similar
+ data represented in a common format, known as <em>control
+ data</em>. The data is often stored in <em>control
+ files</em>. Binary and source packages have control files,
+ and the <tt>.changes</tt> files which control the installation
+ of uploaded files are also in control file format.
+ <prgn>Dpkg</prgn>'s internal databases are in a similar
format.
</p>
<sect><heading>Syntax of control files</heading>
<p>
- A file consists of one or more paragraphs of fields. The
- paragraphs are separated by blank lines. Some control files
- only allow one paragraph; others allow several, in which
- case each paragraph often refers to a different package.
+ A control file consists of one or more paragraphs of fields.
+ The paragraphs are separated by blank lines. Some control
+ files allow only one paragraph; others allow several, in
+ which case each paragraph usually refers to a different
+ package. (For example, in source packages, the first
+ paragraph refers to the source package, and later paragraphs
+ refer to binary packages generated from the source.)
</p>
<p>
- Each paragraph is a series of fields and values; each field
- consists of a name, followed by a colon and the value. It
- ends at the end of the line. Horizontal whitespace (spaces
- and tabs) may occur immediately before or after the value
- and is ignored there; it is conventional to put a single
- space after the colon.
+ Each paragraph consists of a series of data fields; each
+ field consists of the field name, followed by a colon and
+ then the data/value associated with that field. It ends at
+ the end of the line. Horizontal whitespace (spaces and
+ tabs) may occur immediately before or after the value and is
+ ignored there; it is conventional to put a single space
+ after the colon. For example, a field might be:
+ <example>
+ Package: libc6
+ </example>
+ the field name is <tt>Package</tt> and the field value
+ <tt>libc6</tt>.
</p>
<p>
<p>
Except where otherwise stated only a single line of data is
allowed and whitespace is not significant in a field body.
- Whitespace may never appear inside names (of packages,
- architectures, files or anything else), version numbers or
- in between the characters of multi-character version
+ Whitespace must not appear inside names (of packages,
+ architectures, files or anything else) or version numbers,
+ or between the characters of multi-character version
relationships.
</p>
would mean a new paragraph.
</p>
- <p>
- It is important to note that there are several fields which
- are optional as far as <prgn>dpkg</prgn> and the related
- tools are concerned, but which must appear in every Debian
- package, or whose omission may cause problems. When writing
- the control files for Debian packages you <em>must</em> read
- the Debian policy manual in conjunction with the details
- below and the list of fields for the particular file.</p>
</sect>
<sect><heading>List of fields</heading>
<p>
This list here is not supposed to be exhaustive. Most fields
- are dealt with elsewhere in this document and in the
- dpkg documentation.
+ are dealt with elsewhere in this document.
</p>
<sect1 id="f-Package"><heading><tt>Package</tt>
</heading>
<p>
They must be at least two characters long and must start
- with an alphanumeric character. The use of lowercase
- package names is strongly recommended unless the package
- you're building (or referring to, in other fields) is
- already using uppercase.</p>
+ with an alphanumeric character and not be all digits. The
+ use of lowercase package names is strongly recommended
+ unless the package you're building (or referring to, in
+ other fields) is already using uppercase.</p>
</sect1>
<sect1 id="f-Version"><heading><tt>Version</tt>
complies. This is updated manually when editing the
source package to conform to newer standards; it can
sometimes be used to tell when a package needs attention.
+ Its format is described above; see
+ <ref id="standardsversion">.
</p>
-
- <p>
- Its format is the same as that of a version number except
- that no epoch or Debian revision is allowed - see <ref
- id="versions">.</p>
</sect1>
In a <tt>.changes</tt> file or parsed changelog output
this contains the (space-separated) name(s) of the
distribution(s) where this version of the package should
- be or was installed. Distribution names follow the rules
- for package names. (See <ref id="f-Package">).
- </p>
-
- <p>
+ be installed. Valid distributions are determined by the
+ archive maintainers.
<footnote>
- Current distribution values are:
+ Current distribution names are:
<taglist>
<tag><em>stable</em></tag>
<item>
<p>
This is the current `released' version of Debian
- GNU/Linux. Once the
- distribution is <em>stable</em> only major bug fixes
- are allowed. When changes are made to this
- distribution, the release number is increased
- (for example: 1.2r1 becomes 1.2r2 then 1.2r3, etc).
+ GNU/Linux. Once the distribution is
+ <em>stable</em> only security fixes and other
+ major bug fixes are allowed. When changes are
+ made to this distribution, the release number is
+ increased (for example: 2.2r1 becomes 2.2r2 then
+ 2.2r3, etc).
</p>
</item>
</p>
</item>
+ <tag><em>testing</em></tag>
+ <item>
+ <p>
+ This distribution value refers to the
+ <em>testing</em> part of the Debian distribution
+ tree. It receives its packages from the
+ unstable distribution after a short time lag to
+ ensure that there are no major issues with the
+ unstable packages. It is less prone to breakage
+ than unstable, but still risky. It is not
+ possible to upload packages directly to
+ <em>testing</em>.
+ </p>
+ </item>
+
<tag><em>frozen</em></tag>
<item>
<p>
- From time to time, the <em>unstable</em>
+ From time to time, the <em>frozen</em>
distribution enters a state of `code-freeze' in
anticipation of release as a <em>stable</em>
version. During this period of testing only
fixes for existing or newly-discovered bugs will
- be allowed.
+ be allowed. The exact details of this stage are
+ determined by the Release Manager.
</p>
</item>
<tag><em>experimental</em></tag>
<item>
<p>
- The packages with this distribution value are deemed
- by their maintainers to be high risk. Oftentimes they
- represent early beta or developmental packages from
- various sources that the maintainers want people to
- try, but are not ready to be a part of the other parts
- of the Debian distribution tree. Download at your own
+ The packages with this distribution value are
+ deemed by their maintainers to be high
+ risk. Oftentimes they represent early beta or
+ developmental packages from various sources that
+ the maintainers want people to try, but are not
+ ready to be a part of the other parts of the
+ Debian distribution tree. Download at your own
risk.
</p>
</item>
</taglist>
- There are several sections in each
- distribution. Currently, these sections are:
- <taglist>
- <tag><em>main</em></tag>
- <item>
- <p>
- The packages in this section are those in the
- main Debian distribution. They are all free
- (according to the Debian free software
- guidelines) and meet any other criteria for
- inclusion described in this manual.</p>
- </item>
-
- <tag><em>contrib</em></tag>
- <item>
- <p>
- The packages in this section do not meet the
- criteria for inclusion in the main Debian
- distribution as defined by this manual, but are
- otherwise free, as defined by the Debian free
- software guidelines.</p>
- </item>
-
- <tag><em>non-free</em></tag>
- <item>
- <p>
- Packages in <em>non-free</em> do not meet the
- criteria of free software, as defined by the
- Debian free software guidelines. Again, use your
- best judgment in downloading from this
- Distribution.</p>
- </item>
-
- </taglist> You should list <em>all</em> distributions that
- the package should be installed into. Except in unusual
- circumstances, installations to <em>stable</em> should also
- go into <em>frozen</em> (if it exists) and
- <em>unstable</em>. Likewise, installations into
- <em>frozen</em> should also go into <em>unstable</em>.
+ You should list <em>all</em> distributions that the
+ package should be installed into.
</footnote>
</p>
</sect1>
</sect>
</chapt>
- <chapt id="versions"><heading>Version numbering </heading>
+ <chapt id="versions"><heading>Version numbering</heading>
<p>
- Every package has a version number, in its <tt>Version</tt>
- control file field.
+ Every package has a version number recorded in its
+ <tt>Version</tt> control file field.
</p>
<p>
<p>
The version number format is:
- &lsqb<var>epoch</var><tt>:</tt>]<var>upstream-version</var>[<tt>-</tt><var>debian-revision</var>]
+ &lsqb<var>epoch</var><tt>:</tt>]<var>upstream_version</var>[<tt>-</tt><var>debian_revision</var>]
</p>
<p>
<p>
This is a single (generally small) unsigned integer. It
may be omitted, in which case zero is assumed. If it is
- omitted then the <var>upstream-version</var> may not
+ omitted then the <var>upstream_version</var> may not
contain any colons.
</p>
</item>
- <tag><var>upstream-version</var></tag>
+ <tag><var>upstream_version</var></tag>
<item>
<p>
- This is the main part of the version. It is usually the
- version number of the original (`upstream') package from
- which the <tt>.deb</tt> file has been made, if this is
- applicable. Usually this will be in the same format as
- that specified by the upstream author(s); however, it
- may need to be reformatted to fit into the package
- management system's format and comparison scheme.
+ This is the main part of the version number. It is
+ usually the version number of the original (`upstream')
+ package from which the <tt>.deb</tt> file has been made,
+ if this is applicable. Usually this will be in the same
+ format as that specified by the upstream author(s);
+ however, it may need to be reformatted to fit into the
+ package management system's format and comparison
+ scheme.
</p>
<p>
The comparison behavior of the package management system
- with respect to the <var>upstream-version</var> is
- described below. The <var>upstream-version</var>
+ with respect to the <var>upstream_version</var> is
+ described below. The <var>upstream_version</var>
portion of the version number is mandatory.
</p>
<p>
- The <var>upstream-version</var> may contain only
- alphanumerics and the characters <tt>.</tt> <tt>+</tt>
- <tt>-</tt> <tt>:</tt> (full stop, plus, hyphen, colon)
- and should start with a digit. If there is no
- <var>debian-revision</var> then hyphens are not allowed;
+ The <var>upstream_version</var> may contain only
+ alphanumerics
+ <footnote>
+ <p>Alphanumerics are <tt>A-Za-z0-9</tt> only.</p>
+ </footnote>
+ and the characters <tt>.</tt> <tt>+</tt> <tt>-</tt>
+ <tt>:</tt> (full stop, plus, hyphen, colon) and should
+ start with a digit. If there is no
+ <var>debian_revision</var> then hyphens are not allowed;
if there is no <var>epoch</var> then colons are not
allowed.</p>
</item>
- <tag><var>debian-revision</var></tag>
+ <tag><var>debian_revision</var></tag>
<item>
<p>
- This part of the version represents the version of the
- modifications that were made to the package to make it a
- Debian binary package. It is in the same format as the
- <var>upstream-version</var> and is compared in the same
- way.
+ This part of the version number specifies the version of
+ the Debian package based on the upstream version. It
+ may contain only alphanumerics and the characters
+ <tt>+</tt> and <tt>.</tt> (plus and full stop) and is
+ compared in the same way as the
+ <var>upstream_version</var> is.
</p>
<p>
It is optional; if it isn't present then the
- <var>upstream-version</var> may not contain a hyphen.
+ <var>upstream_version</var> may not contain a hyphen.
This format represents the case where a piece of
software was written specifically to be turned into a
- Debian binary package, and so there is only one
- `debianization' of it and therefore no revision
- indication is required.
+ Debian package, and so there is only one `debianization'
+ of it and therefore no revision indication is required.
</p>
<p>
It is conventional to restart the
- <var>debian-revision</var> at <tt>1</tt> each time the
- <var>upstream-version</var> is increased.
+ <var>debian_revision</var> at <tt>1</tt> each time the
+ <var>upstream_version</var> is increased.
</p>
<p>
- The package management system will break the
- <var>upstream-version</var> and
- <var>debian-revision</var> apart at the last hyphen in
- the string. 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).
- </p>
-
- <p>
- The <var>debian-revision</var> may contain only
- alphanumerics and the characters <tt>+</tt> and
- <tt>.</tt> (plus and full stop).
+ The package management system will break the version
+ 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).
</p>
</item>
</taglist>
- The <var>upstream-version</var> and <var>debian-revision</var>
+ The <var>upstream_version</var> and <var>debian_revision</var>
parts are compared by the package management system using the
same algorithm:
</p>
</p>
<p>
- These two steps are repeated (chopping initial non-digit
- strings and initial digit strings off from the start) until a
+ These two steps (comparing and removing initial non-digit
+ strings and initial digit strings) are repeated until a
difference is found or both strings are exhausted.
</p>
<p>
Note that the purpose of epochs is to allow us to leave behind
mistakes in version numbering, and to cope with situations
- where the version numbering changes. It is <em>not</em> there
- to cope with version numbers containing strings of letters
- which the package management system cannot interpret (such as
- <tt>ALPHA</tt> or <tt>pre-</tt>), or with silly orderings (the
- author of this manual has heard of a package whose versions
- went <tt>1.1</tt>, <tt>1.2</tt>, <tt>1.3</tt>, <tt>1</tt>,
- <tt>2.1</tt>, <tt>2.2</tt>, <tt>2</tt> and so forth).
+ where the version numbering scheme changes. It is
+ <em>not</em> intended to cope with version numbers containing
+ strings of letters which the package management system cannot
+ interpret (such as <tt>ALPHA</tt> or <tt>pre-</tt>), or with
+ silly orderings (the author of this manual has heard of a
+ package whose versions went <tt>1.1</tt>, <tt>1.2</tt>,
+ <tt>1.3</tt>, <tt>1</tt>, <tt>2.1</tt>, <tt>2.2</tt>,
+ <tt>2</tt> and so forth).
</p>
<p>
too.</p>
<p>
- Note, that other version formats based on dates which are
+ Note that other version formats based on dates which are
parsed correctly by the package management system should
<em>not</em> be changed.</p>
<sect id="timestamps"><heading>Time Stamps</heading>
<p>
- Maintainers are encouraged to preserve the modification
- times of the upstream source files in a package, as far as
- is reasonably possible. Even though this is optional, this
- is still a good idea.
+ Maintainers should preserve the modification times of the
+ upstream source files in a package, as far as is reasonably
+ possible.
<footnote>
<p>
The rationale is that there is some information conveyed
</sect>
<sect id="debianrules"><heading><tt>debian/rules</tt> - the
- main building script </heading>
+ main building script</heading>
<p>
This file must be an executable makefile, and contains the
package-specific recipes for compiling the package and
- building binary package(s) out of the source.
+ building binary package(s) from the source.
</p>
<p>
Since an interactive <tt>debian/rules</tt> script makes it
impossible to auto-compile that package and also makes it
hard for other people to reproduce the same binary
- package, all <strong>required targets</strong> MUST be
+ package, all <em>required targets</em> MUST be
non-interactive. At a minimum, required targets are the
ones called by <prgn>dpkg-buildpackage</prgn>, namely,
<em>clean</em>, <em>binary</em>, <em>binary-arch</em>,
</p>
<p>
- The targets which must be present are:
+ The required and optional targets are as follows:
<taglist>
<tag><tt>build</tt></tag>
<item>
<p>
- This should perform all non-interactive
- configuration and compilation of the package. If a
- package has an interactive pre-build configuration
- routine, the Debianised source package should be
- built after this has taken place, so that it can be
- built without rerunning the configuration.
+ This should perform all non-interactive configuration
+ and compilation of the package. If a package has an
+ interactive pre-build configuration routine, the
+ Debianized source package must either be built after
+ this has taken place (so that the binary package can
+ be built without rerunning the configuration) or the
+ configuration routine modified to become
+ non-interactive. (The latter is preferable if there
+ are architecture-specific features detected by the
+ configuration routine.)
</p>
<p>
</p>
<p>
- The <prgn>build</prgn> target may need to run
- <prgn>clean</prgn> first - see below.
+ The <prgn>build</prgn> target may need to run the
+ <prgn>clean</prgn> target first - see below.
</p>
<p>
- When a package has a configuration routine that
- takes a long time, or when the makefiles are poorly
- designed, or when <prgn>build</prgn> needs to run
- <prgn>clean</prgn> first, it is a good idea to
+ When a package has a configuration and build routine
+ which takes a long time, or when the makefiles are
+ poorly designed, or when <prgn>build</prgn> needs to
+
run <prgn>clean</prgn> first, it is a good idea to
<tt>touch build</tt> when the build process is
complete. This will ensure that if <tt>debian/rules
- build</tt> is run again it will not rebuild the
- whole program.
+ build</tt> is run again it will not rebuild the whole
+ program.
+ <footnote>
+ <p>
+ Another common way to do this is for <prgn>build</prgn>
+ to depend on <prgn>build-stamp</prgn> and to do
+ nothing else, and for the <prgn>build-stamp</prgn>
+ target to do the building and to <tt>touch
+ build-stamp</tt> on completion. This is
+ especially useful if the build routine creates a
+ file or directory called <tt>build</tt>; in such a
+ case, <prgn>build</prgn> will need to be listed as
+ a phony target (i.e., as a dependency of the
+ <tt>.PHONY</tt> target). See the documentation of
+ <prgn>make</prgn> for more information on phony
+ targets.
+ </p>
+ </footnote>
</p>
</item>
<item>
<p>
The <prgn>binary</prgn> target must be all that is
- necessary for the user to build the binary
- package. All these targets are required to be
- non-interactive. It is split into two parts:
- <prgn>binary-arch</prgn> builds the packages' output
- files which are specific to a particular
+ necessary for the user to build the binary package(s)
+ produced from this source package. All of these
+ targets are required to be non-interactive. It is
+ split into two parts: <prgn>binary-arch</prgn> builds
+ the binary packages which are specific to a particular
architecture, and <prgn>binary-indep</prgn> builds
those which are not.
</p>
</p>
<p>
- Both <prgn>binary-*</prgn> targets should depend on
+ Each <prgn>binary-*</prgn> target should depend on
the <prgn>build</prgn> target, above, so that the
package is built if it has not been already. It
should then create the relevant binary package(s),
</p>
<p>
- If one of the <prgn>binary-*</prgn> targets has
- nothing to do (this will be always be the case if
- the source generates only a single binary package,
- whether architecture-dependent or not) it
- <em>must</em> still exist, and must always
- succeed.
+ Both the <prgn>binary-arch</prgn> and
+ <prgn>binary-indep</prgn> targets <em>must</em> exist.
+ If one of them has nothing to do (which will always be
+ the case if the source generates only a single binary
+ package, whether architecture-dependent or not), it
+ must still exist and must always succeed.
</p>
<p>
The <prgn>binary</prgn> targets must be invoked as
root.
+ <footnote>
+ <p>
+ The <prgn>fakeroot</prgn> package often allows one
+ to build a package correctly even without being
+ root.
+ </p>
+ </footnote>
</p>
</item>
<item>
<p>
- This must undo any effects that the
- <prgn>build</prgn> and <prgn>binary</prgn> targets
- may have had, except that it should leave alone any
- output files created in the parent directory by a
- run of <prgn>binary</prgn>. This target must be
- non-interactive.
+ This must undo any effects that the <prgn>build</prgn>
+ and <prgn>binary</prgn> targets may have had, except
+ that it should leave alone any output files created in
+ the parent directory by a run of a <prgn>binary</prgn>
+ target. This target must be non-interactive.
</p>
<p>
- If a <prgn>build</prgn> file is touched at the end
- of the <prgn>build</prgn> target, as suggested
- above, it should be removed as the first thing that
- <prgn>clean</prgn> does, so that running
+ If a <prgn>build</prgn> file is touched at the end of
+ the <prgn>build</prgn> target, as suggested above, it
+ should be removed as the first action that
+ <prgn>clean</prgn> performs, so that running
<prgn>build</prgn> again after an interrupted
<prgn>clean</prgn> doesn't think that everything is
already done.
<p>
The <prgn>build</prgn>, <prgn>binary</prgn> and
- <prgn>clean</prgn> targets must be invoked with a current
- directory of the package's top-level directory.
+ <prgn>clean</prgn> targets must be invoked with the current
+ directory being the package's top-level directory.
</p>
</p>
<p>
- The architecture we build on and build for is determined by
- make variables via dpkg-architecture. You can get the Debian
- architecture and the GNU style architecture specification
- string for the build machine as well as the host
- machine. Here is a list of supported make variables:
+ The architectures we build on and build for are determined
+ by <prgn>make</prgn> variables using
+ <prgn>dpkg-architecture</prgn>. You can determine the
+ Debian architecture and the GNU style architecture
+ specification string for the build machine (the machine type
+ we are building on) as well as for the host machine (the
+ machine type we are building for). Here is a list of
+ supported <prgn>make</prgn> variables:
<list compact="compact">
<item>
<p><tt>DEB_*_ARCH</tt> (the Debian architecture)</p>
specification string)</p>
</item>
<item>
- <p><tt>DEB_*_GNU_CPU</tt> (the CPU part of DEB_*_GNU_TYPE)</p>
+ <p><tt>DEB_*_GNU_CPU</tt> (the CPU part of
+ <tt>DEB_*_GNU_TYPE</tt>)</p>
</item>
<item>
<p><tt>DEB_*_GNU_SYSTEM</tt> (the System part of
- DEB_*_GNU_TYPE)</p>
+ <tt>DEB_*_GNU_TYPE</tt>)</p>
</list>
- </p>
-
- <p>
where <tt>*</tt> is either <tt>BUILD</tt> for specification of
- the build machine or <tt>HOST</tt> for specification of the machine
- we build for.
+ the build machine or <tt>HOST</tt> for specification of the
+ host machine.
</p>
<p>
Backward compatibility can be provided in the rules file
by setting the needed variables to suitable default
- values, please refer to the documentation of
- dpkg-architecture for details.
+ values; please refer to the documentation of
+ <prgn>dpkg-architecture</prgn> for details.
</p>
<p>
Though there is nothing stopping an author who is also
the Debian maintainer from using it for all their
changes, it will have to be renamed if the Debian and
- upstream maintainers become different
- people.
+ upstream maintainers become different people. In such a
+ case, however, it might be better to maintain the
+ package as a non-native package.
</p>
</footnote>.
</p>
<p>
That format is a series of entries like this:
<example>
- <var>package</var> (<var>version</var>) <var>distribution(s)</var>; urgency=<var>urgency</var>
+<var>package</var> (<var>version</var>) <var>distribution(s)</var>; urgency=<var>urgency</var>
- * <var>change details</var>
- <var>more change details</var>
- * <var>even more change details</var>
+ * <var>change details</var>
+ <var>more change details</var>
+ * <var>even more change details</var>
- -- <var>maintainer name and email address</var> <var>date</var>
+ -- <var>maintainer name and email address</var> <var>date</var>
</example>
</p>
<prgn>dpkg</prgn> changelog format (though there is
currently only one useful <var>keyword</var>,
<tt>urgency</tt>).
+ <footnote>
+ <p>
+ Usual urgency values are <tt>low</tt>, <tt>medium</tt>,
+ <tt>high</tt> and <tt>critical</tt>. They have an
+ effect on how quickly a package will be considered for
+ inclusion into the <tt>testing</tt> distribution, and
+ give an indication of the importance of any fixes
+ included in this upload.
+ </p>
+ </footnote>
</p>
<p>
</p>
<p>
- The maintainer name and email address need <em>not</em>
- necessarily be those of the usual package maintainer.
- They should be the details of the person doing
- <em>this</em> version. The information here will be
- copied to the <tt>.changes</tt> file, and then later used
- to send an acknowledgement when the upload has been
- installed.
+ If this upload resolves bugs recorded in the Bug Tracking
+ System (BTS), they may be automatically closed on the
+ inclusion of this package into the Debian archive by
+ including the string: <tt>closes: Bug#<var>nnnnn</var></tt>
+ in the change details.
+ <footnote>
+ <p>
+ To be precise, the string should match the following
+ Perl regular expression:
+ <example>
+<tt>/closes:\s*(?:bug)?\#\s?\d+(?:,\s*(?:bug)?\#\s?\d+)*/i</tt>
+ </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.
+ </p>
+ </footnote>
+ </p>
+
+ <p>
+ The maintainer name and email address used in the changelog
+ should be the details of the person uploading <em>this</em>
+ version. They are <em>not</em> necessarily those of the
+ usual package maintainer. The information here will be
+ copied to the <tt>Changed-By</tt> field in the
+ <tt>.changes</tt> file, and then later used to send an
+ acknowledgement when the upload has been installed.
</p>
<p>
</p>
</footnote>; it should include the time zone specified
numerically, with the time zone name or abbreviation
- optionally present as a comment.
+ optionally present as a comment in parentheses.
</p>
<p>
<p>
When <prgn>dpkg-gencontrol</prgn>,
<prgn>dpkg-genchanges</prgn> and <prgn>dpkg-source</prgn>
- generate control files they do variable substitutions on
- their output just before writing it. Variable
+ generate control files they perform variable substitutions
+ on their output just before writing it. Variable
substitutions have the form
<tt>${<var>variable-name</var>}</tt>. The optional file
- <tt>debian/substvars</tt> contains variable substitutions
- to be used; variables can also be set directly from
+ <tt>debian/substvars</tt> contains variable substitutions to
+ be used; variables can also be set directly from
<tt>debian/rules</tt> using the <tt>-V</tt> option to the
- source packaging commands, and certain predefined
- variables are available.
+ source packaging commands, and certain predefined variables
+ are also available.
</p>
<p>
- The is usually generated and modified dynamically by
- <tt>debian/rules</tt> targets; in this case it must be
- removed by the <prgn>clean</prgn> target.
+ The <tt>debian/substvars</tt> file is usually generated and
+ modified dynamically by <tt>debian/rules</tt> targets; in
+ this case it must be removed by the <prgn>clean</prgn>
+ target.
</p>
<p>
</p>
<p>
- <prgn>dpkg-gencontrol</prgn> adds an entry to this file
- for the <tt>.deb</tt> file that will be created by
- <prgn>dpkg-deb</prgn> from the control file that it
- generates, so for most packages all that needs to be done
- with this file is to delete it in <prgn>clean</prgn>.
+ When <prgn>dpkg-gencontrol</prgn> is run for a binary
+ package, it adds an entry to <tt>debian/files</tt> for the
+ <tt>.deb</tt> file that will be created when <prgn>dpkg-deb
+ --build</prgn> is run for that binary package. So for most
+ packages all that needs to be done with this file is to
+ delete it in the <prgn>clean</prgn> target.
</p>
<p>
packages, but only when extracting
them.
</p>
- </footnote>
- <footnote>
<p>
Hard links may be permitted at some point in the
future, but would require a fair amount of
projects / debian / debian-policy.git / blobdiff