[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#218893: marked as done (Add Build-Options control field)

Your message dated Fri, 11 Aug 2017 07:53:51 -0700
with message-id <87o9rmxiio.fsf@iris.silentflame.com>
and subject line Done in a recent release
has caused the Debian Bug report #218893,
regarding Add Build-Options control field
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
218893: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=218893
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: debian-policy
Version: 3.6.1

Hello Debian policy,

I would like to fix the problem with Build-Depends-Indep and buid-arch
in current policy.

1) Background:

1.1) Current policy defines two optional debian/rules targets
'build-arch' and 'build-indep'.

1.2) Policy state that

          If one or both of the targets `build-arch' and `build-indep' are
          not provided, then invoking `debian/rules' with one of the
          not-provided targets as arguments should produce a exit status
          code of 2.  Usually this is provided automatically by make if the
          target is missing.

1.3) Dpkg developer Adam Heath tried to implement the recipe above in
dpkg-buildpackage but reverted it since it was broken. The problem is
that 'debian/rules build-arch' can produce an exit status code of 2 even
if the target is available. GNU make manual state that 

     The exit status is two if `make' encounters any errors.  It will
     print messages describing the particular errors.

1.4) dpkg-buildpackage -B call 'debian/rules build' and then
'debian/rules binary-arch'. Policy 7.6 mandate that both 'Build-Depends'
and 'Build-Depends-Indep' dependencies be satisfied when 'debian/rules
build' is called, making the split useless.

1.5) The buildd software only install Build-Depends and not
Build-Depends-Indep. Due to 1.4, this leads to build failures.

1.6) Policy 7.6 defines the Build-Depends/Build-Depends-Indep split in
term of use of debian/rules target, not in term of which kind of packages are 
to be build (i.e. Arch: any or all).

2) Analysis

There are several problems intertwined here:

2.1) The recipe given in policy to detect whether optional targets are
available is not reliable.

2.2) buildd make a false assumption on the behaviour of dpkg-buildpackage

2.3) Even if it were correct, it would not be correct due to 1.6: buildd
must know if build-arch is available to decide whether
Build-Depends-Indep need to be installed. Look at the following example:

  Package has both Build-Depends and Build-Depends-Indep, but no
  build-arch target. This is acceptable according to policy. However
  policy require that both Build-Depends and Build-Depends-Indep be
  installed when building binary-arch packages since the 'build' target
  will be called.

3) Solution:
3.1) Provide an easy and reliable way to tell if the optional targets 
are implemented.
3.2) Change dpkg-buildpackage to make use of this information
3.3) Change buildd to make use of this information.
( Though one could argue that buildd should not make assumption on
dpkg-buildpackage behaviour. )

Only 3.1 is relevant to policy.

I propose two alternative (attached, sorry for the SGML patches).

Choose one:

The first is to add a debian/rules.version with meaning:
debian/rules.version is present and is "1\n": build-arch and build-indep
are implemented

The second is to add a debian/rules.targets with the list of available
optional targets.

First solution is easier to implement.  Second one scale better but does not
allow to revoke the meaning of a target.

If you are going to second this proposal, please state if you prefer
debian/rules.version or debian/rules.targets.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

--- /home/bill/debian/debian/policy.sgml	Wed Oct 29 22:49:42 2003
+++ /home/bill/debian/debian/policy.sgml.new	Wed Oct 29 23:54:20 2003
@@ -1856,15 +1856,6 @@
 	      </p>
 
 	      <p>
-		If one or both of the targets <tt>build-arch</tt> and
-		<tt>build-indep</tt> are not provided, then invoking
-		<file>debian/rules</file> with one of the not-provided
-		targets as arguments should produce a exit status code
-		of 2.  Usually this is provided automatically by make
-		if the target is missing.
-	      </p>
-
-	      <p>
 		The <tt>build-arch</tt> and <tt>build-indep</tt> targets
 		must not do anything that might require root privilege.
 	      </p>
@@ -2031,6 +2022,27 @@
 	  or system information; the GNU style variables should be
 	  used for that.
 	</p>
+      </sect>
+      <sect id="debianrulesversion">
+      <heading>Optional rules version file:
+      <file>debian/rules.version</file></heading>
+      <p>
+      If this file is present, it must contain an integer followed
+      by a newline character.
+      This integer is called the rules version.
+      If this file is not present, the version is defined as being <tt>0</tt>.
+      Currently two versions are defined
+      <list compact="compact">
+      <item> <tt>0</tt>: <file>debian/rules</file> implement <em>clean</em>,
+      <em>binary</em>, <em>binary-arch</em>, <em>binary-indep</em>, and
+      <em>build</em>. 
+                          
+      </item> <item> <tt>1</tt>: As version <tt>0</tt>, but it also
+      implements the targets <em>binary-arch</em> and <em>binary-indep</em>.
+      
+      </item> 
+      </list>
+      </p>
       </sect>
 
 <!-- FIXME: section pkg-srcsubstvars is the same as substvars -->

--- /home/bill/debian/debian/policy.sgml	Wed Oct 29 22:49:42 2003
+++ /home/bill/debian/debian/policy.sgml.new2	Wed Oct 29 23:55:06 2003
@@ -1856,15 +1856,6 @@
 	      </p>
 
 	      <p>
-		If one or both of the targets <tt>build-arch</tt> and
-		<tt>build-indep</tt> are not provided, then invoking
-		<file>debian/rules</file> with one of the not-provided
-		targets as arguments should produce a exit status code
-		of 2.  Usually this is provided automatically by make
-		if the target is missing.
-	      </p>
-
-	      <p>
 		The <tt>build-arch</tt> and <tt>build-indep</tt> targets
 		must not do anything that might require root privilege.
 	      </p>
@@ -2031,6 +2022,15 @@
 	  or system information; the GNU style variables should be
 	  used for that.
 	</p>
+      </sect>
+      <sect id="debianrulestargets">
+      <heading>Optional rules targets file:
+      <file>debian/rules.targets</file></heading>
+      <p>
+      If this file is present, it must contain a newline separated list 
+      of targets amongst the ones defined as <em>optional</em> above 
+      effectively supported by the corresponding <file>debian/rules</file>.
+      </p>
       </sect>
 
 <!-- FIXME: section pkg-srcsubstvars is the same as substvars -->

--- End Message ---
--- Begin Message --- 
Version: 3.9.4.0

We believe this was fixed in a recent release.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: