Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
I have re-read the discussion, and I think some points raised are valid.
I'm hereby changing my proposal.
The proposal has been seconded by Edward Betts <edward@debian.org>.
I need his support for these changes, or a second from someone else.
And I'm still looking for another second.
Summary of the changes:
- The fields change as follows:
Depends -> Build-Depends
Arch-Depends (removed as suggested by Roman Hodek)
Indep-Depends -> Build-Indep-Depends
Conflicts -> Build-Conflicts
Arch-Conflicts (removed as suggested by Roman Hodek)
Indep-Conflicts -> Build-Indep-Conflicts
(The rename suggested by Steve Greenland)
- The syntax of the fields is explicitly mentioned to be
identical to binary Depends et al. Mentioning redundant
packages is explicitly discouraged. Strict versioning
for -dev packages must be used.
(Suggested by Roman Hodek.)
The following suggestions will NOT be part of this proposal. They may
be proposed separately if necessary.
- Dependencies to source packages will not be supported.
The only solution offered would break the declarative
semantics of the control files, making them partly
imperative. This is bad, because you would not be able
to write both dependency *testers* and dependency *satisfiers*
based on the suggested dependency information. (Satisfier
meaning an apt-like entity which installs required packages
and symlinks.)
(Suggestion by Roman Hodek.)
- Per-binary build-time dependencies will not be supported.
There is no way to control the Debian build system
in per-package basis, so per-package build-time dependencies
would serve no useful purpose while, as noted by Roman Hodek,
they do make parsing the dependencies harder.
(Suggestion by Joey Hess.)
- The current list of build-essential packages will not be
included as a footnote to the Policy Manual. Try to
generate it yourself and you shall understand why -
it would way too long.
(Suggestion by Santiago Vila.)
I thank everybody who have taken part in the discussion.
The updated policy diffs are included below.
--- policy.sgml.old Tue Jul 13 21:13:28 1999
+++ policy.sgml Fri Jul 23 18:45:36 1999
@@ -929,6 +929,53 @@
release it.</p></sect1>
+ <sect1>
+ <heading>Dependencies</heading>
+
+ <p>
+ Source packages must specify which binary packages they
+ require to be installed or not to be installed in order to
+ build correctly.
+ </p>
+
+ <p>
+ For example, if building a package requires a certain
+ compiler, then the compiler must be specified as a build-time
+ dependency.
+ </p>
+
+ <p>
+ It is not necessary for a source package to specify
+ dependencies on the following packages (which will
+ be referred to as "build-essential packages"): packages which are
+ marked <tt>Essential</tt>; packages with the priority
+ <tt>required</tt>; the <tt>dpkg-dev</tt> and <tt>make</tt>
+ packages; and packages which are required for compiling
+ and linking a minimal "Hello World" program written in C
+ or C++. Runtime library packages should not normally be
+ specified in source dependencies.
+ </p>
+
+ <p>
+ When specifying the set of build-time dependencies, one
+ should list only those packages explicitly required
+ by the build. It is not necessary to list packages
+ which are required merely because some other package
+ in the list of build-time dependencies depends on them.
+ The reason is that dependencies change, and you should
+ list only those <em/you/ need. What others need
+ is their business.
+ </p>
+
+ <p>
+ Build-time dependencies on library development packages
+ must be tightly versioned so that when build-time
+ dependencies are satisfied at build-time, the resulting
+ binary package will end up with the same set of
+ dependencies at every build. In other words, all shared
+ library packages installable with allowed -dev packages
+ must have an equivalent shlibs file.
+
<sect1>
<heading>Changes to the upstream sources</heading>
--- packaging.sgml.old Tue Jul 13 21:01:41 1999
+++ packaging.sgml Fri Jul 23 18:54:26 1999
@@ -1193,6 +1193,12 @@
</item>
<item>
<p>
+ <qref id="relationships"><tt>Build-Depends</tt> at
+ al.</qref> (source package interrelationships)
+ </p>
+ </item>
+ <item>
+ <p>
<qref id="f-Standards-Version"><tt>Standards-Version</tt></qref>
</p>
</item>
@@ -1223,7 +1229,7 @@
<item>
<p>
<qref id="relationships"><tt>Depends</tt> et
- al.</qref> (package interrelationships)
+ al.</qref> (binary package interrelationships)
</p>
</item>
</list>
@@ -1661,6 +1667,12 @@
<item>
<p><qref id="f-Architecture"><tt>Architecture</tt></qref></p>
</item>
+ <item>
+ <p>
+ <qref id="relationships"><tt>Build-Depends</tt> et
+ al.</qref> (source package interrelationships)
+ </p>
+ </item>
<item>
<p>
<qref id="f-Standards-Version"><tt>Standards-Version</tt></qref></p>
@@ -3518,7 +3530,23 @@
<p>
This is done using the <tt>Depends</tt>, <tt>Recommends</tt>,
<tt>Suggests</tt>, <tt>Conflicts</tt>, <tt>Provides</tt> and
- <tt>Replaces</tt> control file fields.
+ <tt>Replaces</tt> control file fields, when they appear in the
+ context of binary packages (eg. in a per-binary paragraph of
+ debian/control).
+ </p>
+
+ <p>
+ Source packages may declare relationships to binary packages,
+ saying that they require certain binary packages being
+ installed or absent at the time of building the package.
+ <p>
+
+ <p>
+ This is done using the <tt>Build-Depends</tt>,
+ <tt>Build-Indep-Depends</tt>, <tt>Build-Conflicts</tt>, and
+ <tt>Build-Indep-conflicts</tt> control file fields, when they
+ appear in the context of source packages (eg. in the general
+ package of debian/control).
</p>
<sect id="depsyntax"><heading>Syntax of relationship fields
@@ -3530,10 +3558,11 @@
</p>
<p>
- In <tt>Depends</tt>, <tt>Recommends</tt>, <tt>Suggests</tt>
- and <tt>Pre-Depends</tt> (the fields which declare
- dependencies of the package in which they occur on other
- packages) these package names may also be lists of
+ In <tt>Depends</tt>, <tt>Build-Depends</tt>,
+ <tt>Build-Indep-Depends</tt>, <tt>Recommends</tt>,
+ <tt>Suggests</tt> and <tt>Pre-Depends</tt> (the fields which
+ declare dependencies of the package in which they occur on
+ other packages) these package names may also be lists of
alternative package names, separated by vertical bar symbols
<tt>|</tt> (pipe symbols).
</p>
@@ -3580,7 +3609,7 @@
</p>
</sect>
- <sect><heading>Dependencies - <tt>Depends</tt>, <tt>Recommends</tt>,
+ <sect><heading>Binary Dependencies - <tt>Depends</tt>, <tt>Recommends</tt>,
<tt>Suggests</tt>, <tt>Pre-Depends</tt>
</heading>
@@ -3818,12 +3847,12 @@
</p>
</sect1>
- <sect id="conflicts"><heading>Alternative packages -
+ <sect id="conflicts"><heading>Alternative binary packages -
<tt>Conflicts</tt> and <tt>Replaces</tt>
</heading>
<p>
- When one package declares a conflict with another
+ When one binary package declares a conflict with another
<prgn>dpkg</prgn> will refuse to allow them to be installed
on the system at the same time.
</p>
@@ -3882,11 +3911,13 @@
<sect id="virtual"><heading>Virtual packages - <tt>Provides</tt>
</heading>
- <p>
- As well as the names of actual (`concrete') packages, the
- package relationship fields <tt>Depends</tt>,
- <tt>Recommends</tt>, <tt>Suggests</tt> and
- <tt>Conflicts</tt> may mention virtual packages.
+ <p>
+ As well as the names of actual (`concrete') packages, the
+ package relationship fields <tt>Depends</tt>,
+ <tt>Build-Depends</tt>, <tt>Build-Indep-depends</tt>,
+ <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Conflicts</tt>,
+ <tt>Build-Conflicts</tt> and <tt>Build-Indep-Conflicts</tt> may
+ mention virtual packages.
</p>
<p>
@@ -4080,6 +4111,47 @@
lightweight standalone info browser.
</p>
</sect>
+
+ <sect><heading>Relationships between source and binary packages -
+ <tt>Build-Depends</tt>, <tt>Build-Indep-Depends</tt>,
+ <tt>Build-Conflicts</tt>, <tt>Build-Indep-Conflicts</tt>
+ </heading>
+
+ <p>
+ A source package may declare a dependency or a conflict on a
+ binary package. This is done with the control file fields
+ <tt>Build-Depends</tt>, <tt>Build-Indep-Depends</tt>,
+ <tt>Build-Conflicts</tt>, and <tt>Indep-Conflicts</tt>. Their
+ semantics is that the dependencies and conflicts they define
+ must be satisfied (as defined earlier for binary packages),
+ when one of the targets in <tt>debian/rules</tt> that the
+ particular field applies to is invoked.
+
+ <taglist>
+ <tag><tt>Build-Depends</tt>, <tt>Build-Conflicts</tt></tag>
+ <item>
+ <p>
+ The <tt>Build-Depends</tt> and <tt>Build-Conflicts</tt> fields apply
+ to the targets
+ <tt>build</tt>, <tt>binary</tt>, <tt>binary-arch</tt>
+ and <tt>binary-indep</tt>.
+ </p>
+ </item>
+ <tag><tt>Build-Indep-Depends</tt>, <tt>Build-Indep-Conflicts</tt></tag>
+ <item>
+ <p>
+ The <tt>Build-Indep-Depends</tt> and
+ <tt>Build-Indep-Conflicts</tt> fields apply to the targets
+ <tt>build</tt>, <tt>binary</tt> and
+ <tt>binary-indep</tt>.
+ </p>
+ </item>
+ </taglist>
+
+ </p>
+
+ </sect>
+
</chapt>
<chapt id="conffiles"><heading>Configuration file handling
--
%%% Antti-Juhani Kaijanaho % gaia@iki.fi % http://www.iki.fi/gaia/ %%%
"... memory leaks are quite acceptable in many applications ..."
(Bjarne Stroustrup, The Design and Evolution of C++, page 220)
Reply to: