Bug#41232: marked as done ([ACCEPTED] Build-time dependencies on binary packages)
Your message dated Sat, 6 Nov 1999 21:13:58 +0000 (GMT)
with message-id <E11kD9q-0000Vf-00@polya>
and subject line Fixed in debian-policy 3.1.0.0
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Darren Benham
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 13 Jul 1999 19:16:20 +0000
Received: (qmail 17429 invoked from network); 13 Jul 1999 19:16:19 -0000
Received: from ds9.sci.fi (195.74.0.54)
by master.debian.org with SMTP; 13 Jul 1999 19:16:19 -0000
Received: from ugh.jyu.fi.invalid (mail@gaia.pp.sci.fi [195.74.24.105])
by ds9.sci.fi (8.9.1/8.9.1) with ESMTP id WAA24723
for <submit@bugs.debian.org>; Tue, 13 Jul 1999 22:16:20 +0300 (EET DST)
Received: from ajk by ugh.jyu.fi.invalid with local (Exim 3.02 #1 (Debian))
id 11485K-0004u6-00; Tue, 13 Jul 1999 22:19:22 +0300
Date: Tue, 13 Jul 1999 22:19:21 +0300
From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: submit@bugs.debian.org
Subject: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Message-ID: <19990713221921.S29829@ugh.jyu.fi.invalid>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
Sender: Antti-Juhani Kaijanaho <antkaij@st.jyu.fi>
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)
---------------------------------------
Received: (at 41232-done) by bugs.debian.org; 6 Nov 1999 21:31:44 +0000
Received: (qmail 17140 invoked from network); 6 Nov 1999 21:15:11 -0000
Received: from mserv1c.u-net.net (195.102.240.33)
by master.debian.org with SMTP; 6 Nov 1999 21:15:11 -0000
Received: from [195.102.196.44] (helo=polya)
by mserv1c.u-net.net with esmtp (Exim 2.10 #35)
id 11kD9x-0005Qp-00; Sat, 6 Nov 1999 21:14:05 +0000
Received: from jdg by polya with local (Exim 3.03 #1 (Debian))
id 11kD9q-0000Vf-00; Sat, 06 Nov 1999 21:13:58 +0000
Subject: Fixed in debian-policy 3.1.0.0
To: 8221-done@bugs.debian.org, 17621-done@bugs.debian.org,
19179-done@bugs.debian.org, 24695-done@bugs.debian.org,
32448-done@bugs.debian.org, 32449-done@bugs.debian.org,
33076-done@bugs.debian.org, 40766-done@bugs.debian.org,
40767-done@bugs.debian.org, 41095-done@bugs.debian.org,
41121-done@bugs.debian.org, 41232-done@bugs.debian.org,
41547-done@bugs.debian.org, 41829-done@bugs.debian.org,
42358-done@bugs.debian.org, 42447-done@bugs.debian.org,
42849-done@bugs.debian.org, 43651-done@bugs.debian.org,
44620-done@bugs.debian.org, 44643-done@bugs.debian.org,
44922-done@bugs.debian.org, 45307-done@bugs.debian.org,
45318-done@bugs.debian.org, 45561-done@bugs.debian.org,
46516-done@bugs.debian.org, 48570-done@bugs.debian.org
Date: Sat, 6 Nov 1999 21:13:58 +0000 (GMT)
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <E11kD9q-0000Vf-00@polya>
From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>
These bugs have been fixed in debian-policy 3.1.0.0; changelog follows.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Changes: debian-policy (3.1.0.0) unstable; urgency=low
.
* Add instructions on /usr/doc -> /usr/share/doc symlinks (closes:
#45561, #42447, #48570)
* Added source dependencies (closes: #41232)
* Deprecated /etc/rc.boot (closes: #32448, #32449)
* Update-rc.d now only legal way to automatically access /etc/rc?.d
directoried (closes: #41547)
* FHS compliant location of examples (closes: #42849)
* Added ispell-dictionary to virtual-packages.list (following new
suggestions: no objections => accept) (closes: #8221)
* Added man-browser to virtual-packages.list (closes: #24695)
* Added ident-server to virtual-packages.list (closes: #45307)
* Alphabeticised virtual packages list ;)
* Corrected GPL reference in proposal.sgml
* Clarification of "extra" priority (closes: #33076)
* Remove buggy and seriously problematic licenses from list of contrib
package criteria (closes: #45318)
* Move docs to /usr/share/doc with a compatibility symlink (closes:
#41829)
* Update to FHS 2.1 draft #3 (for /var/state etc. changes).
* Correct /var/lib/games -> /var/games (closes: #42358)
* Added MIME subpolicy (closes: #46516)
* Added support for VISUAL (closes: #41121)
* Clarify non-dependence on /usr/local (closes: #44922)
* Modified description of mail spool locking (closes: #43651)
* Clarified wording of conffiles and configuration files (closes:
#40766, #40767)
* Changed description of release numbers (closes: #44620)
* Added changelog.html -> changelog requirement (closes: $40934)
* packaging-manual now correctly installs its docs (closes: #44643)
* The packaging manual now discusses version numbers based on dates
(closes: #17621)
* Mention ls -f for testing order in which files appear on disk (closes:
#19179)
* Change order of '.' and '+' in description of version numbers (closes:
#41095)
* s/fields/field names/ in section 4.1 of packaging manual for clarity
* Add Build-Depends-Indep: field to control file
Reply to: