Your message dated Sat, 6 Nov 1999 21:13:58 +0000 (GMT) with message-id <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED] [195.74.24.105]) by ds9.sci.fi (8.9.1/8.9.1) with ESMTP id WAA24723 for <[EMAIL PROTECTED]>; 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 <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: debian-policy: [PROPOSAL] Build-time dependencies on binary packages Message-ID: <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Sender: Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> 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 % [EMAIL PROTECTED] % 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: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] 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: <[EMAIL PROTECTED]> From: Julian Gilbey <[EMAIL PROTECTED]> These bugs have been fixed in debian-policy 3.1.0.0; changelog follows. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] 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