</p>
<p>
- The <var>date</var> must be in RFC822 format<footnote>
- This is generated by <tt>date -R</tt>.
- </footnote>; it must include the time zone specified
- numerically, with the time zone name or abbreviation
- optionally present as a comment in parentheses.
+ The <var>date</var> has the following format<footnote>
+ This is the same as the format generated by <tt>date
+ -R</tt>.
+ </footnote> (compatible and with the same semantics of
+ RFC 2822 and RFC 5322):
+ <example>day-of-week, dd month yyyy hh:mm:ss +zzzz</example>
+ where:
+ <list compact="compact">
+ <item>
+ day-of week is one of: Mon, Tue, Wed, Thu, Fri, Sat, Sun
+ </item>
+ <item>
+ dd is a one- or two-digit day of the month (01-31)
+ </item>
+ <item>
+ month is one of: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug,
+ Sep, Oct, Nov, Dec
+ </item>
+ <item>yyyy is the four-digit year (e.g. 2010)</item>
+ <item>hh is the two-digit hour (00-23)</item>
+ <item>mm is the two-digit minutes (00-59)</item>
+ <item>ss is the two-digit seconds (00-60)</item>
+ <item>
+ +zzzz or -zzzz is the the time zone offset from Coordinated
+ Universal Time (UTC). "+" indicates that the time is ahead
+ of (i.e., east of) UTC and "-" indicates that the time is
+ behind (i.e., west of) UTC. The first two digits indicate
+ the hour difference from UTC and the last two digits
+ indicate the number of additional minutes difference from
+ UTC. The last two digits must be in the range 00-59.
+ </item>
+ </list>
</p>
<p>
The <tt>build</tt> target should perform all the
configuration and compilation of the package.
If a package has an interactive pre-build
- configuration routine, the Debianized source package
+ configuration routine, the Debian 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
A package may also provide both of the targets
<tt>build-arch</tt> and <tt>build-indep</tt>.
The <tt>build-arch</tt> target, if provided, should
- perform all the configuration and compilation required
- for producing all architecture-dependant binary packages
- (those packages for which the body of the
- <tt>Architecture</tt> field in <tt>debian/control</tt>
- is not <tt>all</tt>).
- Similarly, the <tt>build-indep</tt> target, if
- provided, should perform all the configuration and
- compilation required for producing all
- architecture-independent binary packages
+ perform all the configuration and compilation required for
+ producing all architecture-dependant binary packages
(those packages for which the body of the
- <tt>Architecture</tt> field in <tt>debian/control</tt>
- is <tt>all</tt>).
+ <tt>Architecture</tt> field in <tt>debian/control</tt> is
+ not <tt>all</tt>). Similarly, the <tt>build-indep</tt>
+ target, if provided, should perform all the configuration
+ and compilation required for producing all
+ architecture-independent binary packages (those packages
+ for which the body of the <tt>Architecture</tt> field
+ in <tt>debian/control</tt> is <tt>all</tt>).
The <tt>build</tt> target should depend on those of the
targets <tt>build-arch</tt> and <tt>build-indep</tt> that
- are provided in the rules file.
+ are provided in the rules file.<footnote>
+ The intent of this split is so that binary-only builds
+ need not install the dependencies required for
+ the <tt>build-indep</tt> target. However, this is not
+ yet used in practice since <tt>dpkg-buildpackage
+ -B</tt>, and therefore the autobuilders,
+ invoke <tt>build</tt> rather than <tt>build-arch</tt>
+ due to the difficulties in determining whether the
+ optional <tt>build-arch</tt> target exists.
+ </footnote>
</p>
<p>
<tt>libc6</tt>.
</p>
+ <p>
+ A paragraph must not contain more than one instance of a
+ particular field name.
+ </p>
+
<p>
Many fields' values may span several lines; in this case
each continuation line must start with a space or a tab.
The syntax and semantics of the fields are described below.
</p>
-<!-- stuff -->
-
<p>
These fields are used by <prgn>dpkg-gencontrol</prgn> to
generate control files for binary packages (see below), by
<list compact="compact">
<item><qref id="f-Format"><tt>Format</tt></qref> (mandatory)</item>
<item><qref id="f-Source"><tt>Source</tt></qref> (mandatory)</item>
+ <item><qref id="f-Binary"><tt>Binary</tt></qref></item>
+ <item><qref id="f-Architecture"><tt>Architecture</tt></qref></item>
<item><qref id="f-Version"><tt>Version</tt></qref> (mandatory)</item>
<item><qref id="f-Maintainer"><tt>Maintainer</tt></qref> (mandatory)</item>
<item><qref id="f-Uploaders"><tt>Uploaders</tt></qref></item>
- <item><qref id="f-Binary"><tt>Binary</tt></qref></item>
- <item><qref id="f-Architecture"><tt>Architecture</tt></qref></item>
- <item><qref id="sourcebinarydeps"><tt>Build-Depends</tt> et al</qref></item>
+ <item><qref id="f-Homepage"><tt>Homepage</tt></qref></item>
<item><qref id="f-Standards-Version"><tt>Standards-Version</tt></qref> (recommended)</item>
+ <item><qref id="sourcebinarydeps"><tt>Build-Depends</tt> et al</qref></item>
+ <item><qref id="f-Checksums"><tt>Checksums-Sha1</tt>
+ and <tt>Checksums-Sha256</tt></qref> (recommended)</item>
<item><qref id="f-Files"><tt>Files</tt></qref> (mandatory)</item>
- <item><qref id="f-Homepage"><tt>Homepage</tt></qref></item>
</list>
</p>
<item><qref id="f-Description"><tt>Description</tt></qref> (mandatory)</item>
<item><qref id="f-Closes"><tt>Closes</tt></qref></item>
<item><qref id="f-Changes"><tt>Changes</tt></qref> (mandatory)</item>
+ <item><qref id="f-Checksums"><tt>Checksums-Sha1</tt>
+ and <tt>Checksums-Sha256</tt></qref> (recommended)</item>
<item><qref id="f-Files"><tt>Files</tt></qref> (mandatory)</item>
</list>
</p>
<p>
The package maintainer's name and email address. The name
- should come first, then the email address inside angle
- brackets <tt><></tt> (in RFC822 format).
+ must come first, then the email address inside angle
+ brackets <tt><></tt> (in RFC822 format).
</p>
<p>
<sect1 id="f-Uploaders">
<heading><tt>Uploaders</tt></heading>
- List of the names and email addresses of co-maintainers of
- the package, if any. If the package has other maintainers
- beside the one named in the
- <qref id="f-Maintainer">Maintainer field</qref>, their
- names and email addresses should be listed here. The
- format is the same as that of the Maintainer tag, and
- multiple entries should be comma separated. Currently,
- this field is restricted to a single line of data. This
- is an optional field.
- </p>
+ <p>
+ List of the names and email addresses of co-maintainers of
+ the package, if any. If the package has other maintainers
+ beside 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 Maintainer field, and
+ multiple entries must be comma separated. This is an optional
+ field.
+ </p>
+
<p>
Any parser that interprets the Uploaders field in
<file>debian/control</file> must permit it to span multiple
<heading><tt>Changed-By</tt></heading>
<p>
- The name and email address of the person who changed the
- said package. Usually the name of the maintainer.
- All the rules for the Maintainer field apply here, too.
+ The name and email address of the person who prepared this
+ version of the package, usually a maintainer. The syntax is
+ the same as for the <qref id="f-Maintainer">Maintainer
+ field</qref>.
</p>
</sect1>
It is optional; if it isn't present then the
<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 package, and so there is only one "debianisation"
- of it and therefore no revision indication is required.
+ software was written specifically to be a Debian
+ package, where the Debian package source must always
+ be identical to the pristine source and therefore no
+ revision indication is required.
</p>
<p>
<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).
+ silly orderings.<footnote>
+ 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.
+ </footnote>
</p>
</sect1>
<heading><tt>Date</tt></heading>
<p>
- This field includes the date the package was built or last edited.
+ This field includes the date the package was built or last
+ edited. It must be in the same format as the <var>date</var>
+ in a <file>debian/changelog</file> entry.
</p>
<p>
</p>
</sect1>
+ <sect1 id="f-Checksums">
+ <heading><tt>Checksums-Sha1</tt>
+ and <tt>Checksums-Sha256</tt></heading>
+
+ <p>
+ These fields contain a list of files with a checksum and size
+ for each one. Both <tt>Checksums-Sha1</tt>
+ and <tt>Checksums-Sha256</tt> have the same syntax and differ
+ only in the checksum algorithm used: SHA-1
+ for <tt>Checksums-Sha1</tt> and SHA-256
+ for <tt>Checksums-Sha256</tt>.
+ </p>
+
+ <p>
+ <tt>Checksums-Sha1</tt> and <tt>Checksums-Sha256</tt> are
+ multiline fields. The first line of the field value (the part
+ on the same line as <tt>Checksums-Sha1:</tt>
+ or <tt>Checksums-Sha256:</tt>) is always empty. The content
+ of the field is expressed as continuation lines, one line per
+ file. Each line consists of the checksum, a space, the file
+ size, a space, and the file name. For example (from
+ a <file>.changes</file> file):
+ <example>
+Checksums-Sha1:
+ 1f418afaa01464e63cc1ee8a66a05f0848bd155c 1276 example_1.0-1.dsc
+ a0ed1456fad61116f868b1855530dbe948e20f06 171602 example_1.0.orig.tar.gz
+ 5e86ecf0671e113b63388dac81dd8d00e00ef298 6137 example_1.0-1.debian.tar.gz
+ 71a0ff7da0faaf608481195f9cf30974b142c183 548402 example_1.0-1_i386.deb
+Checksums-Sha256:
+ ac9d57254f7e835bed299926fd51bf6f534597cc3fcc52db01c4bffedae81272 1276 example_1.0-1.dsc
+ 0d123be7f51e61c4bf15e5c492b484054be7e90f3081608a5517007bfb1fd128 171602 example_1.0.orig.tar.gz
+ f54ae966a5f580571ae7d9ef5e1df0bd42d63e27cb505b27957351a495bc6288 6137 example_1.0-1.debian.tar.gz
+ 3bec05c03974fdecd11d020fc2e8250de8404867a8a2ce865160c250eb723664 548402 example_1.0-1_i386.deb
+ </example>
+ </p>
+
+ <p>
+ In the <file>.dsc</file> file, these fields should list all
+ files that make up the source package. In
+ the <file>.changes</file> file, these fields should list all
+ files being uploaded. The list of files in these fields
+ must match the list of files in the <tt>Files</tt> field.
+ </p>
+ </sect1>
+
</sect>
<sect>
<heading>Controlling terminal for maintainer scripts</heading>
<p>
- The maintainer scripts are guaranteed to run with a
- controlling terminal and can interact with the user.
- Because these scripts may be executed with standard output
- redirected into a pipe for logging purposes, Perl scripts
- should set unbuffered output by setting <tt>$|=1</tt> so
- that the output is printed immediately rather than being
- buffered.
+ Maintainer scripts are not guaranteed to run with a controlling
+ terminal and may not be able to interact with the user. They
+ must be able to fall back to noninteractive behavior if no
+ controlling terminal is available. Maintainer scripts that
+ prompt via a program conforming to the Debian Configuration
+ Management Specification (see <ref id="maintscriptprompt">) may
+ assume that program will handle falling back to noninteractive
+ behavior.
+ </p>
+
+ <p>
+ For high-priority prompts without a reasonable default answer,
+ maintainer scripts may abort if there is no controlling
+ terminal. However, this situation should be avoided if at all
+ possible, since it prevents automated or unattended installs.
+ In most cases, users will consider this to be a bug in the
+ package.
</p>
</sect>
+
<sect id="exitstatus">
<heading>Exit status</heading>
<p>
Normally a <tt>Breaks</tt> entry will have an "earlier than"
version clause; such a <tt>Breaks</tt> is introduced in the
- version of an (implicit or explicit) dependency which
- violates an assumption or reveals a bug in earlier versions
- of the broken package. This use of <tt>Breaks</tt> will
- inform higher-level package management tools that broken
- package must be upgraded before the new one.
+ version of an (implicit or explicit) dependency which violates
+ an assumption or reveals a bug in earlier versions of the broken
+ package, or which takes over a file from earlier versions of the
+ package named in <tt>Breaks</tt>. This use of <tt>Breaks</tt>
+ will inform higher-level package management tools that the
+ broken package must be upgraded before the new one.
</p>
<p>
If the breaking package also overwrites some files from the
- older package, it should use <tt>Replaces</tt> (not
- <tt>Conflicts</tt>) to ensure this goes smoothly.
+ older package, it should use <tt>Replaces</tt> to ensure this
+ goes smoothly. See <ref id="replaces"> for a full discussion
+ of taking over files from other packages, including how to
+ use <tt>Breaks</tt> in those cases.
+ </p>
+
+ <p>
+ Many of the cases where <tt>Breaks</tt> should be used were
+ previously handled with <tt>Conflicts</tt>
+ because <tt>Breaks</tt> did not yet exist.
+ Many <tt>Conflicts</tt> fields should now be <tt>Breaks</tt>.
+ See <ref id="conflicts"> for more information about the
+ differences.
</p>
</sect>
When one binary package declares a conflict with another
using a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will
refuse to allow them to be installed on the system at the
- same time.
+ same time. This is a stronger restriction than <tt>Breaks</tt>,
+ which just prevents both packages from being configured at the
+ same time. Conflicting packages cannot be unpacked on the
+ system at the same time.
</p>
<p>
If one package is to be installed, the other must be removed
- first - if the package being installed is marked as
- replacing (see <ref id="replaces">) the one on the system,
- or the one on the system is marked as deselected, or both
- packages are marked <tt>Essential</tt>, then
- <prgn>dpkg</prgn> will automatically remove the package
- which is causing the conflict, otherwise it will halt the
- installation of the new package with an error. This
- mechanism is specifically designed to produce an error when
- the installed package is <tt>Essential</tt>, but the new
- package is not.
+ first. If the package being installed is marked as replacing
+ (see <ref id="replaces">, but note that <tt>Breaks</tt> should
+ normally be used in this case) the one on the system, or the one
+ on the system is marked as deselected, or both packages are
+ marked <tt>Essential</tt>, then <prgn>dpkg</prgn> will
+ automatically remove the package which is causing the conflict.
+ Otherwise, it will halt the installation of the new package with
+ an error. This mechanism is specifically designed to produce an
+ error when the installed package is <tt>Essential</tt>, but the
+ new package is not.
</p>
<p>
</p>
<p>
- A <tt>Conflicts</tt> entry should almost never have an
- "earlier than" version clause. This would prevent
- <prgn>dpkg</prgn> from upgrading or installing the package
- which declared such a conflict until the upgrade or removal
- of the conflicted-with package had been completed. Instead,
- <tt>Breaks</tt> may be used.
+ Normally, <tt>Breaks</tt> should be used instead
+ of <tt>Conflicts</tt> since <tt>Conflicts</tt> imposes a
+ stronger restriction on the ordering of package installation or
+ upgrade and can make it more difficult for the package manager
+ to find a correct solution to an upgrade or installation
+ problem. <tt>Breaks</tt> should be used
+ <list>
+ <item>when moving a file from one package to another (see
+ <ref id="replaces">),</item>
+ <item>when splitting a package (a special case of the previous
+ one), or</item>
+ <item>when the breaking package exposes a bug in or interacts
+ badly with particular versions of the broken
+ package.</item>
+ </list>
+ <tt>Conflicts</tt> should be used
+ <list>
+ <item>when two packages provide the same file and will
+ continue to do so,</item>
+ <item>in conjunction with <tt>Provides</tt> when only one
+ package providing a given virtual facility may be installed
+ at a time (see <ref id="virtual">),</item>
+ <item>in other cases where one must prevent simultaneous
+ installation of two packages for reasons that are ongoing
+ (not fixed in a later version of one of the packages) or
+ that must prevent both packages from being unpacked at the
+ same time, not just configured.</item>
+ </list>
+ Be aware that adding <tt>Conflicts</tt> is normally not the best
+ solution when two packages provide the same files. Depending on
+ the reason for that conflict, using alternatives or renaming the
+ files is often a better approach. See, for
+ example, <ref id="binaries">.
+ </p>
+
+ <p>
+ A <tt>Conflicts</tt> entry may have an "earlier than" version
+ clause if the reason for the conflict is corrected in a later
+ version of one of the packages. However, normally the presence
+ of an "earlier than" version clause is a sign
+ that <tt>Breaks</tt> should have been used instead. An "earlier
+ than" version clause in <tt>Conflicts</tt>
+ prevents <prgn>dpkg</prgn> from upgrading or installing the
+ package which declares such a conflict until the upgrade or
+ removal of the conflicted-with package has been completed, which
+ is a strong restriction.
</p>
</sect>
</p>
<p>
- If a relationship field has a version number attached
- then only real packages will be considered to see whether
- the relationship is satisfied (or the prohibition violated,
- for a conflict or breakage) - it is assumed that a real
- package which provides the virtual package is not of the
- "right" version. So, a <tt>Provides</tt> field may not
- contain version numbers, and the version number of the
- concrete package which provides a particular virtual package
- will not be looked at when considering a dependency on or
- conflict with the virtual package name.
+ If a relationship field has a version number attached, only real
+ packages will be considered to see whether the relationship is
+ satisfied (or the prohibition violated, for a conflict or
+ breakage). In other words, if a version number is specified,
+ this is a request to ignore all <tt>Provides</tt> for that
+ package name and consider only real packages. The package
+ manager will assume that a package providing that virtual
+ package is not of the "right" version. A <tt>Provides</tt>
+ field may not contain version numbers, and the version number of
+ the concrete package which provides a particular virtual package
+ will not be considered when considering a dependency on or
+ conflict with the virtual package name.<footnote>
+ It is possible that a future release of <prgn>dpkg</prgn> may
+ add the ability to specify a version number for each virtual
+ package it provides. This feature is not yet present,
+ however, and is expected to be used only infrequently.
+ </footnote>
</p>
<p>
- It is likely that the ability will be added in a future
- release of <prgn>dpkg</prgn> to specify a version number for
- each virtual package it provides. This feature is not yet
- present, however, and is expected to be used only
- infrequently.
+ To specify which of a set of real packages should be the default
+ to satisfy a particular dependency on a virtual package, list
+ the real package as an alternative before the virtual one.
</p>
<p>
- If you want to specify which of a set of real packages
- should be the default to satisfy a particular dependency on
- a virtual package, you should list the real package as an
- alternative before the virtual one.
+ If the virtual package represents a facility that can only be
+ provided by one real package at a time, such as
+ the <package>mail-transport-agent</package> virtual package that
+ requires installation of a binary that would conflict with all
+ other providers of that virtual package (see
+ <ref id="mail-transport-agents">), all packages providing that
+ virtual package should also declare a conflict with it
+ using <tt>Conflicts</tt>. This will ensure that at most one
+ provider of that virtual package is unpacked or installed at a
+ time.
</p>
</sect>
-
<sect id="replaces"><heading>Overwriting files and replacing
packages - <tt>Replaces</tt></heading>
<sect1><heading>Overwriting files in other packages</heading>
<p>
- Firstly, as mentioned before, it is usually an error for a
- package to contain files which are on the system in
- another package.
+ It is usually an error for a package to contain files which
+ are on the system in another package. However, if the
+ overwriting package declares that it <tt>Replaces</tt> the one
+ containing the file being overwritten, then <prgn>dpkg</prgn>
+ will replace the file from the old package with that from the
+ new. The file will no longer be listed as "owned" by the old
+ package and will be taken over by the new package.
+ Normally, <tt>Breaks</tt> should be used in conjunction
+ with <tt>Replaces</tt>.<footnote>
+ To see why <tt>Breaks</tt> is normally needed in addition
+ to <tt>Replaces</tt>, consider the case of a file in the
+ package <package>foo</package> being taken over by the
+ package <package>foo-data</package>.
+ <tt>Replaces</tt> will allow <package>foo-data</package> to
+ be installed and take over that file. However,
+ without <tt>Breaks</tt>, nothing
+ requires <package>foo</package> to be upgraded to a newer
+ version that knows it does not include that file and instead
+ depends on <package>foo-data</package>. Nothing would
+ prevent the new <package>foo-data</package> package from
+ being installed and then removed, removing the file that it
+ took over from <package>foo</package>. After that
+ operation, the package manager would think the system was in
+ a consistent state, but the <package>foo</package> package
+ would be missing one of its files.
+ </footnote>
</p>
<p>
- However, if the overwriting package declares that it
- <tt>Replaces</tt> the one containing the file being
- overwritten, then <prgn>dpkg</prgn> will replace the file
- from the old package with that from the new. The file
- will no longer be listed as "owned" by the old package.
+ For example, if a package <package>foo</package> is split
+ into <package>foo</package> and <package>foo-data</package>
+ starting at version 1.2-3, <package>foo-data</package> would
+ have the fields
+ <example compact="compact">
+Replaces: foo (<< 1.2-3)
+Breaks: foo (<< 1.2-3)
+ </example>
+ in its control file. The new version of the
+ package <package>foo</package> would normally have the field
+ <example compact="compact">
+Depends: foo-data (>= 1.2-3)
+ </example>
+ (or possibly <tt>Recommends</tt> or even <tt>Suggests</tt> if
+ the files moved into <package>foo-data</package> are not
+ required for normal operation).
</p>
<p>
special argument to allow the package to do any final
cleanup required. See <ref id="mscriptsinstact">.
<footnote>
- <p>
- Replaces is a one way relationship -- you have to
- install the replacing package after the replaced
- package.
- </p>
+ Replaces is a one way relationship. You have to install
+ the replacing package after the replaced package.
</footnote>
</p>
<p>
For this usage of <tt>Replaces</tt>, virtual packages (see
<ref id="virtual">) are not considered when looking at a
- <tt>Replaces</tt> field - the packages declared as being
+ <tt>Replaces</tt> field. The packages declared as being
replaced must be mentioned by their real names.
</p>
<p>
- Furthermore, this usage of <tt>Replaces</tt> only takes
- effect when both packages are at least partially on the
- system at once, so that it can only happen if they do not
- conflict or if the conflict has been overridden.
+ This usage of <tt>Replaces</tt> only takes effect when both
+ packages are at least partially on the system at once. It is
+ not relevant if the packages conflict unless the conflict has
+ been overridden.
</p>
-
</sect1>
<sect1><heading>Replacing whole packages, forcing their
removal</heading>
<p>
- Secondly, <tt>Replaces</tt> allows the packaging system to
+ Second, <tt>Replaces</tt> allows the packaging system to
resolve which package should be removed when there is a
- conflict - see <ref id="conflicts">. This usage only
- takes effect when the two packages <em>do</em> conflict,
- so that the two usages of this field do not interfere with
- each other.
+ conflict (see <ref id="conflicts">). This usage only takes
+ effect when the two packages <em>do</em> conflict, so that the
+ two usages of this field do not interfere with each other.
</p>
<p>
Replaces: mail-transport-agent
</example>
ensuring that only one MTA can be installed at any one
- time.
+ time. See <ref id="virtual"> for more information about this
+ example.
</sect1>
</sect>
The dependencies and conflicts they define must be satisfied
(as defined earlier for binary packages) in order to invoke
the targets in <tt>debian/rules</tt>, as follows:<footnote>
- <p>
- If you make "build-arch" or "binary-arch", you need
- Build-Depends. If you make "build-indep" or
- "binary-indep", you need Build-Depends and
- Build-Depends-Indep. If you make "build" or "binary",
- you need both.
- </p>
<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 basically assumed to be building the whole package
- anyway and so installs all build dependencies. The
- autobuilders use <tt>dpkg-buildpackage -B</tt>, which
- calls <tt>build</tt> (not <tt>build-arch</tt>, since it
- does not yet know how to check for its existence) and
- <tt>binary-arch</tt>.
+ met with Build-Depends. Anyone building the
+ <tt>build-indep</tt> and binary-indep<tt></tt> targets is
+ assumed to be building the whole package, and therefore
+ installation of all build dependencies is required.
</p>
<p>
- The purpose of the original split, I recall, was so that
- the autobuilders wouldn't need to install extra packages
- needed only for the binary-indep targets. But without a
- build-arch/build-indep split, this didn't work, since
- most of the work is done in the build target, not in the
- binary target.
+ The autobuilders use <tt>dpkg-buildpackage -B</tt>, which
+ calls <tt>build</tt>, not <tt>build-arch</tt> since it does
+ not yet know how to check for its existence, and
+ <tt>binary-arch</tt>. The purpose of the original split
+ between <tt>Build-Depends</tt> and
+ <tt>Build-Depends-Indep</tt> was so that the autobuilders
+ wouldn't need to install extra packages needed only for the
+ binary-indep targets. But without a build-arch/build-indep
+ split, this didn't work, since most of the work is done in
+ the build target, not in the binary target.
</p>
</footnote>
-
<taglist>
- <tag><tt>Build-Depends</tt>, <tt>Build-Conflicts</tt></tag>
+ <tag><tt>clean</tt>, <tt>build-arch</tt>, and
+ <tt>binary-arch</tt></tag>
<item>
- The <tt>Build-Depends</tt> and
- <tt>Build-Conflicts</tt> fields must be satisfied when
- any of the following targets is invoked:
- <tt>build</tt>, <tt>clean</tt>, <tt>binary</tt>,
- <tt>binary-arch</tt>, <tt>build-arch</tt>,
- <tt>build-indep</tt> and <tt>binary-indep</tt>.
+ Only the <tt>Build-Depends</tt> and <tt>Build-Conflicts</tt>
+ fields must be satisfied when these targets are invoked.
</item>
- <tag><tt>Build-Depends-Indep</tt>,
- <tt>Build-Conflicts-Indep</tt></tag>
+ <tag><tt>build</tt>, <tt>build-indep</tt>, <tt>binary</tt>,
+ and <tt>binary-indep</tt></tag>
<item>
- The <tt>Build-Depends-Indep</tt> and
- <tt>Build-Conflicts-Indep</tt> fields must be
- satisfied when any of the following targets is
- invoked: <tt>build</tt>, <tt>build-indep</tt>,
- <tt>binary</tt> and <tt>binary-indep</tt>.
+ The <tt>Build-Depends</tt>, <tt>Build-Conflicts</tt>,
+ <tt>Build-Depends-Indep</tt>, and
+ <tt>Build-Conflicts-Indep</tt> fields must be satisfied when
+ these targets are invoked.
</item>
</taglist>
</p>
-
</sect>
-
</chapt>
<heading>Development files</heading>
<p>
- The development files associated to a shared library need to be
- placed in a package called
- <package><var>libraryname</var><var>soversion</var>-dev</package>,
+ If there are development files associated with a shared library,
+ the source package needs to generate a binary development package
+
named <package><var>libraryname</var><var>soversion</var>-dev</package>,
or if you prefer only to support one development version at a
- time, <package><var>libraryname</var>-dev</package>.
+ time, <package><var>libraryname</var>-dev</package>. Installing
+ the development package must result in installation of all the
+ development files necessary for compiling programs against that
+ shared library.<footnote>
+ This wording allows the development files to be split into
+ several packages, such as a separate architecture-independent
+ <package><var>libraryname</var>-headers</package>, provided that
+ the development package depends on all the required additional
+ packages.
+ </footnote>
</p>
<p>
<chapt id="files">
<heading>Files</heading>
- <sect>
+ <sect id="binaries">
<heading>Binaries</heading>
<p>
package is purged.
</item>
</list>
+ Obsolete configuration files without local changes may be
+ removed by the package during upgrade.
</p>
<p>
<p>
If a program needs to specify an <em>architecture specification
- string</em> in some place, it should select one of the
- strings provided by <tt>dpkg-architecture -L</tt>. The
- strings are in the format
- <tt><var>os</var>-<var>arch</var></tt>, though the OS part
- is sometimes elided, as when the OS is Linux.<footnote>
- <p>Currently, the strings are:
- i386 ia64 alpha amd64 armeb arm hppa m32r m68k mips
- mipsel powerpc ppc64 s390 s390x sh3 sh3eb sh4 sh4eb
- sparc darwin-i386 darwin-ia64 darwin-alpha darwin-amd64
- darwin-armeb darwin-arm darwin-hppa darwin-m32r
- darwin-m68k darwin-mips darwin-mipsel darwin-powerpc
- darwin-ppc64 darwin-s390 darwin-s390x darwin-sh3
- darwin-sh3eb darwin-sh4 darwin-sh4eb darwin-sparc
- freebsd-i386 freebsd-ia64 freebsd-alpha freebsd-amd64
- freebsd-armeb freebsd-arm freebsd-hppa freebsd-m32r
- freebsd-m68k freebsd-mips freebsd-mipsel freebsd-powerpc
- freebsd-ppc64 freebsd-s390 freebsd-s390x freebsd-sh3
- freebsd-sh3eb freebsd-sh4 freebsd-sh4eb freebsd-sparc
- kfreebsd-i386 kfreebsd-ia64 kfreebsd-alpha
- kfreebsd-amd64 kfreebsd-armeb kfreebsd-arm kfreebsd-hppa
- kfreebsd-m32r kfreebsd-m68k kfreebsd-mips
- kfreebsd-mipsel kfreebsd-powerpc kfreebsd-ppc64
- kfreebsd-s390 kfreebsd-s390x kfreebsd-sh3 kfreebsd-sh3eb
- kfreebsd-sh4 kfreebsd-sh4eb kfreebsd-sparc knetbsd-i386
- knetbsd-ia64 knetbsd-alpha knetbsd-amd64 knetbsd-armeb
- knetbsd-arm knetbsd-hppa knetbsd-m32r knetbsd-m68k
- knetbsd-mips knetbsd-mipsel knetbsd-powerpc
- knetbsd-ppc64 knetbsd-s390 knetbsd-s390x knetbsd-sh3
- knetbsd-sh3eb knetbsd-sh4 knetbsd-sh4eb knetbsd-sparc
- netbsd-i386 netbsd-ia64 netbsd-alpha netbsd-amd64
- netbsd-armeb netbsd-arm netbsd-hppa netbsd-m32r
- netbsd-m68k netbsd-mips netbsd-mipsel netbsd-powerpc
- netbsd-ppc64 netbsd-s390 netbsd-s390x netbsd-sh3
- netbsd-sh3eb netbsd-sh4 netbsd-sh4eb netbsd-sparc
- openbsd-i386 openbsd-ia64 openbsd-alpha openbsd-amd64
- openbsd-armeb openbsd-arm openbsd-hppa openbsd-m32r
- openbsd-m68k openbsd-mips openbsd-mipsel openbsd-powerpc
- openbsd-ppc64 openbsd-s390 openbsd-s390x openbsd-sh3
- openbsd-sh3eb openbsd-sh4 openbsd-sh4eb openbsd-sparc
- hurd-i386 hurd-ia64 hurd-alpha hurd-amd64 hurd-armeb
- hurd-arm hurd-hppa hurd-m32r hurd-m68k hurd-mips
- hurd-mipsel hurd-powerpc hurd-ppc64 hurd-s390 hurd-s390x
- hurd-sh3 hurd-sh3eb hurd-sh4 hurd-sh4eb hurd-sparc
- </p>
- </footnote>
+ string</em> in some place, it should select one of the strings
+ provided by <tt>dpkg-architecture -L</tt>. The strings are in
+ the format <tt><var>os</var>-<var>arch</var></tt>, though the OS
+ part is sometimes elided, as when the OS is Linux.
</p>
<p>
<tt><var>arch</var>-unknown-linux</tt>, since the
<tt>unknown</tt> does not look very good.
</p>
- </sect>
- <sect id="arch-wildcard-spec">
- <heading>Architecture Wildcards</heading>
+ <sect1 id="arch-wildcard-spec">
+ <heading>Architecture wildcards</heading>
- <p>
- A package may specify an architecture wildcard. Architecture
- wildcards are in the format <tt>any</tt> (which matches every
- architecture), <tt><var>os</var></tt>-any, or
- any-<tt><var>cpu</var></tt>. <footnote>
- Internally, the package system normalizes the GNU triplets and
- the Debian arches into Debian arch triplets (which are kind of
- inverted GNU triplets), with the first component of the
- triplet representing the libc and ABI in use, and then does
- matching against those triplets. However, such triplets are
- an internal implementation detail that should not be used by
- packages directly. The libc and ABI portion is handled
- internally by the package system based on the <var>os</var>
- and <var>cpu</var>.
- </footnote>
- </p>
+ <p>
+ A package may specify an architecture wildcard. Architecture
+ wildcards are in the format <tt>any</tt> (which matches every
+ architecture), <tt><var>os</var></tt>-any, or
+ any-<tt><var>cpu</var></tt>. <footnote>
+ Internally, the package system normalizes the GNU triplets
+ and the Debian arches into Debian arch triplets (which are
+ kind of inverted GNU triplets), with the first component of
+ the triplet representing the libc and ABI in use, and then
+ does matching against those triplets. However, such
+ triplets are an internal implementation detail that should
+ not be used by packages directly. The libc and ABI portion
+ is handled internally by the package system based on
+ the <var>os</var> and <var>cpu</var>.
+ </footnote>
+ </p>
+ </sect1>
</sect>
<sect>
<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>
name="Man-Page-HOWTO">,
<manref name="man" section="7">, the examples
created by <prgn>debmake</prgn> or <prgn>dh_make</prgn>,
- the helper program
s <prgn>help2man</prgn>, or the
+ the helper program <prgn>help2man</prgn>, or the
directory <file>/usr/share/doc/man-db/examples</file>.
</footnote>
</p>
</p>
<p>
- Packages distributed under the UCB BSD license, the Apache
- license (version 2.0), the Artistic license, the GNU GPL
- (version 2 or 3), the GNU LGPL (versions 2, 2.1, or 3), and the
- GNU FDL (versions 1.2 or 1.3) should refer to the corresponding
- files under <file>/usr/share/common-licenses</file>,<footnote>
+ Packages distributed under the Apache license (version 2.0), the
+ Artistic license, the GNU GPL (version 2 or 3), the GNU LGPL
+ (versions 2, 2.1, or 3), and the GNU FDL (versions 1.2 or 1.3)
+ should refer to the corresponding files
+ under <file>/usr/share/common-licenses</file>,<footnote>
<p>
In particular,
- <file>/usr/share/common-licenses/BSD</file>,
<file>/usr/share/common-licenses/Apache-2.0</file>,
<file>/usr/share/common-licenses/Artistic</file>,
<file>/usr/share/common-licenses/GPL-2</file>,
<file>/usr/share/common-licenses/LGPL-3</file>,
<file>/usr/share/common-licenses/GFDL-1.2</file>, and
<file>/usr/share/common-licenses/GFDL-1.3</file>
- respectively.
+ respectively. The University of California BSD license is
+ also included in <package>base-files</package> as
+ <file>/usr/share/common-licenses/BSD</file>, but given the
+ brevity of this license, its specificity to code whose
+ copyright is held by the Regents of the University of
+ California, and the frequency of minor wording changes, its
+ text should be included in the copyright file rather than
+ referencing this file.
</p>
</footnote> rather than quoting them in the copyright
file.
</p>
<p>
- The maintainer scripts are guaranteed to run with a
- controlling terminal and can interact with the user.
- See <ref id="controllingterminal">.
+ The maintainer scripts are not guaranteed to run with a
+ controlling terminal and may not be able to interact with
+ the user. See <ref id="controllingterminal">.
</p>
</item>
</sect>
<sect id="pkg-sourcetree">
- <heading>The Debianised source tree</heading>
+ <heading>The Debian package source tree</heading>
<p>
The source archive scheme described later is intended to
- allow a Debianised source tree with some associated control
- information to be reproduced and transported easily. The
- Debianised source tree is a version of the original program
- with certain files added for the benefit of the
- Debianisation process, and with any other changes required
+ allow a Debian package source tree with some associated
+ control information to be reproduced and transported easily.
+ The Debian package source tree is a version of the original
+ program with certain files added for the benefit of the
+ packaging process, and with any other changes required
made to the rest of the source code and installation
scripts.
</p>
<p>
The extra files created for Debian are in the subdirectory
- <file>debian</file> of the top level of the Debianised source
- tree. They are described below.
+ <file>debian</file> of the top level of the Debian package
+ source tree. They are described below.
</p>
<sect1 id="pkg-debianrules">
</item>
<tag>
- Debianisation diff -
+ Debian package diff -
<file>
<var>package</var>_<var>upstream_version-revision</var>.diff.gz
</file>
<item><p>Apply the diff using <tt>patch -p0</tt>.</p>
</item>
<item><p>Untar the tarfile again if you want a copy of the original
- source code alongside the Debianised version.</p>
+ source code alongside the Debian version.</p>
</item>
</enumlist>
<p>
The source packaging tools manage the changes between the
- original and Debian
ised source using <prgn>diff</prgn> and
+ original and Debian source using <prgn>diff</prgn> and
<prgn>patch</prgn>. Turning the original source tree as
- included in the <file>.orig.tar.gz</file> into the debianised
- source must not involve any changes which cannot be
+ included in the <file>.orig.tar.gz</file> into the Debian
+ package source must not involve any changes which cannot be
handled by these tools. Problematic changes which cause
<prgn>dpkg-source</prgn> to halt with an error when
building the source package are:
projects / debian / debian-policy.git / blobdiff