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
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>
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
- 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.
+ 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>
<tt>Conflicts</tt> should be used
<list>
<item>when two packages provide the same file and will
- continue to do so (but be aware that this is often an error
- that should be fixed rather than using <tt>Conflicts</tt> --
- see, for example, <ref id="binaries">),</item>
+ 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>
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>
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 which package which provides
- 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>
+ 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,
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 required in addition
- to <tt>Provides</tt>, consider the
- case of a file in the package <package>foo</package> being
-
taken over by the package <package>foo-data</package>.
+ 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
<example compact="compact">
Replaces: foo (<< 1.2-3)
Breaks: foo (<< 1.2-3)
- </example compact="compact">
+ </example>
in its control file. The new version of the
package <package>foo</package> would normally have the field
- <example>
+ <example compact="compact">
Depends: foo-data (>= 1.2-3)
</example>
(or possibly <tt>Recommends</tt> or even <tt>Suggests</tt> if
<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>
</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