Bug#345619: debian-policy: 4.8. binary-{arch, indep} should fail with error code 2 -> must

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#345619: debian-policy: 4.8. binary-{arch, indep} should fail with error code 2 -> must

Kari Pahula-2
Package: debian-policy
Version: 3.6.2.1
Severity: wishlist

Debian policy 4.8. states:
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.

I'm proposing that this would be changed to "must produce".
debian/rules binary-* has the bits requiring root privileges and
build-* has the steps that can be done without.  As such, debian/rules
build-* is often called explicitly before $rootcommand debian/rules
binary-*.

But, since it's not a requirement for debian/rules build-{arch,indep}
to return an error when the targets are missing, tools such as
dpkg-buildpackage have no choice but to always call debian-rules build
even when building arch dependent packages.

If it was required that the missing rules returned an exit status,
dpkg-buildpackage could try debian/rules build-arch first and then
debian/rules build if that failed.

An alternative would be to require that build-{arch,indep} are always
present and both depending on build target, just like already done
with binary-* targets.  But that would require larger changes.

As they are now, build-{arch,indep} targets are less useful than what
they could be.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

-- no debconf information


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#345619: debian-policy: 4.8. binary-{arch, indep} should fail with error code 2 -> must

Ian Jackson
Kari Pahula writes ("Bug#345619: debian-policy: 4.8. binary-{arch, indep} should fail with error code 2 -> must"):
> Debian policy 4.8. states:
> 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.

Unfortunately there are some problems with this approach.

* Firstly, we would have to specify that the exit status 2 must _not_
be used other than when the target does not exist.  This would involve
overhauling all of the rules files anyway (in which case we might as
well add the relevant target).

* Secondly, rules files are generally makefiles and make doesn't allow
the makefile to manipulate make's exit status.

> An alternative would be to require that build-{arch,indep} are always
> present and both depending on build target, just like already done
> with binary-* targets.  But that would require larger changes.

I think this would be a better idea (although of course you mean that
`build' should depend on both of the new targets, not vice versa).
You could check the Standards-Version header to see if you want to use
the new target.

Ian.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#345619: debian-policy: 4.8. binary-{arch, indep} should fail with error code 2 -> must

Kari Pahula
On Tue, Jan 03, 2006 at 02:34:45PM +0000, Ian Jackson wrote:
> Kari Pahula writes ("Bug#345619: debian-policy: 4.8. binary-{arch, indep} should fail with error code 2 -> must"):
> > Debian policy 4.8. states:
> > 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.
>
> Unfortunately there are some problems with this approach.

I agree, it feels like a hack.

> > An alternative would be to require that build-{arch,indep} are always
> > present and both depending on build target, just like already done
> > with binary-* targets.  But that would require larger changes.
>
> I think this would be a better idea (although of course you mean that
> `build' should depend on both of the new targets, not vice versa).

Let me elaborate a bit.  The most important thing would be to make it
a requirement for build-{arch,indep} targets to be present.  Even if
they were empty.  They may be implemented by depending on build, which
would build both the arch and indep parts.  And build, in turn, may be
implemented by depending on build-arch and build-indep, if the
respective parts of the build process are properly separated to those
targets.  But obviously both of the above can't hold at the same time.

But all of the above are just implementation details.  The important
change would be to make it a requirement for build-{arch,indep} to be
present.

> You could check the Standards-Version header to see if you want to use
> the new target.

Right, and the change would be backwards compatible too.  It will not
break anything if older tools still do make build even if there was
the more specific build-{arch,indep} target available.

The reason why I got to think about this policy change was because I
noticed that every arch's buildd was calling my build-indep and having
doxygen generate 30 MBs of docs.  I was suggested on IRC to either
generate the docs in binary-indep or ask for a policy change.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#345619: debian-policy: 4.8. binary-{arch, indep} should fail with error code 2 -> must

Russ Allbery-2
Kari Pahula <[hidden email]> writes:

> But all of the above are just implementation details.  The important
> change would be to make it a requirement for build-{arch,indep} to be
> present.

The difficulty with this sort of change is that it requires changing every
Debian package, or near to.  I'm going to have the same problem with
building the bearoff database in gnubg, so I'm quite willing to do my part
and add build-{arch,indep} to all my packages, but that still leaves tens
of thousands to go.

Generally policy doesn't change until the change has mostly been
implemented in practice.

I'm not entirely sure how one does go about making a change like this.
Get consensus on debian-devel, send a note to debian-devel-announce asking
everyone to change their packages, and get a test into lintian?

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#345619: debian-policy: 4.8. binary-{arch, indep} should fail with error code 2 -> must

Kari Pahula
On Wed, Jan 04, 2006 at 10:30:04AM -0800, Russ Allbery wrote:
> Kari Pahula <[hidden email]> writes:
>
> > But all of the above are just implementation details.  The important
> > change would be to make it a requirement for build-{arch,indep} to be
> > present.
>
> The difficulty with this sort of change is that it requires changing every
> Debian package, or near to.  I'm going to have the same problem with

As far as changes go, this one can be minimally implemented by adding
these two lines to debian/rules:
build-arch: build
build-indep: build

Lintian can trivially catch the vast majority of missing targets by
running
make -n -f debian/rules build-arch build-indep >/dev/null || echo boo!

Plus, any package that follows this policy will look just the same to
any program that doesn't know about it.  debian/rules build will still
do the exact same thing.  Only if a tool wants to depend on build-*
being present will it have to check the standards-version of the
package.

IMHO this would be sufficient as a transition plan:
for next major patchlevel of policy:
 * build-arch and build-indep targets should be implemented
 * have a lintian warning if they're missing

for the next minor version:
 * build-arch and build-indep must be implemented
 * lintian error if they're missing


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#345619: debian-policy: 4.8. binary-{arch, indep} should fail with error code 2 -> must

Russ Allbery-2
Kari Pahula <[hidden email]> writes:
> On Wed, Jan 04, 2006 at 10:30:04AM -0800, Russ Allbery wrote:

>> The difficulty with this sort of change is that it requires changing
>> every Debian package, or near to.  I'm going to have the same problem
>> with

> As far as changes go, this one can be minimally implemented by adding
> these two lines to debian/rules:
> build-arch: build
> build-indep: build

Oh, it's incredibly trivial, sure.  The *difficulty* of the change isn't
the issue.  Installing documentation in /usr/share/doc instead of /usr/doc
is incredibly trivial as well.  :)  (Admittedly, this is even more
trivial, but you see the point.)

> Lintian can trivially catch the vast majority of missing targets by
> running
> make -n -f debian/rules build-arch build-indep >/dev/null || echo boo!

Oh, yeah, that's right, debian/rules is required to be a makefile now.
Yeah, I don't think the lintian probe would be too hard.

I just don't know how this sort of change fits into the policy process.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#345619: debian-policy: 4.8. binary-{arch, indep} should fail with error code 2 -> must

Kari Pahula
On Wed, Jan 04, 2006 at 01:56:13PM -0800, Russ Allbery wrote:
> I just don't know how this sort of change fits into the policy process.

How about this: change the policy to state that build-arch and
build-indep should be present, make it a lintian warning if they're
missing and defer any decision to make it a requirement until they're
widely implemented.

Lintian warning reports for all packages are already readily
available.  Checking those and that the packages' standards-version is
high enough to trigger this particular warning should give a decent
picture of how many packages are still missing the targets.

Besides, it's not like there's a need to have as a goal to have each
and every package in the archive to implenent build-{arch,indep}, if
any tools that use those targets will check the standards-version too.
Of course, if the standards-version of every package in the archive
ever gets high enough, that check can be dropped, too.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#345619: debian-policy: 4.8. binary-{arch, indep} should fail with error code 2 -> must

Bill Allombert-3
In reply to this post by Kari Pahula-2
On Mon, Jan 02, 2006 at 11:44:21AM +0200, Kari Pahula wrote:

> But, since it's not a requirement for debian/rules build-{arch,indep}
> to return an error when the targets are missing, tools such as
> dpkg-buildpackage have no choice but to always call debian-rules build
> even when building arch dependent packages.
>
> If it was required that the missing rules returned an exit status,
> dpkg-buildpackage could try debian/rules build-arch first and then
> debian/rules build if that failed.
>
> An alternative would be to require that build-{arch,indep} are always
> present and both depending on build target, just like already done
> with binary-* targets.  But that would require larger changes.
>
> As they are now, build-{arch,indep} targets are less useful than what
> they could be.

Before going farther, I strongly recommends you read the
bug log for #218893.

Cheers,
Bill.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#345619: debian-policy: 4.8. binary-{arch, indep} should fail with error code 2 -> must

Adeodato Simó-4
In reply to this post by Kari Pahula
* Kari Pahula [Wed, 04 Jan 2006 11:37:46 +0200]:

> The reason why I got to think about this policy change was because I
> noticed that every arch's buildd was calling my build-indep and having
> doxygen generate 30 MBs of docs.  I was suggested on IRC to either
> generate the docs in binary-indep or ask for a policy change.

  Or move doxygen from Build-Depends to Build-Depends-Indep, and
  gracefully ignore its absence in the "build" target, if possible.

--
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
Y sobre todo, tienes mucho de gilipollas.
                -- B.C.S. addressing P.G.i.Q in b8g



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#345619: debian-policy: 4.8. binary-{arch, indep} should fail with error code 2 -> must

Kari Pahula
In reply to this post by Bill Allombert-3
On Thu, Jan 05, 2006 at 11:23:43AM +0100, Bill Allombert wrote:
> Before going farther, I strongly recommends you read the
> bug log for #218893.

Good to see that this has been discussed before.

IMHO the sanest thing would be to make build-{arch,indep} goals
mandatory.  It would make build-arch target useful for buildds and is
the most robust and simplest of the solutions I've seen so far.  An
added benefit would be to have all the build targets be symmetrical
with the binary targets.

The obvious con of the change would be the transition required.  But,
as the effects of the change would only touch infrastructure invisible
to users, I don't see a need to set any deadlines for this transition
to happen.  I'd propose the following change, let the transition
happen on its own pace, and if it ever seems to be close to
completion, change the policy to reflect that.

IMHO that last "must" part would be justified too.  There's no robust
way of checking for the targets' presence right now.

Would there be a need to state explicitly that packages may implement
build-{arch,indep} by depending on build target?  The main issue is to
get those targets in there, not to optimize builds for every package.

--- policy.sgml 2006-01-05 23:32:04.000000000 +0200
+++ policy.sgml.new 2006-01-05 23:40:34.659324743 +0200
@@ -1839,21 +1839,21 @@
       </p>
     </item>
 
-    <tag><tt>build-arch</tt> (optional),
- <tt>build-indep</tt> (optional)
+    <tag><tt>build-arch</tt>,
+ <tt>build-indep</tt>
     </tag>
     <item>
       <p>
- A package may also provide both of the targets
+ A package should also provide both of the targets
  <tt>build-arch</tt> and <tt>build-indep</tt>.
- The <tt>build-arch</tt> target, if provided, should
+ The <tt>build-arch</tt> target should
  perform all the configuration and compilation required
  for producing all architecture-dependant binary packages
  (those packages for which the body of the
  <tt>Architecture</tt> field in <tt>debian/control</tt>
  is not <tt>all</tt>).
- Similarly, the <tt>build-indep</tt> target, if
- provided, should perform all the configuration and
+ Similarly, the <tt>build-indep</tt> target
+ should perform all the configuration and
  compilation required for producing all
  architecture-independent binary packages
  (those packages for which the body of the
@@ -1865,12 +1865,9 @@
       </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.
+        Not having <tt>build-arch</tt> and
+        <tt>build-indep</tt> is deprecated.  Programs must
+        not depend on having these targets available.
       </p>
 
       <p>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]