Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Package: debian-policy
Version: 3.0.0.0
Severity: wishlist
This is a long mail. Bear with me, and read at least the summary (section
2). This mail is also available at
<URL: http://master.debian.org/~ajk/proposal.txt >
1) Introduction
We've been kicking around the idea of build-time dependencies (aka
source dependencies) for years. When I studied the mail archives on
the history, I found that many proposals had been made, some went
unnoticed, some created much discussion. The build bot people have a
partial solution of their own. Yet, we still don't have a general way
of specifying these dependencies in our packages.
In this proposal, I intend to introduce a method by which a package
maintainer can specify which packages must be installed at the time of
building the package in question. I hope that this time we'll
succeed.
Many people want to take a bold step forward and have a system that
automatically finds out what the build-time dependencies are. This
proposal is much more modest. I just want a standardised way of
specifying the build-time dependencies.
This proposal does not deal with the fact that some packages need to
have particular *source* packages unpacked and even perhaps partially
built at the time of a build. Those issues are more complex and
requires more study - perhaps the sbuild folks who have dealt with
them can offer a solution?
2) Summary
My proposal is, in short, the following: Define six new fields for
debian/control and specify their meaning. The six new fields are used
only in .dsc files and in the first paragraph of debian/control. They
are:
* Depends
Specifies the packages that must be installed when one of
the targets build, binary, binary-arch and binary-indep
of debian/rules is invoked.
* Arch-Depends
This is a variant of Depends which is followed only when
the architecture-dependent parts of the package are being
built.
* Indep-Depends
This is a variant of Depends which is followed only when
the architecture-independent parts of the package are being
built.
* Conflicts, Arch-Conflicts, Indep-Conflicts
These are analoguous to the dependency fields above.
Most packages will use only Depends and Conflicts. The other fields
are useful with multi-binary packages.
It will not be necessary to specify "Essential: yes" or "Priority:
required" packages, nor is it necessary to specify a minimal standard
C and C++ compilation environment. The dpkg-dev package is also
assumed to be installed. Helper packages such as debhelper, if any,
*must* be specified.
3) Motivation and impact
The sbuild people already have a working source dependency mechanism.
It has one flaw, however. It needs a central repository of dependency
information, and the way to inform that repository of changes in
packaging is not well known. This proposal remedies this by defining
a way for package maintainers to define and maintain this information
in their own packages, and for the build bots to automatically extract
this information from the packages.
Why six fields, why not two, you ask. My answer is that the build
bots generally build only architecture-specific packages, and a
multi-binary package can also contain architecture-independent
packages. It would be waste of resources to require the porters to
install packages which are only needed to build arch: all packages.
This proposal requires very little changes to any programs. Dpkg
needs to be changed a little, so that the new fields get propagated
from debian/control to .dsc files at source build time. Build bots
will want to change their ways so that they extract (part of) their
dependency information from the new fields. And one would wish that
dpkg-buildpackage checked the dependencies before doing a build, but
this is not required for this proposal to go forward.
I will send the dpkg folks a diff which implements the only mandatory
change. I also have a half-finished patch for dpkg-buildpackage
implementing the dependency check; I will submit it when it's ready.
The proposal, if accepted, will affect most Debian packages in terms
of changes to Policy.
4) The proposal
I propose those changes to the Policy Manual and to the Packaging
Manual that are given in the diffs attached to this mail.
I am now looking for seconds to this proposal.
--- policy.sgml.old Tue Jul 13 21:13:28 1999
+++ policy.sgml Tue Jul 13 21:34:45 1999
@@ -929,6 +929,32 @@
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: 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>
+
<sect1>
<heading>Changes to the upstream sources</heading>
--- packaging.sgml.old Tue Jul 13 21:01:41 1999
+++ packaging.sgml Tue Jul 13 21:03:48 1999
@@ -1193,6 +1193,12 @@
</item>
<item>
<p>
+ <qref id="relationships"><tt>Depends</tt> at
+ al.</qref> (source package interrelationships)
+ </p>
+ </item>
+ <item>
+ <p>
<qref id="f-Standards-Version"><tt>Standards-Version</tt></qref>
</p>
</item>
@@ -1661,6 +1667,12 @@
<item>
<p><qref id="f-Architecture"><tt>Architecture</tt></qref></p>
</item>
+ <item>
+ <p>
+ <qref id="relationships"><tt>Depends</tt> et
+ al.</qref> (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>Depends</tt>, <tt>Arch-depends</tt>,
+ <tt>Indep-depends</tt>, <tt>Conflicts</tt>, <tt>Arch-conflicts</tt>
+ and <tt>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,7 +3558,8 @@
</p>
<p>
- In <tt>Depends</tt>, <tt>Recommends</tt>, <tt>Suggests</tt>
+ In <tt>Depends</tt>, <tt>Arch-Depends</tt>, <tt>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
@@ -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>Arch-Depends</tt>, <tt>Indep-depends</tt>,
+ <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Conflicts</tt>,
+ <tt>Arch-Conflicts</tt> and <tt>Indep-Conflicts</tt> may
+ mention virtual packages.
</p>
<p>
@@ -4080,6 +4111,58 @@
lightweight standalone info browser.
</p>
</sect>
+
+ <sect><heading>Relationships between source and binary packages -
+ <tt>Depends</tt>, <tt>Arch-Depends</tt>, <tt>Indep-Depends</tt>,
+ <tt>Conflicts</tt>, <tt>Arch-Conflicts</tt>, <tt>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>Depends</tt>, <tt>Arch-Depends</tt>,
+ <tt>Indep-Depends</tt>, <tt>Conflicts</tt>,
+ <tt>Arch-Conflicts</tt> and <tt>Indep-Conflicts</tt>, when
+ they appear in the context of a source package. Of course,
+ some of the fields may not appear in other contexts. 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>Depends</tt>, <tt>Conflicts</tt></tag>
+ <item>
+ <p>
+ The <tt>Depends</tt> and <tt>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>Arch-Depends</tt>, <tt>Arch-Conflicts</tt></tag>
+ <item>
+ <p>
+ The <tt>Arch-Depends</tt> and <tt>Arch-Conflicts</tt>
+ fields apply to the targets <tt>build</tt>,
+ <tt>binary</tt> and <tt>binary-arch</tt>.
+ </p>
+ </item>
+ <tag><tt>Indep-Depends</tt>, <tt>Indep-Conflicts</tt></tag>
+ <item>
+ <p>
+ The <tt>Indep-Depends</tt> and
+ <tt>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: