Bug#218893: Proposal: debian/rules.version file [Fix for the build-arch problem]
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 -->
Reply to: