Bug#41232: AMENDMENT 1999-07-23 FINAL DRAFT] Build-time dependencies on binary packages
On Sat, Aug 07, 1999 at 02:18:41AM +0300, Antti-Juhani Kaijanaho wrote:
> Thus the discussion should end on Friday, the 13th of this month.
This deadline is almost at hand. I've produced a final draft of the
amendment for your review. Consider it frozen: i will not make any
substantial changes to it anymore - only simple thinkos and typos will
be corrected. I hope we can get a consensus to back this amendment;
otherwise, we'll have to reject it. (There will of course be the option
of starting a new proposal with new seconds and a new discussion period.)
> To concentrate the remaining discussion on the matters at hand, I'll
> summarise the points of disagreement and add my comments.
I'll summarise my final positions on those issues here, as they are
resolved in the draft.
> * Are Build-Conflicts really necessary?
Yes.
> * Do we need to conditionalize the build dependencies based
> on architectures?
Yes. Conditionalisation is supported based on host architecture. If it
is necessary, a separate amendment can establish a way to conditionalise
based on build architecture.
> * If so, what syntax should we use?
I've chosen the "package (>= 42) [i386 !hurd-i386]" syntax. It's
moderately non-intrusive, and the separate parenthetical forms emphasize
the difference between the two add-ons: the version specification narrows
the relationship, the architecture specification conditionalises it.
Commas are not allowed as separators, as that would needlessly compilcate
parsers.
The set definition syntax is simple but AFAICS expressible enough. If
fancier syntaxes (such as [hurd-*]) are needed, they can be introduced
in a separate amendment.
> * Should we use four fields or six fields?
Four.
> * When are versioned dependencies necessary?
Every time not using them would result in bad or inconsistently configured
packages.
This amendment contains a couple of other modifications that have either
been discussed and agreed on earlier or that merely enhance the language.
This amendment will not introduce build-recommendations or
build-suggestions. They can be introduced in a separate amendment.
Here are the diffs against policy and packaging manual version 3.0.1.0:
--- policy.sgml.orig Thu Aug 12 03:36:37 1999
+++ policy.sgml Thu Aug 12 03:58:13 1999
@@ -932,6 +932,51 @@
release it.</p></sect1>
+ <sect1>
+ <heading>Package relationships</heading>
+
+ <p>
+ Source packages must specify which binary packages they
+ require to be installed or not to be installed in order to
+ build correctly. For example, if building a package
+ requires a certain compiler, then the compiler must be
+ specified as a build-time dependency.
+ </p>
+
+ <p>
+ It will not be necessary to explicitly specify build-time
+ relationships on a minimal set of packages that are always
+ needed to compile, link and put in a Debian package a
+ standard "Hello World!" program written in C or C++. The
+ required packages are called <em/build-essential/, and an
+ informational list will be published separately from this
+ document.
+ </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>
+ It is a bug if, after unpacking a source package on a
+ system with the build-essential packages installed and
+ satisfying the build-time relationships (including the
+ implied relationships), one cannot build the package and
+ produce a working binary package suitable for installation
+ into the binary distribution corresponding to the source
+ distribution which contained the source package. This
+ means in particular that version clauses should be used
+ rigorously in build-time relationships so that one cannot
+ produce bad or inconsistently configured packages when the
+ relationships are properly satisfied.
+ </p>
+
<sect1>
<heading>Changes to the upstream sources</heading>
--- packaging.sgml.orig Thu Aug 12 03:36:40 1999
+++ packaging.sgml Thu Aug 12 04:23:00 1999
@@ -1191,6 +1191,12 @@
(classification, mandatory)
</p>
</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>
@@ -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>
@@ -3521,6 +3533,18 @@
<tt>Replaces</tt> control file fields.
</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-Depends-Indep</tt>, <tt>Build-Conflicts</tt>, and
+ <tt>Build-Conflicts-Indep</tt> control file fields.
+ </p>
+
<sect id="depsyntax"><heading>Syntax of relationship fields
</heading>
@@ -3529,13 +3553,13 @@
package names separated by commas.
</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
- alternative package names, separated by vertical bar symbols
- <tt>|</tt> (pipe symbols).
+ <p> In <tt>Depends</tt>, <tt>Recommends</tt>,
+ <tt>Suggests</tt>, <tt>Pre-Depends</tt>,
+ <tt>Build-Depends</tt> and <tt>Build-Depends-Indep</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>
<p>
@@ -3578,9 +3602,37 @@
Depends: libc5 (>= 5.2.18-4), mime-support, csh | tcsh
</example>
</p>
+
+ <p>
+ All fields that specify build-time relationships
+ (<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
+ <tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt>)
+ may be restricted to a certain set of architectures. This
+ is done in brackets after each individual package name and
+ the optional version specification. The brackets enclose a
+ list of Debian architecture names separated by whitespace.
+ An exclamation mark may be prepended to each name. If the
+ current Debian host architecture is not in this list, or it
+ is in the list with a prepended exclamation mark, the
+ package name and the associated version specification are
+ ignored completely for the purposes of defining the
+ relationships.
+ </p>
+
+ <p>
+ For example:
+ <example>
+ Source: glibc
+ Build-Depends-Indep: texinfo
+ Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
+ hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
+ </example>
+ </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 +3870,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 +3934,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-Depends-Indep</tt>,
+ <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Conflicts</tt>,
+ <tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt> may
+ mention virtual packages.
</p>
<p>
@@ -4080,8 +4134,49 @@
lightweight standalone info browser.
</p>
</sect>
- </chapt>
+
+ <sect><heading>Relationships between source and binary packages -
+ <tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
+ <tt>Build-Conflicts</tt>, <tt>Build-Conflicts-Indep</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-Depends-Indep</tt>,
+ <tt>Build-Conflicts</tt>, and <tt>Build-Conflicts-Indep</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-Depends-Indep</tt>, <tt>Build-Conflicts-Indep</tt></tag>
+ <item>
+ <p>
+ The <tt>Build-Depends-Indep</tt> and
+ <tt>Build-Conflicts-Indep</tt> fields apply to the
+ targets <tt>binary</tt> and <tt>binary-indep</tt>.
+ </p>
+ </item>
+ </taglist>
+
+ </p>
+
+ </sect>
+
+
+ </chapt>
<chapt id="conffiles"><heading>Configuration file handling
</heading>
--
%%% 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: