Debian Bug report logs - #41232
[ACCEPTED] Build-time dependencies on binary packages

version graph

Package: debian-policy; Maintainer for debian-policy is Debian Policy List <debian-policy@lists.debian.org>; Source for debian-policy is src:debian-policy.

Reported by: Antti-Juhani Kaijanaho <gaia@iki.fi>

Date: Tue, 13 Jul 1999 19:18:01 UTC

Severity: fixed

Found in versions 3.0.0.0, 1.4.1.4

Fixed in version debian-policy/3.1.0.0

Done: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

Bug is archived. No further changes may be made.

Forwarded to debian-policy@lists.debian.org

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
New bug report received and forwarded. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: submit@bugs.debian.org
Subject: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Tue, 13 Jul 1999 22:19:21 +0300
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)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Adam Heath <doogie@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #10 received at submit@bugs.debian.org (full text, mbox):

From: Adam Heath <doogie@debian.org>
To: Antti-Juhani Kaijanaho <gaia@iki.fi>, 41232@bugs.debian.org
Cc: submit@bugs.debian.org, debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Wed, 14 Jul 1999 01:44:46 -0500 (CDT)
On Tue, 13 Jul 1999, Antti-Juhani Kaijanaho wrote:

Look good, except for one thing.  How would you handle the case where
debian/control is generated from debian/control.in?  dpkg-buildpackage would
not be able to check for dependencies in this case, until control is
generated, but you can't call debian/rules to build control until you have
checked dependencies.  A typical chicken/egg problem.

Adam




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Adam Heath <doogie@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #20 received at 41232@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: Adam Heath <doogie@debian.org>, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Wed, 14 Jul 1999 12:12:58 +0300
On Wed, Jul 14, 1999 at 01:44:46AM -0500, Adam Heath wrote:
> Look good, except for one thing.  How would you handle the case where
> debian/control is generated from debian/control.in?

A source package is required to have a valid debian/control after unpack.
Although the Packaging Manual does not explicitly say this, the intent is
nevertheless clear - and dpkg-source will not build a source package without
a control file (if it's not called debian/control, dpkg-source needs to be
told about the real name).

-- 
%%% 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)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #25 received at 41232@bugs.debian.org (full text, mbox):

From: Santiago Vila <sanvila@unex.es>
To: Adam Heath <doogie@debian.org>
Cc: 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Wed, 14 Jul 1999 12:03:42 +0200 (CET)
On Wed, 14 Jul 1999, Adam Heath wrote:

> On Tue, 13 Jul 1999, Antti-Juhani Kaijanaho wrote:
> 
> Look good, except for one thing.  How would you handle the case where
> debian/control is generated from debian/control.in?

The usual debian/control file is already some sort of "control.in", since
it uses variables (like ${shlibs:Depends}) which get replaced by their
real values at build time.

Is there any control.in file which may not be rewritten so that it uses
the "usual" variables mechanism?

In other words: Does the packaging system support all our current needs
for generating real control files? (i.e. those in debian/tmp/DEBIAN)

-- 
 "47123eb94aeb76c5e9debc390f65ec00" (a truly random sig)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #30 received at 41232@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Wed, 14 Jul 1999 17:15:27 +0300
On Wed, Jul 14, 1999 at 03:20:34PM +0200, Roman Hodek wrote:
> Just one note: Arch-{Depends,Conflicts} might be unnecessary, as it
> should be very rare that someone only builds the arch-indep packages.
> So we could merge Arch-Depends into Depends. If one compiles with
> dpkg-buildpackage -B, he needs to look only at Depends.
> dpkg-buildpackage without -B needs to look at Depends + Indep-Depends.

This sounds doable.  Any opinions?

> For my current system I have defined the following packages as
> build-essential:

I wanted to avoid naming specific packages in Policy (I only named two in
the proposal, make and dpkg-dev), since packages change and it would be a
pain in the rear to change policy every time GNU Libc changes name, for
example.

>   Depends-Sourcetree: tcl8.0 ("ln -s tcl8.0-* tcl8.0; cd tcl8.0; ./configure --prefix=/usr")

I want to keep this proposal as clean as possible; I don't want to see this
kind of kluging in it if at all possible. My intent is to let this proposal
to handle the majority cases.  The tough minority will need to be dealt with
separately (for example, by using your central dependencies forever for
these packages).

In my opinion, we should ban dependencies on source packages in the Policy
(although I'm not proposing that yet).

>  - The source dependencies can be specified the same way as normal
>    (binary) dependencies, i.e. you can depend on virtual packages,
>    alternatives, and you can specify version relations.

I tried to phrase the proposal (ie the diff) so that this would be true.
Did I fail?

>  - You don't need to specify packages that are dependencies of another
>    package that is already a source dependency, provided that nothing
>    is used explicitly from the first package.

Agreed.  Do you want to write the language for the Policy?  I'll accept it
as a part of this proposal, if you do.

>  - If a dependency on a -dev package is given, it must be a versioned
>    dependency if needed to ensure that the resulting (binary)
>    dependencies of built packages are unchanged.

Again, can you suggest a wording?

-- 
%%% 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)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #35 received at 41232@bugs.debian.org (full text, mbox):

From: Santiago Vila <sanvila@unex.es>
To: Antti-Juhani Kaijanaho <gaia@iki.fi>, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Wed, 14 Jul 1999 17:59:26 +0200 (CET)
On Tue, 13 Jul 1999, Antti-Juhani Kaijanaho wrote:

> +          <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.

Small comment: I like the informal way the "build-essential" packages are
described. However, for practical reasons, it would help to specify
also which ones they are at a given time. For example:

[...] and packages which are required for compiling and linking a minimal
"Hello World" program written in C or C++ (currently the following ones:
binutils, libc6-dev, gcc, [...]).

The idea would be to provide a real list, but also the rationale from
which the list is derived, so that whenever the list of build-essential
packages change, we just update policy accordingly, without changing the
spirit of it. How does this sound?


BTW: You mention both "Essential: yes" packages and "Priority: required" 
packages as the basis for the build-essential packages. Would not be
easier to specify just "Priority: required", or do you want dependencies
on, say, Essential packages of extra priority not to be specified?

Thanks.

-- 
 "10b71a6acfe945c43349f1765089edfe" (a truly random sig)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Edward Betts <edward@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #40 received at 41232@bugs.debian.org (full text, mbox):

From: Edward Betts <edward@debian.org>
To: 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Wed, 14 Jul 1999 14:58:54 +0100
[Message part 1 (text/plain, inline)]
Antti-Juhani Kaijanaho <gaia@iki.fi> wrote:
> 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.

Seconded.

-- 
I consume, therefore I am
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #45 received at 41232@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: Santiago Vila <sanvila@unex.es>, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Wed, 14 Jul 1999 19:25:01 +0300
On Wed, Jul 14, 1999 at 05:59:26PM +0200, Santiago Vila wrote:
> The idea would be to provide a real list, but also the rationale from
> which the list is derived, so that whenever the list of build-essential
> packages change, we just update policy accordingly, without changing the
> spirit of it. How does this sound?

I don't like the idea of going through the Policy change procedure every
time we move something in or out of the required class.  IMHO a list is good
to have, but I'd like more to see it as a separate document, with only
informative status and no weight of policy (so that when these two disagree,
it's the definition in policy which is followed).

> Would not be easier to specify just "Priority: required"

Possibly.  I was under the impression that Essential: yes packages are
guaranteed to be there in every Debian system, regardless of their priority.

> on, say, Essential packages of extra priority not to be specified?

Do we have such packages in the current distributions?

-- 
%%% 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)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #50 received at 41232@bugs.debian.org (full text, mbox):

From: Santiago Vila <sanvila@unex.es>
To: Antti-Juhani Kaijanaho <gaia@iki.fi>, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Wed, 14 Jul 1999 20:37:21 +0200 (CET)
On Wed, 14 Jul 1999, Antti-Juhani Kaijanaho wrote:

> On Wed, Jul 14, 1999 at 05:59:26PM +0200, Santiago Vila wrote:
> > The idea would be to provide a real list, but also the rationale from
> > which the list is derived, so that whenever the list of build-essential
> > packages change, we just update policy accordingly, without changing the
> > spirit of it. How does this sound?
> 
> I don't like the idea of going through the Policy change procedure every
> time we move something in or out of the required class.  IMHO a list is good
> to have, but I'd like more to see it as a separate document, with only
> informative status and no weight of policy (so that when these two disagree,
> it's the definition in policy which is followed).

Well: Would a footnote be a good compromise between being it in a separate
document and being it in the same paragraph in policy? :-)
If it is properly worded, we should not fear about its weight.

> > Would not be easier to specify just "Priority: required"
> 
> Possibly.  I was under the impression that Essential: yes packages are
> guaranteed to be there in every Debian system, regardless of their priority.
> 
> > on, say, Essential packages of extra priority not to be specified?
> 
> Do we have such packages in the current distributions?

Currently, maybe not; but there were in the past[*], and I think the door
is still open for them (although I agree policy is not very well worded
in this respect).

[*] There was a package, I think, which replaced e2fstools. It was
essential because it was yet another version of e2fstools, and therefore
the packaging system should not let you to remove it, but it was not
required because everybody should be happy with normal e2fstools, and it
was not supposed to be installed in the system.

Thanks.

-- 
 "848c33df24f488e0fe7fd3905ea86730" (a truly random sig)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #55 received at 41232@bugs.debian.org (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Antti-Juhani Kaijanaho <gaia@iki.fi>, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Wed, 14 Jul 1999 16:27:13 +0200
On Wed, Jul 14, 1999 at 05:15:27PM +0300, Antti-Juhani Kaijanaho wrote:
> On Wed, Jul 14, 1999 at 03:20:34PM +0200, Roman Hodek wrote:
> > Just one note: Arch-{Depends,Conflicts} might be unnecessary, as it
> > should be very rare that someone only builds the arch-indep packages.
> > So we could merge Arch-Depends into Depends. If one compiles with
> > dpkg-buildpackage -B, he needs to look only at Depends.
> > dpkg-buildpackage without -B needs to look at Depends + Indep-Depends.
> 
> This sounds doable.  Any opinions?

Fine for me.
 
> > For my current system I have defined the following packages as
> > build-essential:
> 
> I wanted to avoid naming specific packages in Policy (I only named two in
> the proposal, make and dpkg-dev), since packages change and it would be a
> pain in the rear to change policy every time GNU Libc changes name, for
> example.

IMHO, we will have to name specific packages. However, unlike Roman, I
hesitate to provide a huge default set. "make" of course sounds reasonable,
"dpkg-dev" anyway, but "texinfo" not. texinfo *was* in the tetex packages,
and I had some trouble to compile some packages on the Hurd before I had tex
:) [I used texinfo from the GNU source though, which worked fine]

Now, texinfo is not in tetex but in it's own package. Still, I think it is
important to add it to the Depends. 

I don't mind the few extra bytes, and the work is done by each maintainer on
its own, so it is reasonable to make the Depends inclusive rather then
exclusive.
 
> >   Depends-Sourcetree: tcl8.0 ("ln -s tcl8.0-* tcl8.0; cd tcl8.0; ./configure --prefix=/usr")
> 
> I want to keep this proposal as clean as possible; I don't want to see this
> kind of kluging in it if at all possible. My intent is to let this proposal
> to handle the majority cases.  The tough minority will need to be dealt with
> separately (for example, by using your central dependencies forever for
> these packages).

I have to agree with Antti-Juhani. Although it is nice that such weird
things can be automated (hi Roman :), I think this should not be covered by
dpkg for now.

> In my opinion, we should ban dependencies on source packages in the Policy
> (although I'm not proposing that yet).

Yes, this is something to consider.
 
> >  - You don't need to specify packages that are dependencies of another
> >    package that is already a source dependency, provided that nothing
> >    is used explicitly from the first package.
> 
> Agreed.  Do you want to write the language for the Policy?  I'll accept it
> as a part of this proposal, if you do.

"Indirect dependencies are evil, don't depend on them. If you do, we wil come
and hurt you." :)

I think we don't need to add this to the proposal. Roman just wanted to make
us aware of something that follows directly from the word Dependency in the
abstract sense (IMO).

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Steve Greenland <stevegr@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #60 received at 41232@bugs.debian.org (full text, mbox):

From: Steve Greenland <stevegr@debian.org>
To: Antti-Juhani Kaijanaho <gaia@iki.fi>, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Wed, 14 Jul 1999 21:32:22 -0500
If I understand the proposal, I think I have a strong objection to
the names of the fields.

> 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, Arch-Depends, Indep-Depends, Conflicts, Arch-Conflicts,
Indep-Conflicts]

I realize that these would be in the first stanza of the control
file, and therefore don't technically conflict with the binary
Depends/Conflicts fields, but I think it's going to lead to a lot
of confusion, particularly for new maintainers. Why not name them
Src-Depends, Src-Indep-Depends, etc.

Steve


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #65 received at 41232@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Thu, 15 Jul 1999 10:51:42 +0300
On Wed, Jul 14, 1999 at 09:32:22PM -0500, Steve Greenland wrote:
> I realize that these would be in the first stanza of the control
> file, and therefore don't technically conflict with the binary
> Depends/Conflicts fields, but I think it's going to lead to a lot
> of confusion, particularly for new maintainers. 

Here we have a conflict between your sense of aesthetics and mine - I'm a
minimalist, when it comes to designing interfaces. I doubt we'll be able to
agree on this one ;-)

In my opinion Depends is conceptually the same field in both build-time
dependencies and in ordinary dependencies.  Their syntax is the same, and
their semantics is almost the same.  Both intend to make sure that the
package is "usable".  The only difference in semantics comes from the fact
that the meaning of "usable" is different: for source packages, it is
"buildable".

In fact, the biggest problem I had with previous proposals, when I looked at
the archives, was that they invented a new base field.  We don't name the
Section/Priority fields Src-Section or Src-Priority, either.

And as to new maintainers, I've seen a few posts in -mentors where people
ask about simple Unix commands (in the context of packaging, of course).
They Just Will Have To Learn(tm), as we all did.

What do others think?

> Why not name them Src-Depends, Src-Indep-Depends, etc.

I might be persuaded to use Build-Depends or Source-Depends etc, but
Src-Depends is IMHO Just Too Ugly(tm).

-- 
%%% 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)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roman.Hodek@informatik.uni-erlangen.de:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #70 received at 41232@bugs.debian.org (full text, mbox):

From: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
To: Marcus.Brinkmann@ruhr-uni-bochum.de, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Thu, 15 Jul 1999 11:05:56 +0200 (MET DST)
> IMHO, we will have to name specific packages. However, unlike Roman,
> I hesitate to provide a huge default set. "make" of course sounds
> reasonable, "dpkg-dev" anyway, but "texinfo" not. texinfo *was* in
> the tetex packages, and I had some trouble to compile some packages
> on the Hurd before I had tex :) [I used texinfo from the GNU source
> though, which worked fine]

I believe everybody understood this wrong :-) I Just wanted to show an
**EXAMPLE**, namely what the central system currently considers
build-essential. I (hope that I) showed that the differences where
only stuff introduced for my convenience: perl, texinfo, and
debhelper/debmake. I've made those essential only to avoid cluttering
up the manual dependencies. To repeat: I did not propose to add them
to the list we may or may not write into policy...

> > In my opinion, we should ban dependencies on source packages in the Policy
> > (although I'm not proposing that yet).
> 
> Yes, this is something to consider.

Yes!! If a build uses something outside its own source tree, this
seems somewhat broken. The stuff that's needed should go into -dev
packages. The new tcl8.0-dev shows that this is doable.

BTW, FYI: currently those packages depend on source trees:

blt8.0-unoff => *TCL80-SOURCE, *TK80-SOURCE
blt8.0 => *TCL80-SOURCE, *TK80-SOURCE
expect => *TCL80-SOURCE
gs => *LIBJPEG-SOURCE
gs-aladdin => *LIBJPEG-SOURCE
roxen => *PIKE-SOURCE
tclx => *TCL76-SOURCE, *TK42-SOURCE
tk4.2 => *TCL76-SOURCE
tkstep8.0 => *TCL80-SOURCE, *TK80-SOURCE
tnt => *AX25UTIL-SOURCE

The Tcl/Tk source tree deps can be removed by properly using the new
data tcl8.0-dev provides. gs and gs-alladin maybe could include the
needed libjpeg code. And ax25-utils should export its stuff into a
-dev package.

> "Indirect dependencies are evil, don't depend on them. If you do, we
> wil come and hurt you." :)
> 
> I think we don't need to add this to the proposal. Roman just wanted
> to make us aware of something that follows directly from the word
> Dependency in the abstract sense (IMO).

It maybe follows directly for you, but if you don't stress it
explicitly, many people will forget this consequence... :-)

Roman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roman.Hodek@informatik.uni-erlangen.de:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #75 received at 41232@bugs.debian.org (full text, mbox):

From: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
To: 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Thu, 15 Jul 1999 11:07:24 +0200 (MET DST)
> I realize that these would be in the first stanza of the control
> file, and therefore don't technically conflict with the binary
> Depends/Conflicts fields, but I think it's going to lead to a lot of
> confusion, particularly for new maintainers. Why not name them
> Src-Depends, Src-Indep-Depends, etc.

This seems to make sense. Antti?

Roman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Steve Greenland <stevegr@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #80 received at 41232@bugs.debian.org (full text, mbox):

From: Steve Greenland <stevegr@debian.org>
To: Antti-Juhani Kaijanaho <gaia@iki.fi>, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Thu, 15 Jul 1999 22:04:12 -0500
On 15-Jul-99, 02:51 (CDT), Antti-Juhani Kaijanaho <gaia@iki.fi> wrote: 
> On Wed, Jul 14, 1999 at 09:32:22PM -0500, Steve Greenland wrote:
> > I realize that these would be in the first stanza of the control
> > file, and therefore don't technically conflict with the binary
> > Depends/Conflicts fields, but I think it's going to lead to a lot
> > of confusion, particularly for new maintainers. 
> 
> Here we have a conflict between your sense of aesthetics and mine - I'm a
> minimalist, when it comes to designing interfaces. I doubt we'll be able to
> agree on this one ;-)

Actually, I tend to agree with aesthetically :-). But sometimes
usability requirements exceed aesthetic desires.

> In my opinion Depends is conceptually the same field in both build-time
> dependencies and in ordinary dependencies.  Their syntax is the same, and
> their semantics is almost the same.
>
> In fact, the biggest problem I had with previous proposals, when I looked at
> the archives, was that they invented a new base field.  We don't name the
> Section/Priority fields Src-Section or Src-Priority, either.

Hmmm. I tend to think of the first stanza in debian/control as the
"global" stanza, and the rest as "per package". Therefore, the use
of Section/Priority is entirely consistent -- default in the first
stanza, overrides where necessary. Thus, having "Depends" in the global
stanza strikes me as confusing, because there is no connection with the
"Depends" in the rest of the file.

You, OTOH, apparently tend to think of the first as "source", the rest
as "binary"; thus no confusion about "Depends". I can't argue that's a
wrong view, either; when I consider it that way, it makes sense.

> And as to new maintainers, I've seen a few posts in -mentors where people
> ask about simple Unix commands (in the context of packaging, of course).
> They Just Will Have To Learn(tm), as we all did.

Yeah, of course. But this strikes me as "Well, if you type 'ls' in
/usr/local/src, it does this, but if you do it in /usr/bin, it does
something else." Perhaps an exageration, but we have enough problems as
it is.


> > Why not name them Src-Depends, Src-Indep-Depends, etc.
> 
> I might be persuaded to use Build-Depends or Source-Depends etc, but
> Src-Depends is IMHO Just Too Ugly(tm).

Ugly is right. What jerk came up with Src-Depends? :-) "Build-Depends"
strikes me as the most accurate and descriptive.

Anyway, go with the flow. If everybody else (or most) are comfortable
with Depends, Conflicts, etc., stick with them. (But I may track
questions in debian-mentor, and come back later with "I told you so!")

Steve




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joey@kitenet.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #85 received at 41232@bugs.debian.org (full text, mbox):

From: Joey Hess <joey@kitenet.net>
To: Steve Greenland <stevegr@debian.org>, 41232@bugs.debian.org
Cc: Antti-Juhani Kaijanaho <gaia@iki.fi>
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Fri, 16 Jul 1999 13:13:17 -0700
Steve Greenland wrote:
> Hmmm. I tend to think of the first stanza in debian/control as the
> "global" stanza, and the rest as "per package". Therefore, the use
> of Section/Priority is entirely consistent -- default in the first
> stanza, overrides where necessary. Thus, having "Depends" in the global
> stanza strikes me as confusing, because there is no connection with the
> "Depends" in the rest of the file.

Yes, I tend to look at it that way too. Unfortunatly, I think it's really a
mixture of both source and global fields.

However, this got me thinking. Antti-Juhani said earlier, referring to
indep-depends and arch-depends:

  Most packages will use only Depends and Conflicts.  The other fields 
  are useful with multi-binary packages.

Well, if the first stanza is global, how about being able to put the fields
in the other stanzas too, to control dependancies on a per-binary-package
basis? You would need to name them prefix, though. Something like:

Source: foo
Section: bar
Maintainer: Joey Hess <joeyh@master.debian.org>
Standards-Version: 2.5.0.0
Build-Depends: debhelper
Build-Conflicts: evil-package

Package: foo-doc
Architecture: all
Build-Depends: sgml-tools
...

Package: foo
Architecture: any
Build-depends: aalib1g-dev, flex
Depends: ${shlibs:Depends}
...

So foo-doc needs debhelper and sgml-tools to build, while foo needs
debhelper, aalib1g-dev and flex.

-- 
see shy jo


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #90 received at 41232@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: 41232@bugs.debian.org
Cc: Edward Betts <edward@debian.org>
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Fri, 23 Jul 1999 19:02:03 +0300
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)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #95 received at 41232@bugs.debian.org (full text, mbox):

From: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
To: gaia@iki.fi, 41232@bugs.debian.org
Cc: 41232@bugs.debian.org, edward@debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Fri, 23 Jul 1999 18:23:09 +0200 (MET DST)
>  - 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)

Ok.

>  - 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.)

Ok.

> The following suggestions will NOT be part of this proposal.  They may
> be proposed separately if necessary.

Ok.

> +            <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>
> +

Isn't that wrong? I think Build-Indep-{Depends,Conflicts} apply only
to 'binary-indep' (and transitive to 'binary'), but not to 'build'.
Otherwise, you'd have to install Build-Indep-Depends also for the pure
build...

Except that (probable) leftover from the previous version, I formally
second the proposal.

Roman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #100 received at 41232@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
Cc: 41232@bugs.debian.org, edward@debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Fri, 23 Jul 1999 19:38:51 +0300
On Fri, Jul 23, 1999 at 06:23:09PM +0200, Roman Hodek wrote:
> Isn't that wrong? I think Build-Indep-{Depends,Conflicts} apply only
> to 'binary-indep' (and transitive to 'binary'), but not to 'build'.
> Otherwise, you'd have to install Build-Indep-Depends also for the pure
> build...

Yes, consider that a typo.  I will not submit another patch as the fix
is obvious.

-- 
%%% 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)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #105 received at 41232@bugs.debian.org (full text, mbox):

From: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
To: gaia@iki.fi
Cc: 41232@bugs.debian.org, edward@debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Fri, 23 Jul 1999 18:54:30 +0200 (MET DST)
> Yes, consider that a typo. I will not submit another patch as the
> fix is obvious.

Yep, that's what I thought as I seconded the proposal :-)

Roman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Santiago Vila <sanvila@unex.es>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #110 received at 41232@bugs.debian.org (full text, mbox):

From: Santiago Vila <sanvila@unex.es>
To: 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Fri, 23 Jul 1999 18:58:54 +0200 (CET)
I second this proposal.

-- 
 "04a94df3723d0d4e76f1f34d5146c6dc" (a truly random sig)



Changed bug title. Request was from Antti-Juhani Kaijanaho <antkaij@st.jyu.fi> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `normal'. Request was from Antti-Juhani Kaijanaho <antkaij@st.jyu.fi> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #119 received at 41232@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: submit@bugs.debian.org
Cc: 41232@bugs.debian.org
Subject: dpkg-dev: Required changes to dpkg source for Policy amendment in bug#41232 [PATCH]
Date: Sat, 24 Jul 1999 00:27:52 +0300
Package: dpkg-dev
Version: 1.4.1.4
Severity: wishlist

[Watch your To and Cc lines on replies.]

The policy amendment #41232 (Build-time dependencies on binary packages)
will probably be incorporated into a future edition of the Policy
documents.  The amendment requires a change to dpkg source.

The only required changes are these:
  - make dpkg-gencontrol aware of the new fields
  - make dpkg-source -b propagate the new fields to the .dsc file
The following patch will do this, if I am not mistaken.

Please incorporate the following or equivalent patch to dpkg if the
policy amendment is accepted.  (I will personally close this bug if it
is rejected;-)



diff -Naur dpkg-1.4.1.4/scripts/controllib.pl dpkg-1.4.1.4-ibid/scripts/controllib.pl
--- dpkg-1.4.1.4/scripts/controllib.pl	Wed May 26 16:38:15 1999
+++ dpkg-1.4.1.4-ibid/scripts/controllib.pl	Sat Jul 24 00:02:13 1999
@@ -1,7 +1,9 @@
 
 $parsechangelog= 'dpkg-parsechangelog';
 
-grep($capit{lc $_}=$_, qw(Pre-Depends Standards-Version Installed-Size));
+grep($capit{lc $_}=$_, qw(Pre-Depends Standards-Version Installed-Size
+                          Build-Depends Build-Indep-Depends
+                          Build-Conflicts Build-Indep-Conflicts));
 
 $substvar{'Format'}= 1.6;
 $substvar{'Newline'}= "\n";
diff -Naur dpkg-1.4.1.4/scripts/dpkg-gencontrol.pl dpkg-1.4.1.4-ibid/scripts/dpkg-gencontrol.pl
--- dpkg-1.4.1.4/scripts/dpkg-gencontrol.pl	Wed May 26 16:38:15 1999
+++ dpkg-1.4.1.4-ibid/scripts/dpkg-gencontrol.pl	Sat Jul 24 00:07:08 1999
@@ -45,7 +45,8 @@
 $i=100;grep($fieldimps{$_}=$i--,
           qw(Package Version Section Priority Architecture Essential
              Pre-Depends Depends Recommends Suggests Optional Conflicts Replaces
-             Provides Installed-Size Maintainer Source Description));
+             Provides Installed-Size Maintainer Source Description Build-Depends
+             Build-Indep-Depends  Build-Conflicts Build-Indep-Conflicts));
 
 while (@ARGV) {
     $_=shift(@ARGV);
@@ -115,7 +116,7 @@
         if (m/^Maintainer$/) { $f{$_}=$v; }
         elsif (m/^Source$/) { &setsourcepackage; }
         elsif (s/^X[CS]*B[CS]*-//i) { $f{$_}= $v; }
-        elsif (m/^X[CS]+-|^Standards-Version$/i) { }
+        elsif (m/^X[CS]+-|^Standards-Version$|^Build-(Indep-)?(Depends|Conflicts)$/i) { }
         elsif (m/^Section$|^Priority$/) { $spdefault{$_}= $v; }
         else { &unknown('general section of control info file'); }
     } elsif (s/^C$myindex //) {
diff -Naur dpkg-1.4.1.4/scripts/dpkg-source.pl dpkg-1.4.1.4-ibid/scripts/dpkg-source.pl
--- dpkg-1.4.1.4/scripts/dpkg-source.pl	Wed May 26 16:38:15 1999
+++ dpkg-1.4.1.4-ibid/scripts/dpkg-source.pl	Sat Jul 24 00:00:59 1999
@@ -51,7 +51,8 @@
 
 $i = 100;
 grep ($fieldimps {$_} = $i--,
-      qw (Source Version Binary Maintainer Architecture Standards-Version));
+      qw (Source Version Binary Maintainer Architecture Standards-Version
+          Build-Depends Build-Indep-Depends Build-Conflicts Build-Indep-Conflicts));
 
 while (@ARGV && $ARGV[0] =~ m/^-/) {
     $_=shift(@ARGV);
@@ -112,6 +113,7 @@
 #print STDERR "G key >$_< value >$v<\n";
             if (m/^Source$/) { &setsourcepackage; }
             elsif (m/^Standards-Version$|^Maintainer$/) { $f{$_}= $v; }
+            elsif (m/^Build-(Indep-)?(Depends|Conflicts)$/i) { $f{$_}= $v; }
             elsif (s/^X[BC]*S[BC]*-//i) { $f{$_}= $v; }
             elsif (m/^(Section|Priority|Files)$/ || m/^X[BC]+-/i) { }
             else { &unknown('general section of control info file'); }

-- 
%%% 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)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Stefan Gybas <cab@studbox.uni-stuttgart.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #124 received at 41232@bugs.debian.org (full text, mbox):

From: Stefan Gybas <cab@studbox.uni-stuttgart.de>
To: Antti-Juhani Kaijanaho <gaia@iki.fi>, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Sat, 24 Jul 1999 01:58:43 +0200
Antti-Juhani Kaijanaho wrote:

> And I'm still looking for another second.

I second this proposal.

-- 
Stefan Gybas




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #129 received at 41232@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: Antti-Juhani Kaijanaho <gaia@iki.fi>, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Sun, 25 Jul 1999 17:01:48 +0100 (BST)
Antti-Juhani Kaijanaho writes ("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.

I strongly agree with the proposal.  If you still need seconds, count
me as one.

> 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)

I agree with the prefix `Build-'.

I disagree with Roman's suggestion that we should remove the Arch-
versions because they'd not be used often.  I think it important that
the resulting scheme be orthogonal.  It should also parallel the
`binary-*' targets in debian/rules.

I therefore suggest the following list
   Build-Depends
   Build-Depends-Indep
   Build-Depends-Arch
   Build-Conflicts
   Build-Conflicts-Indep
   Build-Conflicts-Arch
where debian/rules binary-foo (where foo is indep or arch) requires
both the -Foo and plain Depends and Conflicts forms to be satisfied,
and debian/rules binary requires all six to be satisfied.

>  - 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.)

Right.

> 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.)

Right.

>  - 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.)

Right.

>  - 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 think that instead the formulation about `compile and link a trivial
C or C++ program and put it in a Debian package' should be the
defining one.  We can supply a list of example packages, but we should
explicitly state that it's only an example which was `true at the time
of writing'.

I think that texinfo shouldn't be there.

Can I suggest another couple of changes ?

 Build-time dependencies must specify version number(s) of package(s)
 if the version in the current Debian stable distribution is not
 adequate.  If this is necessary usually a >= dependency should be
 used.

 It is a bug if, after unpacking the source package on a system
 running the current stable distribution, and satisfying the source
 dependencies (including the implied dependencies), you 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.

Ian.


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #134 received at 41232@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: Ian Jackson <ian@davenant.greenend.org.uk>, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Sun, 25 Jul 1999 20:36:48 +0300
On Sun, Jul 25, 1999 at 05:01:48PM +0100, Ian Jackson wrote:
> I strongly agree with the proposal.  If you still need seconds, count
> me as one.

No, I don't, but thanks anyway :-)

> I therefore suggest the following list
>    Build-Depends
>    Build-Depends-Indep
>    Build-Depends-Arch
>    Build-Conflicts
>    Build-Conflicts-Indep
>    Build-Conflicts-Arch
> where debian/rules binary-foo (where foo is indep or arch) requires
> both the -Foo and plain Depends and Conflicts forms to be satisfied,
> and debian/rules binary requires all six to be satisfied.

I would like to use this suggestion.  Comments?

> I think that instead the formulation about `compile and link a trivial
> C or C++ program and put it in a Debian package' should be the
> defining one.

Sounds good.  Actually, that was what I had originally in mind.  If there
are no objections, I'll make this part of my proposal (seconders: I need
your comments!).

> I think that texinfo shouldn't be there.

Agreed.

>  Build-time dependencies must specify version number(s) of package(s)
>  if the version in the current Debian stable distribution is not
>  adequate.  If this is necessary usually a >= dependency should be
>  used.
> 
>  It is a bug if, after unpacking the source package on a system
>  running the current stable distribution, and satisfying the source
>  dependencies (including the implied dependencies), you 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.

I see the point of this suggestion, but I'm not sure the wording is
wise.  We can't expect to be able to compile the unstable distribution
while satisfying build dependencies with packages in the stable
distribution (think of Gnome in potato or a libc upgrade, for example).
Your suggestion would require us to put in build-time dependencies which
would become redundant the minute we release!

No, I'd like to use something like this: Every package is meant for a
particular distribution (slink, potato, woody, ...), and a package must
be buildable in that distribution, when dependencies are satisfied.

Comments?

-- 
%%% 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)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #139 received at 41232@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: 41232@bugs.debian.org
Subject: Bug#41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: Sun, 25 Jul 1999 20:42:04 +0300
As required by the policy amendment guidelines, and as the proposer
of this amendment, I'm setting the discussion period to two weeks.
It started on 23th of July, 1999, when the proposal entered amendment
status, and will end on 6th of August, 1999.

-- 
%%% 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)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roman.Hodek@informatik.uni-erlangen.de:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #144 received at 41232@bugs.debian.org (full text, mbox):

From: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
To: Debian Policy List <debian-policy@lists.debian.org>, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Mon, 26 Jul 1999 10:54:38 +0200 (MET DST)
> I strongly agree with the proposal.

Nice to have you on the boat, too :-)

> I disagree with Roman's suggestion that we should remove the Arch-
> versions because they'd not be used often. I think it important that
> the resulting scheme be orthogonal. It should also parallel the
> `binary-*' targets in debian/rules.

The current fields are as (un-)orthogonal as the dpkg-buildpackage
options are: You can use -B to build without Arch: all packages, or
you can build all packages.

I see your point, and I can live with the Arch- variants if a majority
wants them. But I still think they just make more work, both for
maintainers who have to define them, and for tools which read source
dependencies. There's no (official) possibility to build only the
Arch: all packages, and this also doesn't make much sense in most
cases.

> I think that instead the formulation about `compile and link a trivial
> C or C++ program and put it in a Debian package' should be the
> defining one.  We can supply a list of example packages, but we should
> explicitly state that it's only an example which was `true at the time
> of writing'.

This seems like the footnote idea...

> Build-time dependencies must specify version number(s) of package(s)
> if the version in the current Debian stable distribution is not
> adequate. If this is necessary usually a >= dependency should be
> used.

This looks like an important point. Anybody against it?

> It is a bug if, after unpacking the source package on a system
> running the current stable distribution, and satisfying the source
> dependencies (including the implied dependencies), you 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.

Ok, this explicitly says what's the intention of source dependencies.
It's correct that this hasn't been said in a formal way yet. For my
part, we can add it, too.

Roman



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #149 received at 41232@bugs.debian.org (full text, mbox):

From: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
To: 41232@bugs.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Mon, 26 Jul 1999 11:02:35 +0200 (MET DST)
> I would like to use this suggestion. Comments?

See my previous mail: I'd say the -Arch variants are unnecessary, but
if everybody wants them for clearness of design, I won't oppose.

> Sounds good. Actually, that was what I had originally in mind. If
> there are no objections, I'll make this part of my proposal
> (seconders: I need your comments!).

Ok with me.

> > I think that texinfo shouldn't be there.
> 
> Agreed.

texinfo etc. were out of the games for a long time, I thought :-)

> I see the point of this suggestion, but I'm not sure the wording is
> wise. We can't expect to be able to compile the unstable
> distribution while satisfying build dependencies with packages in
> the stable distribution (think of Gnome in potato or a libc upgrade,
> for example).

I think you've mis-read Ian's statement here. He didn't say that
source dependencies might be satisfied from stable only (this would
indeed be nonsense). But a consequence is that the src-deps must be
properly versioned so that the appropriate packages from unstable are
installed.

Roman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Joel Klecker <jk@espy.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #154 received at 41232@bugs.debian.org (full text, mbox):

From: Joel Klecker <jk@espy.org>
To: 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Sat, 31 Jul 1999 21:20:53 -0700
I just realized I have to object to this proposal on the grounds that 
it doesn't allow me to correctly specify glibc's source depends.
I need them conditional on DEB_HOST_GNU_SYSTEM, e.g. for Linux-based 
GNU systems I need to depend on kernel-headers-<version>, for 
HURD-based GNU systems I need hurd-dev and gnumach-dev (at least, I 
think I do).
I'm not sure how many other packages might need conditional source 
depends, this could be a specialized requirement.
-- 
Joel Klecker (aka Espy)                    Debian GNU/Linux Developer
<URL:mailto:jk@espy.org>                 <URL:mailto:espy@debian.org>
<URL:http://web.espy.org/>               <URL:http://www.debian.org/>


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joey@kitenet.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #159 received at 41232@bugs.debian.org (full text, mbox):

From: Joey Hess <joey@kitenet.net>
To: Joel Klecker <jk@espy.org>, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Sat, 31 Jul 1999 22:24:47 -0700
Joel Klecker wrote:
> I just realized I have to object to this proposal

I hope this isn't another case of a formal objection without even talking it
over first?

> on the grounds that 
> it doesn't allow me to correctly specify glibc's source depends.
> I need them conditional on DEB_HOST_GNU_SYSTEM, e.g. for Linux-based 
> GNU systems I need to depend on kernel-headers-<version>, for 
> HURD-based GNU systems I need hurd-dev and gnumach-dev (at least, I 
> think I do).
> I'm not sure how many other packages might need conditional source 
> depends, this could be a specialized requirement.

Why not make some virtual packages. All kernel-headers-* packages provide
both, the hurd-dev and gnumach-dev packages each provide one.

-- 
see shy jo


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #164 received at 41232@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
Cc: 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Sun, 1 Aug 1999 15:55:01 +0300
On Mon, Jul 26, 1999 at 10:54:38AM +0200, Roman Hodek wrote:
> I see your point, and I can live with the Arch- variants if a majority
> wants them.

The majority?  There have been, what, probably less than ten people
involved in this discussion.  I don't think a majority vote among them
would be of any indication of what majority want.

> But I still think they just make more work, both for
> maintainers who have to define them, and for tools which read source
> dependencies.

The work for the tools is insignificant.  For maintainers - well, they
can always use Build-Depends as a catch-all and use it like they would
use it in your model.

Here's how the fields would map to the targets

Six-field:
  Build-(Depends|Conflicts): build, binary-arch, binary-indep
  Build-(Depends|Conflicts)-Arch: binary, binary-arch
  Build-(Depends|Conflicts)-Indep: binary, binary-indep

Four-field:  
  Build-(Depends|Conflicts): build, binary, binary-arch, binary-indep
  Build-(Depends|Conflicts)-Indep: binary, binary-indep

(I just noticed that we must not have build map to anything else than
the plain Build-Depends in either model; as you noted earlier, it would
just make the other fields void of purpose.)

If in the four-field model, a maintainer could say

Build-Depends: foo bar
Build-Depends-Indep: baz

where bar is being needed only for the arch-dependent packages, then in the six-field
model she can say either

Build-Depends: foo bar
Build-Depends-Indep: baz

(the same!) or

Build-Depends: foo
Build-Depends-Arch: bar
Build-Depends-Indep: baz

whichever suits her.  Of course, the two-field way in the six-field model
will be deprecated when (if) we allow building only arch-all packages.

Would the six-field model be okay with you in this light?

> > Build-time dependencies must specify version number(s) of package(s)
> > if the version in the current Debian stable distribution is not
> > adequate. If this is necessary usually a >= dependency should be
> > used.
> 
> This looks like an important point. Anybody against it?

I would be.  I don't like introducing the variable concept of "stable
distribution" in here.  I'd more like to use the rule we use with binary
dependencies: use versioned dependency if some version would not be
acceptable, independent of the distributions involved.

-- 
%%% 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)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #169 received at 41232@bugs.debian.org (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Joey Hess <joey@kitenet.net>, 41232@bugs.debian.org
Cc: Joel Klecker <jk@espy.org>
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Sun, 1 Aug 1999 18:29:29 +0200
On Sat, Jul 31, 1999 at 10:24:47PM -0700, Joey Hess wrote:
> > on the grounds that 
> > it doesn't allow me to correctly specify glibc's source depends.
> > I need them conditional on DEB_HOST_GNU_SYSTEM, e.g. for Linux-based 
> > GNU systems I need to depend on kernel-headers-<version>, for 
> > HURD-based GNU systems I need hurd-dev and gnumach-dev (at least, I 
> > think I do).
> > I'm not sure how many other packages might need conditional source 
> > depends, this could be a specialized requirement.
> 
> Why not make some virtual packages. All kernel-headers-* packages provide
> both, the hurd-dev and gnumach-dev packages each provide one.

In my experience, such quick hacks are inconvenient for people who for
example create a new distribution (for example Debian GNU/BSD), because
changes need coordination between several maintainers. It is much better if
we try to keep our decentralized structure.

And, it would somehow be wrong, because there is no abstract ground on which
these virtual packages could be created. They would come out of thin air,
just to fit this proposal.

We have packages that can't be compiled on all arhcitectures. Now we need to
care about different source dependencies on different architectures as well.

This shouldn't be too hard. You only need a syntax for it. There are several
possibilities:

Build-Depends: hurd-all:gnumach-dev, hurd-all:hurd-dev, linux-all:kernel-headers-2.0.36

Or:

Build-Depends: texinfo
Build-Depends-hurd-all: gnumach-dev, hurd-dev
Build-Depends-linux-all: kernel-headers-2.0.36

Whatever you do, please make sure that this proposal is flexible enough to
catch individual Debian architectures, not only Hurd vs. Linux.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #174 received at 41232@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Sun, 1 Aug 1999 21:50:17 +0300
On Sun, Aug 01, 1999 at 06:29:29PM +0200, Marcus Brinkmann wrote:
> Whatever you do, please make sure that this proposal is flexible enough to
> catch individual Debian architectures, not only Hurd vs. Linux.

Please help in this.  You know the problems better than I - what problems
there are that would be best solved by Yet Another Syntax, and why they
can't be solved in other ways and what options are there.

I'm not too comfortable with amending this proposal in this magnitude.

-- 
%%% 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)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roman.Hodek@informatik.uni-erlangen.de:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #179 received at 41232@bugs.debian.org (full text, mbox):

From: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
To: Marcus.Brinkmann@ruhr-uni-bochum.de, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Mon, 2 Aug 1999 11:36:19 +0200 (MET DST)
> This shouldn't be too hard. You only need a syntax for it. There are several
> possibilities:
> 
> Build-Depends: hurd-all:gnumach-dev, hurd-all:hurd-dev, linux-all:kernel-headers-2.0.36

The prefix idea is good, here a suggestion for concrete syntax:

  ARCH:package        restricted to ARCH (all OSes)
  OS-*:package        restricted to OS (all ARCHs)
  OS-ARCH:package     restricted to OS-ARCH
  ARCH1|ARCH2:package more restrictions can be combined with '|', i.e.
                      package restricted to ARCH1 or ARCH2
  !ARCH:package       restrictions can be negated with '!'

> Build-Depends: texinfo
> Build-Depends-hurd-all: gnumach-dev, hurd-dev
> Build-Depends-linux-all: kernel-headers-2.0.36

This makes an inflation of field names :-)

Roman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #184 received at 41232@bugs.debian.org (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
Cc: 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Mon, 2 Aug 1999 14:55:53 +0200
On Mon, Aug 02, 1999 at 11:36:19AM +0200, Roman Hodek wrote:
> 
> > This shouldn't be too hard. You only need a syntax for it. There are several
> > possibilities:
> > 
> > Build-Depends: hurd-all:gnumach-dev, hurd-all:hurd-dev, linux-all:kernel-headers-2.0.36
> 
> The prefix idea is good, here a suggestion for concrete syntax:
> 
>   ARCH:package        restricted to ARCH (all OSes)

Your naming is weird ;)  s/ARCH/CPU/, s/OS/SYSTEM/ and I'm your friend.
An example would be a bootloader, by the way, like GRUB (a program with
special grub support on i386 machines could exploit this).

>   OS-*:package        restricted to OS (all ARCHs)
>   OS-ARCH:package     restricted to OS-ARCH
>   ARCH1|ARCH2:package more restrictions can be combined with '|', i.e.
>                       package restricted to ARCH1 or ARCH2
>   !ARCH:package       restrictions can be negated with '!'

Looks good to me. I don't know how many logical operators we should support,
but it goes in the right direction. I am also unsure about the colon (:) as
seperator.
 
> > Build-Depends: texinfo
> > Build-Depends-hurd-all: gnumach-dev, hurd-dev
> > Build-Depends-linux-all: kernel-headers-2.0.36
> 
> This makes an inflation of field names :-)

Agreed. I also think that the -Arch fields are overkill.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roman.Hodek@informatik.uni-erlangen.de:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #189 received at 41232@bugs.debian.org (full text, mbox):

From: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
To: Marcus.Brinkmann@ruhr-uni-bochum.de
Cc: 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Mon, 2 Aug 1999 14:59:43 +0200 (MET DST)
> Your naming is weird ;) s/ARCH/CPU/, s/OS/SYSTEM/ and I'm your
> friend.

If it makes you lucky, think the vars re-named :-) But it really makes
no difference, I meant exactly the same as you, i.e. ARCH == cpu.

> Looks good to me. I don't know how many logical operators we should
> support, but it goes in the right direction. I am also unsure about
> the colon (:) as seperator.

The | operator seems necessary when a package needs e.g.svglib on i386
and alpha and nowhere else. The ! operator is necessary to avoid
listings of all archs except one. Such lists have to be extended
whenever there's a new Debian arch, and this calls for bugs.

And I think the colon is as good or bad as anything else, so why not?

Roman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Richard Braakman <dark@xs4all.nl>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #194 received at 41232@bugs.debian.org (full text, mbox):

From: Richard Braakman <dark@xs4all.nl>
To: Antti-Juhani Kaijanaho <gaia@iki.fi>, 41232@bugs.debian.org
Cc: Edward Betts <edward@debian.org>
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Mon, 2 Aug 1999 15:56:30 +0200 (CEST)
Are the -Conflicts headers really necessary?  So far I have not been
able to think of a use for them, and they complicate the task of the
build daemons ("install everything needed to build this package")
unnecessarily.  We've already seen with binary dependencies that
the Conflicts relationships create the most difficult problems.

If package foo has Build-Conflicts: bar, it means that the *presence*
of bar will prevent foo from building correctly.  I consider that a
bug!  Adding support for this would condone such bugs.

I propose that the -Conflicts headers be dropped, unless there is
an example of when they would be good and useful.  I've already
considered a few:

  - Problem: There are two conflicting development environments (let's
    call them tk40-dev and tk41-dev :-), and foo needs the right one.
    Solution: foo declares a Build-Depends on tk41-dev, and tk41-dev
    conflicts with tk40-dev.
  - Problem: Package foo needs debassistant >= 0.8 to build, but
    will not work with debassistant version 0.93 which has a horrible bug.
    Solution: foo declares
          Build-Depends: debassistant (>= 0.8),
                         debassistant (<< 0.93) | debassistant (>> 0.93)

Is there any case where one would want a Build-Conflicts?  Allowing
them will complicate all the code that deals with build dependencies,
whether they are used or not.

Richard Braakman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Stefan Gybas <cab@studbox.uni-stuttgart.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #199 received at 41232@bugs.debian.org (full text, mbox):

From: Stefan Gybas <cab@studbox.uni-stuttgart.de>
To: Roman.Hodek@informatik.uni-erlangen.de, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Mon, 02 Aug 1999 22:55:17 +0200
Roman Hodek wrote:

> The prefix idea is good, here a suggestion for concrete syntax:

I´d prefer a syntax in the style of /etc/exports, e.g.

Build-Depends: package1, package2(CPU1), package3(!CPU1), 
 package4(SYSTEM2-CPU2, SYSTEM3-*), package5 | package6(CPU1),
 package7(CPU1, >= 2.0), package7(!CPU1, >= 2.1)

It looks a bit easier to read (and create) to me than the prefix
syntax as there is already a colon after "Build-Depends". If there
is a system-cpu specification, it must be before the version
specification, so a parser for this would not be too difficult.

About the conflict headers: I don´t think they are necessary, so
I vote for removing them from the proposal (as Richard suggested).

About 4 or 6 fields (actually 2 or 3 without *-Conflicts:): Both
models are fine for me, I prefer the one with 3 fields.

-- 
Stefan Gybas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roman.Hodek@informatik.uni-erlangen.de:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #204 received at 41232@bugs.debian.org (full text, mbox):

From: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
To: cab@studbox.uni-stuttgart.de
Cc: 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Tue, 3 Aug 1999 09:27:02 +0200 (MET DST)
> I´d prefer a syntax in the style of /etc/exports, e.g.
> 
> Build-Depends: package1, package2(CPU1), package3(!CPU1), 
>  package4(SYSTEM2-CPU2, SYSTEM3-*), package5 | package6(CPU1),
>  package7(CPU1, >= 2.0), package7(!CPU1, >= 2.1)
> 
> It looks a bit easier to read (and create) to me than the prefix
> syntax as there is already a colon after "Build-Depends". If there
> is a system-cpu specification, it must be before the version
> specification, so a parser for this would not be too difficult.

Hmm... but the parser still has to decide if the thing in parens is an
arch spec or a version spec, which isn't really trivial, as the
version number can be an arbitrary string. I think I'm against this
just because it's too hard to parse.

> About the conflict headers: I don´t think they are necessary, so I
> vote for removing them from the proposal (as Richard suggested).

No, they're really necessary. An example is bash: If you have
termcap-compat installed during the build, configure will detect
libtermcap before libncurses and link everything with the obsolete
libtermcap. Therefore bash needs a Build-Conflict: termcap-compat.

Roman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #209 received at 41232@bugs.debian.org (full text, mbox):

From: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
To: dark@xs4all.nl, 41232@bugs.debian.org
Cc: gaia@iki.fi, edward@debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Tue, 3 Aug 1999 10:42:49 +0200 (MET DST)
> Are the -Conflicts headers really necessary? So far I have not been
> able to think of a use for them, and they complicate the task of the
> build daemons ("install everything needed to build this package")
> unnecessarily.

That's not really true. The parsing is nearly the same, and it's no
trouble in sbuild to deinstall packages as that's needed anyway after
the build. I guess the negative deps (as I have called them in sbuild)
make about 5 lines of code.

> We've already seen with binary dependencies that the Conflicts
> relationships create the most difficult problems.

But it's something different here... It's really trivial to
temporatily uninstall a package and reinstall it later.

> 	- Problem: There are two conflicting development environments (let's
> 	  call them tk40-dev and tk41-dev :-), and foo needs the right one.
> 	  Solution: foo declares a Build-Depends on tk41-dev, and tk41-dev
> 	  conflicts with tk40-dev.

Yep, it's already done this way without problems and without the need
for build-conflicts.

> 	- Problem: Package foo needs debassistant >= 0.8 to build, but
> 	  will not work with debassistant version 0.93 which has a horrible bug.

Yep :-)

> 	  Solution: foo declares
> 			Build-Depends: debassistant (>= 0.8),
> 						   debassistant (<< 0.93) | debassistant (>> 0.93)

Ok (though a bit complicated, but doesn't matter, it should be rarely
necessary.)

> If package foo has Build-Conflicts: bar, it means that the *presence*
> of bar will prevent foo from building correctly.  I consider that a
> bug!  Adding support for this would condone such bugs.

Hmm... Let's see where such conflicts are used currently:

a2ps => !lprng, lpr, gs, psutils, bzip2, gv, ghostview, gettext, flex

  Hmm... don't remember exactly anymore, but I guess lpr is needed and
  doesn't like lprng in parallel.

abuse => !svgalib-dummyg1
gnuplot => !svgalib-dummyg1, gnuplot

  Some packages would configure for svgalib if svgalib-dummy is installed.

bash => !termcap-compat

  If termcap-compat is installed, configure will detect libtermcap
  before libncurses and link with the former.

emacs20 => !emacs20

  AFAICR emacs used the installed lisp files instead of the ones in
  the build dir, but this has been fixed some time ago.

liece => emacs20, !libsocks-dev

  Can't remember... :-(

plplot => g77, !f2c, itcl3.0-dev, python-numeric

  f2c doesn't conflict with g77, but is preferred by the config.

rpm => !bzip2, m4, gettext, autoconf, automake, tetex-bin

  If bzip2 is installed, librpm.so will be linked with libbz2.so,
  which is unwanted.

ruby => bison, !ruby

  And installed ruby can provoke version conflicts of the installed
  lib and the built lib.

I think at least the cases of bash, plplot, and rpm are no bugs.

Roman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roman.Hodek@informatik.uni-erlangen.de:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #214 received at 41232@bugs.debian.org (full text, mbox):

From: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
To: jgg@ualberta.ca, Debian Policy List <debian-policy@lists.debian.org>, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Tue, 3 Aug 1999 10:45:39 +0200 (MET DST)
> Can we use a format that is more inline with the rest of the depends
> stuff? Perhaps:
> 	 
> 	pkg (>= 2.1 i386)
> 
> With the 'i386' being whatever specification you want to dream up.
> (optional of course)

At least better to parse than "package7(CPU1, >= 2.0)", as the version
can't contain spaces and anything following it must be an arch spec.

Roman



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Richard Braakman <dark@xs4all.nl>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #219 received at 41232@bugs.debian.org (full text, mbox):

From: Richard Braakman <dark@xs4all.nl>
To: 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Tue, 3 Aug 1999 11:57:34 +0200 (CEST)
Roman Hodek wrote:
> But it's something different here... It's really trivial to
> temporatily uninstall a package and reinstall it later.

What if you can only uninstall the package by deconfiguring another one
that you need?  Take this situation:

foo-source has
  Build-Depends: gnu1 | gnu2
  Build-Conflicts: bar

gnu1 has
  Depends: bar

Currently bar and gnu1 are installed.  Will your five lines of code be
able to uninstall bar, uninstall gnu1, and install gnu2?

> Hmm... Let's see where such conflicts are used currently:
> 
> a2ps => !lprng, lpr, gs, psutils, bzip2, gv, ghostview, gettext, flex
> 
>   Hmm... don't remember exactly anymore, but I guess lpr is needed and
>   doesn't like lprng in parallel.

Hmm, lprng Provides lpr (and Conflicts with it).  I guess this
expresses that lprng won't do.

> abuse => !svgalib-dummyg1
> gnuplot => !svgalib-dummyg1, gnuplot
> 
>   Some packages would configure for svgalib if svgalib-dummy is installed.

They should be configured not to use svgalib, via options in debian/rules.
This should not depend on the build environment.  (If it does, it's
far too easy to silently build without it, even on a platform that
does need it).

> bash => !termcap-compat
> 
>   If termcap-compat is installed, configure will detect libtermcap
>   before libncurses and link with the former.

Also a packaging bug.  Bash should be told to use libncurses, regardless
of the build environment.

> plplot => g77, !f2c, itcl3.0-dev, python-numeric
> 
>   f2c doesn't conflict with g77, but is preferred by the config.
>
> rpm => !bzip2, m4, gettext, autoconf, automake, tetex-bin
> 
>   If bzip2 is installed, librpm.so will be linked with libbz2.so,
>   which is unwanted.

(and so forth)... these should all be told to configure the right way,
regardless of build environment.  Build-time configuration is nice, but
not if you want the binary package to be easily reproducible.  I've
already seen far too many bugs in NMUs caused by packages silently built
with the wrong configuration.  Also, the normal course for a user who
is faced with a core dump is to try to get a backtrace by compiling the
program with debugging symbols.

> ruby => bison, !ruby
> 
>   And installed ruby can provoke version conflicts of the installed
>   lib and the built lib.

Definitely a bug in ruby's build environment... imagine these :-)

gcc => binutils, !gcc
perl => !perl

> I think at least the cases of bash, plplot, and rpm are no bugs.

I think they are, for the reasons I've given above.

Richard Braakman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #224 received at 41232@bugs.debian.org (full text, mbox):

From: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
To: dark@xs4all.nl, 41232@bugs.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Tue, 3 Aug 1999 12:54:56 +0200 (MET DST)
> What if you can only uninstall the package by deconfiguring another one
> that you need?  Take this situation:
> 
> foo-source has
> 	Build-Depends: gnu1 | gnu2
> 	Build-Conflicts: bar
> 
> gnu1 has
> 	Depends: bar
> 
> Currently bar and gnu1 are installed.  Will your five lines of code be
> able to uninstall bar, uninstall gnu1, and install gnu2?

First: The ~ 5 lines were for additional support of negative
dependencies.

Second: sbuild currently doesn't support alternatives yet :-(

Third: Dependency calculations et al. are passed on to apt-get, so
they make up no code :-)

> Hmm, lprng Provides lpr (and Conflicts with it). I guess this
> expresses that lprng won't do.

Ah, that sounds like an explanation, yes. Isn't this a good reason for
Build-Conflicts:? A simple Build-Depends: lpr could be satisfied by
lprng as well, but it's wrong since a2ps needs real lpr, not lprng.

> They should be configured not to use svgalib, via options in debian/rules.
> This should not depend on the build environment.  (If it does, it's
> far too easy to silently build without it, even on a platform that
> does need it).

This is the case for many, really many libs :-( It was one of the
reason we've "invented" source dependencies. You simply can't hardwire
all lib dependencies as options to configure.

> Also a packaging bug. Bash should be told to use libncurses,
> regardless of the build environment.

Also if you have to patch a really correct upstream configure? (I
assume there's no option for disabling libtermcap.)

> (and so forth)... these should all be told to configure the right
> way, regardless of build environment. Build-time configuration is
> nice, but not if you want the binary package to be easily
> reproducible.

...but often configure scripts aren't flexible enough so that you can
select all options from the command line :-(

> I've already seen far too many bugs in NMUs caused by packages
> silently built with the wrong configuration.

And this hopefully will come to an end with source dependencies!

Roman




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to kaih@khms.westfalen.de (Kai Henningsen):
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #229 received at 41232@bugs.debian.org (full text, mbox):

From: kaih@khms.westfalen.de (Kai Henningsen)
To: 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on b
Date: 03 Aug 1999 17:54:00 +0200
dark@xs4all.nl (Richard Braakman)  wrote on 02.08.99 in <E11BIZq-0005TP-00@night>:

> Is there any case where one would want a Build-Conflicts?  Allowing
> them will complicate all the code that deals with build dependencies,
> whether they are used or not.

The only one I can think of is configure picking up unwanted stuff, and  
there should be better ways to deal with that problem.

MfG Kai


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Stefan Gybas <cab@studbox.uni-stuttgart.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #234 received at 41232@bugs.debian.org (full text, mbox):

From: Stefan Gybas <cab@studbox.uni-stuttgart.de>
To: Roman.Hodek@informatik.uni-erlangen.de, 41232@bugs.debian.org
Subject: Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages
Date: Wed, 04 Aug 1999 11:49:14 +0200
Roman Hodek wrote:

> Hmm... but the parser still has to decide if the thing in parens is an
> arch spec or a version spec, which isn't really trivial, as the
> version number can be an arbitrary string.

Yes, but a version specification starts with "<", "=" or ">" so it can
be decided at the first character and as I've suggested before the version
specification must be last inside the parenthesis.

> No, they're really necessary. An example is bash: If you have
> termcap-compat installed during the build, configure will detect
> libtermcap before libncurses and link everything with the obsolete
> libtermcap.

I think this should be handled in the build process itself (either
a configure option or patch configure itself) as I've already said when
I discovered the incorrectly built m68k binary, but the lpr/lprng example
convinced my that Build-Conflicts: is needed so I'm changing my opinion
here.

-- 
Stefan Gybas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #239 received at 41232@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: 41232@bugs.debian.org
Subject: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: Sat, 7 Aug 1999 02:18:41 +0300
The discussion period for this amendment ended on Friday, the 6th of
August, 1999.  However, we don't yet have a consensus.  We do seem to be
on the right track, though, so I'd like us to grant the one-time one-week
extension to this discussion period.  Thus the discussion should end on
Friday, the 13th of this month.  If this is not acceptable, the amendment
should be marked as rejected.

To concentrate the remaining discussion on the matters at hand, I'll
summarise the points of disagreement and add my comments.

  * Are Build-Conflicts really necessary?
        - they appear to be, reading the current list
	  of build-dependencies used by sbuild.
	  
  * Do we need to conditionalize the build dependencies based
    on architectures?
        - Joel Klecker and Marcus Brinkmann seem to think so.
	  I'm not convinced yet.
	- This would complicate the syntax
	
  * If so, what syntax should we use?
        - My choice would be the "package (>= 42 i386)" syntax,
	  as it's the least intrusive choice.
	  
  * Should we use four fields or six fields?
        - In my opinion the four-field choice offers no real
	  advantages (I've discussed my position in detail earlier)
	  
  * When are versioned dependencies necessary?
        - Ian Jackson wants to allow the "current stable" as
	  the base where versioned dependencies are not
	  necessary
	- I've stated my position earlier: use versioned dependencies
	  every time the non-versioned dependencies would introduce
	  a possibility of a broken build, regardless of releases.

I'd like us to reach a consensus on these points during the week we have
left.  If we can't, the proposal should be marked rejected.  (And possibly
a new, revised proposal sent out, if necessary.)

I will be away for a few days starting from later today (Sat).

-- 
%%% 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)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Joel Klecker <jk@espy.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #244 received at 41232@bugs.debian.org (full text, mbox):

From: Joel Klecker <jk@espy.org>
To: 41232@bugs.debian.org
Subject: Re: Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: Fri, 6 Aug 1999 17:00:27 -0700
At 02:18 +0300 1999-08-07, Antti-Juhani Kaijanaho wrote:
>  * Do we need to conditionalize the build dependencies based
>    on architectures?
>        - Joel Klecker and Marcus Brinkmann seem to think so.
>	  I'm not convinced yet.

Well, I *need* that to represent glibc's source depends correctly.

It'd be rediculous for a Debian GNU/HURD system to need 
"kernel-headers-2.2.10" to be installed for glibc's build depends to 
be satisfied, and equally rediculous for a Debian GNU/Linux system to 
need "hurd-dev" and "gnumach-dev" and "mig"(?).
-- 
Joel Klecker (aka Espy)                    Debian GNU/Linux Developer
<URL:mailto:jk@espy.org>                 <URL:mailto:espy@debian.org>
<URL:http://web.espy.org/>               <URL:http://www.debian.org/>


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Anthony Towns <aj@azure.humbug.org.au>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #249 received at 41232@bugs.debian.org (full text, mbox):

From: Anthony Towns <aj@azure.humbug.org.au>
To: Antti-Juhani Kaijanaho <gaia@iki.fi>, 41232@bugs.debian.org
Subject: Re: Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: Sat, 7 Aug 1999 10:09:37 +1000
[Message part 1 (text/plain, inline)]
On Sat, Aug 07, 1999 at 02:18:41AM +0300, Antti-Juhani Kaijanaho wrote:
>   * Are Build-Conflicts really necessary?
>         - they appear to be, reading the current list
> 	  of build-dependencies used by sbuild.

Perhaps it'd be a good idea to allow them, but strongly encourage packages
not to use them wherever possible. (ie, configure scripts should be made
to detect things in the right order, and so forth, and conflicts only
stated where the maintainer can't work out how to fix it, and no patches
have been provided, and so on)

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
        results in slower code, and it results in more bugs.''
                                        -- Linus Torvalds
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #254 received at 41232@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: Joel Klecker <jk@espy.org>, 41232@bugs.debian.org
Subject: Re: Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: Sat, 7 Aug 1999 12:57:21 +0300
On Fri, Aug 06, 1999 at 05:00:27PM -0700, Joel Klecker wrote:
> Well, I *need* that to represent glibc's source depends correctly.

Do you?

> It'd be rediculous for a Debian GNU/HURD system to need 
> "kernel-headers-2.2.10" to be installed for glibc's build depends to 
> be satisfied, and equally rediculous for a Debian GNU/Linux system to 
> need "hurd-dev" and "gnumach-dev" and "mig"(?).

These packages share the common function of containing headers (?) for
the kernel, be it Linux or the Hurd.  Why is it then so appalling to
have both package sets provide a suitable virtual package?

(I will be easily converted to your ways if you just convince me of this
point ;-)

-- 
%%% 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)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #259 received at 41232@bugs.debian.org (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Antti-Juhani Kaijanaho <gaia@iki.fi>, 41232@bugs.debian.org
Subject: Re: Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: Sat, 7 Aug 1999 04:12:13 +0200
On Sat, Aug 07, 1999 at 02:18:41AM +0300, Antti-Juhani Kaijanaho wrote:
> If this is not acceptable, the amendment
> should be marked as rejected.

Na, better not. Let's hammer this one in shape now :)
 
>   * Are Build-Conflicts really necessary?
>         - they appear to be, reading the current list
> 	  of build-dependencies used by sbuild.

Agreed. They may be rare, but necessary. In an ideal world, every
source generation scheme would allow for unlimited customization, but
unfortunately, we are far away from that goal :-/

>   * Do we need to conditionalize the build dependencies based
>     on architectures?
>         - Joel Klecker and Marcus Brinkmann seem to think so.
> 	  I'm not convinced yet.

Yes, we definitely need this. There are already packages that require this,
and there will be more (for example, when we will tackle upstream sources to
support special Hurd features, the package may need special Hurd libraries
to compile that are only available under Hurd architectures).

Ignoring this feature now would serve no one, as it must come anyway. Let's
do it right from the very beginning. (Look at the mess that the current
architecture setup, linux makedev in binary-all for example, very annoying
for the Hurd port. We should learn from this experience and not repeat such
overseights).

> 	- This would complicate the syntax

Only for those packages that make use of it! Those will be only a few
compared with the complete distribution for some time.

This is also not hard to implement. You can make use of dpkg-architecture in
dpkg-dev! This does already give you Debian arch name, GNU CPU and GNU
system string ("linux" or "gnu" for hurd).

If you want, you can leave this out of the implementation and I will do it
when the other features are all supported. Then I add this later-on. Nothing
requires the implementation to be perfect from the beginning, but let's
not go through the policy proposal/amendment cycle again just for this
additional feature, because this will delay it by several weeks.

>   * If so, what syntax should we use?
>         - My choice would be the "package (>= 42 i386)" syntax,
> 	  as it's the least intrusive choice.

allright. But allow a seperator between version number and arch, like 
"(>= 42, i386)" that's a bit easier on the mind.
 	  
>   * Should we use four fields or six fields?
>         - In my opinion the four-field choice offers no real
> 	  advantages (I've discussed my position in detail earlier)

I think the six fields don't offer a real advantage over the four, but I have
no string feelings about this and either is fine for me.

>   * When are versioned dependencies necessary?
>       - Ian Jackson wants to allow the "current stable" as
> 	  the base where versioned dependencies are not
> 	  necessary

As stable changes, we would end up adding and removing version information in
each release. I don't see this happen (read: nobody will care and the
version info will stay even when a new stable is released), so I think in
practice most people will end up doing it the other way anyway:

> 	- I've stated my position earlier: use versioned dependencies
> 	  every time the non-versioned dependencies would introduce
> 	  a possibility of a broken build, regardless of releases.

> I'd like us to reach a consensus on these points during the week we have
> left.  If we can't, the proposal should be marked rejected.  (And possibly
> a new, revised proposal sent out, if necessary.)

As you see above, the only point that I definitely have a strong opinion
about is the arch specific source dependency. Other things I have
preferences, but either way will be fine for me.

Thanks for caring about this proposal,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Stefan Gybas <cab@studbox.uni-stuttgart.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #264 received at 41232@bugs.debian.org (full text, mbox):

From: Stefan Gybas <cab@studbox.uni-stuttgart.de>
To: Antti-Juhani Kaijanaho <gaia@iki.fi>, 41232@bugs.debian.org
Subject: Re: Bug#41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: Sat, 07 Aug 1999 14:21:17 +0200
Antti-Juhani Kaijanaho wrote:

>   * Are Build-Conflicts really necessary?
>         - they appear to be, reading the current list
>           of build-dependencies used by sbuild.

Yes, as Roman pointed out: lprng provides lpr but some package (I don't
remember which one it was) needs the real lpr to build, so you can't just
say Build-Depends: lpr.

I'll accept any choice for the other open points, so I hope we'll get
a consensus and accept the proposal (the sooner the better).

-- 
Stefan Gybas



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #269 received at 41232@bugs.debian.org (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Antti-Juhani Kaijanaho <gaia@iki.fi>, 41232@bugs.debian.org
Subject: Re: Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: Sat, 7 Aug 1999 16:08:56 +0200
On Sat, Aug 07, 1999 at 12:57:21PM +0300, Antti-Juhani Kaijanaho wrote:
> On Fri, Aug 06, 1999 at 05:00:27PM -0700, Joel Klecker wrote:
> > Well, I *need* that to represent glibc's source depends correctly.
> 
> Do you?

Yes, he does.
 
> > It'd be rediculous for a Debian GNU/HURD system to need 
> > "kernel-headers-2.2.10" to be installed for glibc's build depends to 
> > be satisfied, and equally rediculous for a Debian GNU/Linux system to 
> > need "hurd-dev" and "gnumach-dev" and "mig"(?).
> 
> These packages share the common function of containing headers (?) for
> the kernel, be it Linux or the Hurd.  Why is it then so appalling to
> have both package sets provide a suitable virtual package?
> 
> (I will be easily converted to your ways if you just convince me of this
> point ;-)

1. Those packages do NOT provide the same functionality. The gnumach-dev
   and hurd-dev headers are quite different from the linux kernel headers.
   Thus, they don't fit under the same virtual package. Although you will
   notice that both connect the C library to the underlying kernel and
   multi servers, they are not interchangeable.

   It could well be that the Hurd header files will be made available under
   Linux some day, when people are interested porting some of its interfaces to
   Linux for applications. Then the virtual package provided will give
   completely the wrong idea about the package.

2. The mig package provides an *executable* that does not have any meaning
   under current Linux systems (except MkLinux probably). I can't see how
   you would fit mig into this virtual package scheme at all.

To conclude, although I see a slight possibility why one could think of a
virtual package kernel-header that is provided by both gnumach-dev and
linux-kernel-headers, I don't see how this would solve the hurd-dev and mig
dependency of libc on the Hurd, and I don't really see why libc would
benefit from such a virtual package, as it would be necessarily meaningless
(as no two kernels provide exactly the same interface).

Furthermore, I wish you would not pin point this on the glibc package. I
already told you that further packages will require this feature. Are you
actually involved in any of our porting efforts? If not, it would be a
healthy experience ;), or at least check one of the mailing lists
frequently, to learn what is involved.

Don't forget that Debian is not Linux anymore, just as it is not i386
anymore for a long time now. Here is another example: To build the Linux
kernel on a i386, you need the bin86 package, on other platforms you don't.
This may actually be solved by virtual packages, but it is a lot easier just
to specify the correct architecture dependent source dependency.

A further point: Of course, you can solve ALL architecture related dependencies
problems by creating virtual dummy package. So, "dummy-0", "dummy-1" etc.
Do you think this is an adequate solution to this problem?

A very last point: Virtual packages require changes to multiple packages,
while source dependencies are local to a single package. So, everything that
helps keeping all relevant data inside the single package is very helpful in
the development process.

Are you converted now? :)

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #274 received at 41232@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
Cc: 41232@bugs.debian.org
Subject: Re: Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: Sat, 7 Aug 1999 17:33:32 +0300
On Sat, Aug 07, 1999 at 04:08:56PM +0200, Marcus Brinkmann wrote:
> Are you actually involved in any of our porting efforts?

No, as I don't have the required hardware.

> or at least check one of the mailing lists frequently, to learn what
> is involved.

I lurk on several Hurd lists, including debian-hurd.

> Don't forget that Debian is not Linux anymore

I'm not forgetting that.  But there is another point of trying to
make sure Debian is as same as possible in its all incarnations, in
one release.  Architecture-dependent build dependencies can lead into
forgetting that goal.  (Could we agree on a phrase in policy in the style
of "don't use the architecture-dependent build dependencies unless you
really have to"?)

> Are you converted now? :)

Possibly.  I see your point and I trust that you wouldn't put this much
effort to convince me if you didn't believe in what you're saying ;-)

-- 
%%% 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)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #279 received at 41232@bugs.debian.org (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Antti-Juhani Kaijanaho <gaia@iki.fi>, 41232@bugs.debian.org
Cc: Joel Klecker <jk@espy.org>
Subject: Re: Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: Sat, 7 Aug 1999 16:36:42 +0200
On Sat, Aug 07, 1999 at 12:57:21PM +0300, Antti-Juhani Kaijanaho wrote:
> On Fri, Aug 06, 1999 at 05:00:27PM -0700, Joel Klecker wrote:
> > Well, I *need* that to represent glibc's source depends correctly.
> 
> Do you?

I know that I already responded, but this is important enough for me to pull
all strings to kill the idea of using virtual packages for source
dependencies to make sure you don't get any funny ideas about it.

I'll bite and use the glibc package as a concrete example. But remember that
there will be much "worse" packages, too.

This is the situation:

=================================================
Linux:
glibc needs kernel-headers of a specific version.

GNU:
glibc needs gnumach-dev, hurd-dev, mig.
=================================================

Now you suggested that we use a virtual package "system-headers" which glibc
depends on.

==============================================
Package: glibc
Source-Depends: system-headers

Linux:
Package: kernel-headers
Provides: system-headers

GNU:
Package: hurd-dev
Provides: ?

Package: gnumach-dev
Provides: ?

Package: mig
Provides: ?
===============================================

Things start to get ugly. How do you fill in the blanks below to make sure
that all three packages are installed? Note that all three packages
hurd-dev, gnumach-dev and mig don't have any dependencies on each other, and
you shouldn't rely on indirect dependencies anyway.

Note that if either of these Provides: system-headers, glibc's
source-dependencies would be satisfied if only this package is installed, so
we need either need a dummy package or three virtual packages:

"Solution A":
==============================================================
Package: glibc
Source-Depends: system-headers

Linux: (as above)

GNU:
Package: hurd-dev
Provides: system-headers-1

Package: gnumach-dev
Provides: system-headers-2

Package: mig
Provides: system-build-utility     # (what the HACK is THAT?)

Package: system-headers  (an empty package)
Depends: system-headers-1, system-headers-2, system-build-utility
===============================================================

"Solution B":
=======================================================================
Package: glibc
Source-Depends: system-headers-1, system-headers-2, system-build-utility

Linux:
Package: kernel-headers
Provides: system-headers-1, system-headers-2, system-build-utility
                                            # ^^^ HUH???

GNU: (as Solution A, but without the empty system-headers package).
======================================================================

(You see, there are no names for the virtual packages that would make sense
on BOTH architectures. Now imagine different source dependencies on three or
four architectures!)

Neither "solution" is acceptable. Changing the dependencies would involve
action of several maintainers as well as the ftp archive maintainers (for
creation and deletion of dummy packages). Furthermore, the concept of
virtual packages is abused for a completely different matter, and does not
provide an intuitive understanding of the dependencies.

I don't object to use virtual packages where they are actually useful (for
example, source-depends on "awk" if any awk is sufficient (mawk, gawk,...).
But I think it is ridiculous to think that this will solve all problems.
It is obvious that avoiding architecture specification in the source
dependencies will simplify the proposal marginally at the very high costs for
the maintainers. But the idea of the source dependencies is to make life for
maintainers easier, not harder.

If I have still not convinced everybody of the urgent need for arhcitecture
specific build dependencies, I need to know which other solution could
address the points raisen in this and prior mail.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #284 received at 41232@bugs.debian.org (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Antti-Juhani Kaijanaho <gaia@iki.fi>, 41232@bugs.debian.org
Subject: Re: Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: Sat, 7 Aug 1999 16:53:55 +0200
(Note: I wrote my second reply before polling my mail, so it is a bit out of
sync to this mail :)

On Sat, Aug 07, 1999 at 05:33:32PM +0300, Antti-Juhani Kaijanaho wrote:
> On Sat, Aug 07, 1999 at 04:08:56PM +0200, Marcus Brinkmann wrote:
> > Are you actually involved in any of our porting efforts?
> 
> No, as I don't have the required hardware.

Then please trust the experience of porters like Joel, Roman and me in this
one point at least.

> > or at least check one of the mailing lists frequently, to learn what
> > is involved.
> 
> I lurk on several Hurd lists, including debian-hurd.
> 
> > Don't forget that Debian is not Linux anymore
> 
> I'm not forgetting that.  But there is another point of trying to
> make sure Debian is as same as possible in its all incarnations, in
> one release.

This is another story. It is definitely something to consider for the user
interface (same package management, same over-all design), but definitely
not at system level. Especially not at the level where you compile parts of
the low level operating system!

> Architecture-dependent build dependencies can lead into
> forgetting that goal.  (Could we agree on a phrase in policy in the style
> of "don't use the architecture-dependent build dependencies unless you
> really have to"?)

There are two things here. Of course, I don't want architecture specific
dependencies where a bug or source incompatibility is preventing compilation
of the package with a certain set of packages.

But for additional features only some supported operating systems can provide
I think it is a good idea to enable them and suck in further dependencies if
required.

For example, if a Hurd specific addition to the tar program (support for
translators) would make it necessary to link tar with the hurd libraries,
we need those libraries on the Hurd only.

I can understand your concern of "bad" use of arch specific source
dependencies, but I think I have two reasons why they won't be a big deal:

. The porter and the maintainer are often different persons. This raises the
barrier to add unnecessary source-dependencies and will make sure that more
than two eyes watch over it.
. In my experience, different source dependencies can hardly solve any
incompatibility problems on the user level.

Especially the first argument is very strong. Then, it is in everybodies
interest that the source dependencies are clean.

To answer your question: I think we can agree on such a phrase, but not in
the way you said it. There is no need to "discourage" proper use of arch
specific source dependencies. I am currently lacking some imagination. Can
anybody come up with a good wording?

Something like: "General source dependencies are preferred over architecture
specific dependencies". (to make it sound positive and not negative).

However, as we can't specify *when* arch specific source dependencies are
required, it doesn't matter much. I doubt that any such a phrase would have a
huge impact on the way arch specific source dependencies can be used. But it
does not harm to mention it either. So just do it :)

> > Are you converted now? :)
> 
> Possibly.  I see your point and I trust that you wouldn't put this much
> effort to convince me if you didn't believe in what you're saying ;-)

Definitely :) The real reason I am putting this pressure on you is that I am
leaving for holidays next tuesday, and won't come back in the discussion
time of this proposal.

Thanks,
Marcus
-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Richard Braakman <dark@xs4all.nl>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #289 received at 41232@bugs.debian.org (full text, mbox):

From: Richard Braakman <dark@xs4all.nl>
To: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>, 41232@bugs.debian.org
Cc: Antti-Juhani Kaijanaho <gaia@iki.fi>
Subject: Re: Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: Sat, 7 Aug 1999 19:57:38 +0200 (CEST)
Marcus Brinkmann wrote:
> >   * If so, what syntax should we use?
> >         - My choice would be the "package (>= 42 i386)" syntax,
> > 	  as it's the least intrusive choice.
> 
> allright. But allow a seperator between version number and arch, like 
> "(>= 42, i386)" that's a bit easier on the mind.

What happens if you want an architecture specifier but not a version
specifier?

I think something like
   package (>= 42) [i386]
would be better.  This cleanly separates two different things, and it allows
more flexibility in the architecture specifier.  We may want something
like [i386 m68k sparc] (for example, and altgcc dependency), and perhaps
even [!hurd-i386], and it will still look good.

Richard Braakman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #294 received at 41232@bugs.debian.org (full text, mbox):

From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
To: Richard Braakman <dark@xs4all.nl>, 41232@bugs.debian.org
Cc: Antti-Juhani Kaijanaho <gaia@iki.fi>
Subject: Re: Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: Sun, 8 Aug 1999 19:50:42 +0200
On Sat, Aug 07, 1999 at 07:57:38PM +0200, Richard Braakman wrote:
> Marcus Brinkmann wrote:
> > >   * If so, what syntax should we use?
> > >         - My choice would be the "package (>= 42 i386)" syntax,
> > > 	  as it's the least intrusive choice.
> > 
> > allright. But allow a seperator between version number and arch, like 
> > "(>= 42, i386)" that's a bit easier on the mind.
> 
> What happens if you want an architecture specifier but not a version
> specifier?

What's exactly wrong with "(i386)" or "(i386 alpha)" and so on?

Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to goswin.brederlow@student.uni-tuebingen.de:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #299 received at 41232@bugs.debian.org (full text, mbox):

From: goswin.brederlow@student.uni-tuebingen.de
To: Stefan Gybas <cab@studbox.uni-stuttgart.de>
Cc: 41232@bugs.debian.org, Antti-Juhani Kaijanaho <gaia@iki.fi>
Subject: Re: Bug#41232: AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: 09 Aug 1999 14:16:44 +0200
From: Stefan Gybas <cab@studbox.uni-stuttgart.de>

> Yes, as Roman pointed out: lprng provides lpr but some package (I
> don't remember which one it was) needs the real lpr to build, so you
> can't just say Build-Depends: lpr.

Does it run with lprng but only build with the real lpr? If so, its a
bug, that it doesn't compile and should be fixed. If it doesn't run or 
compile with lprng, it should depend on the real lpr.

In both cases the source-conflicts will work on the symptoms and not
on the cause.

But my opinion on source-conflicts is, that the same methods used for
dependencies should be extended to source, source-suggests and
source-recommends should be possible too.

source-suggests means, that you can build this package without, but
debian usually has it installed and source-recoments means that you
could build with that package installed, but debian usually builds
without. Or similar meanings.

If source-conflicts, source-recoments, source-suggests are not used at 
the moment, doesn't mean that they won't be neccessary soon and
allowing them doesn't hurd.

May the Source be with you.
                        Goswin


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #304 received at 41232@bugs.debian.org (full text, mbox):

From: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
To: goswin.brederlow@student.uni-tuebingen.de, 41232@bugs.debian.org
Cc: debian-policy@lists.debian.org
Subject: Re: Bug#41232: AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: Mon, 9 Aug 1999 14:34:13 +0200 (MET DST)
> Does it run with lprng but only build with the real lpr? If so, its
> a bug, that it doesn't compile and should be fixed. If it doesn't
> run or compile with lprng, it should depend on the real lpr.

I don't know if it runs with lprng.... But in any way, it can't depend
only on the real lpr, as lprng provides lpr!

> source-suggests means, that you can build this package without, but
> debian usually has it installed

This further complicates the build system... I guess you mean that
Build-Suggests packages should be installed for auto-builds, right?

> and source-recoments means that you could build with that package
> installed, but debian usually builds without.

Aiee... this is somewhat against the usual understanding of
"recommends", isn't it? :-)

IMHO we (...the source deps) should define *one* set of packages so
that results of recompilations are reproducible.

Roman


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to goswin.brederlow@student.uni-tuebingen.de:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #309 received at 41232@bugs.debian.org (full text, mbox):

From: goswin.brederlow@student.uni-tuebingen.de
To: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>
Cc: 41232@bugs.debian.org, debian-policy@lists.debian.org
Subject: Re: Bug#41232: AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: 09 Aug 1999 18:12:18 +0200
From: Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>

>> Does it run with lprng but only build with the real lpr? If so, its
>> a bug, that it doesn't compile and should be fixed. If it doesn't
>> run or compile with lprng, it should depend on the real lpr.

> I don't know if it runs with lprng.... But in any way, it can't
> depend only on the real lpr, as lprng provides lpr!

So the bug seems to be with lprng, since it doesn't provide lpr
completly. Maybe a virtual package is needed there.

>> source-suggests means, that you can build this package without, but
>> debian usually has it installed

> This further complicates the build system... I guess you mean that
> Build-Suggests packages should be installed for auto-builds, right?

Yes, they should be installed and the auto-build demons should treat
suggest just as depends. But maybe someone wants or needs a minimal
system, so he wants to build packages with less features, disabling
gif, png, tiff ... for gimp for example.

>> and source-recoments means that you could build with that package
>> installed, but debian usually builds without.

> Aiee... this is somewhat against the usual understanding of
> "recommends", isn't it? :-)

Yeah, recommends might be the wrong word, source-possible or
source-leftout could be better. dpkg-source -x should warn when those
are installed, since those should not be installed for a "pure" debian 
package. Autobuild demons should treat those as source-conflicts.

> IMHO we (...the source deps) should define *one* set of packages so
> that results of recompilations are reproducible.

There might be packages that can be compiled with additional features
(like xanim), but those are not part of debian. The Debian package
would be build without those features, but the user might want to
compile them in as well. A source-recommends, source-possible or
source-leftout would give the needed hints what package he needs to
install to get those unusual features, e.g. compile xanim with
additional non-free codecs.

May the Source be with you.
                        Goswin


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #314 received at 41232@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: 41232@bugs.debian.org
Subject: Re: Bug#41232: [AMENDMENT 1999-07-23 FINAL DRAFT] Build-time dependencies on binary packages
Date: Thu, 12 Aug 1999 04:45:01 +0300
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)


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Kristoffer.Rose@ens-lyon.fr:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #319 received at 41232@bugs.debian.org (full text, mbox):

From: Kristoffer.Rose@ENS-Lyon.FR
To: gaia@iki.fi, 41232@bugs.debian.org
Subject: Bug#41232: AMENDMENT 1999-07-23 FINAL DRAFT] Build-time dependencies on binary packages
Date: Thu, 12 Aug 1999 15:26:26 +0200 (CEST)
Antti-Juhani proposes:

> 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.)
>...

Thanks for a very thought out proposal!  Please, let us go for it: debian
has been without source dependencies for far too long.

Best,
	Kristoffer

PS. In case you are wondering: I know because I was offered in 1993 by Ian
Murdock to "take over the source package format of debian", an offer I
unfortunately had to decline due to lack of hardware (!) ... but I do
remember the lively discussion at the time and can only say that this
proposal does address all the concerns I remember from way back then :)
-- 
Kristoffer Høgsbro Rose, phd, prof.associé  <http://www.ens-lyon.fr/~krisrose>
addr. LIP, Ecole Normale Supérieure de Lyon, 46 Allée d'Italie, F-69364 Lyon 7
phone +33(0)4 7272 8642, fax +33(0)4 7272 8080   <Kristoffer.Rose@ENS-Lyon.FR>
pgp f-p: A4D3 5BD7 3EC5 7CA2 924E D21D 126B B8E0   <krisrose@{debian,tug}.org>


Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #324 received at 41232@bugs.debian.org (full text, mbox):

From: Antti-Juhani Kaijanaho <gaia@iki.fi>
To: 41232@bugs.debian.org
Subject: Bug#41232: debian-policy: [ACCEPTED] Build-time dependencies on binary packages
Date: Mon, 16 Aug 1999 20:36:43 +0300
retitle 41232 [ACCEPTED] Build-time dependencies on binary packages
forwarded 41232 debian-policy@lists.debian.org
thanks

I think it is safe to say this amendment is accepted.  If you don't agree,
speak up *now*.

-- 
%%% 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)


Changed bug title. Request was from Antti-Juhani Kaijanaho <gaia@iki.fi> to control@bugs.debian.org. Full text and rfc822 format available.

Noted your statement that bug has been forwarded to debian-policy@lists.debian.org. Request was from Antti-Juhani Kaijanaho <gaia@iki.fi> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#41232; Package debian-policy. Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ian@davenant.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. Full text and rfc822 format available.

Message #333 received at 41232@bugs.debian.org (full text, mbox):

From: Ian Jackson <ian@davenant.greenend.org.uk>
To: 41232@bugs.debian.org
Subject: Re: Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies on binary packages
Date: Tue, 17 Aug 1999 20:29:53 +0100 (BST)
Richard Braakman writes ("Bug#41232: Bug #41232: [AMENDMENT 1999-07-23] Build-time dependencies  on binary packages"):
...
> I think something like
>    package (>= 42) [i386]
> would be better.  This cleanly separates two different things, and it allows
> more flexibility in the architecture specifier.  We may want something
> like [i386 m68k sparc] (for example, and altgcc dependency), and perhaps
> even [!hurd-i386], and it will still look good.

I agree.  Overloading the () metacharacters is a bad idea.

Ian.


Severity set to `fixed'. Request was from Julian Gilbey <jdg@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Reply sent to Julian Gilbey <J.D.Gilbey@qmw.ac.uk>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Antti-Juhani Kaijanaho <gaia@iki.fi>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #340 received at 41232-done@bugs.debian.org (full text, mbox):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>
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
Subject: Fixed in debian-policy 3.1.0.0
Date: Sat, 6 Nov 1999 21:13:58 +0000 (GMT)
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


Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 02:47:22 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.