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

classic Classic list List threaded Threaded
11 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]

Reply | Threaded
Open this post in threaded view
|

Bug#345619: marked as done (build-arch and build-indep targets should be required)

Debian Bug Tracking System
In reply to this post by Kari Pahula-2
Your message dated Wed, 19 Sep 2012 06:32:10 +0000
with message-id <[hidden email]>
and subject line Bug#374029: fixed in debian-policy 3.9.4.0
has caused the Debian Bug report #374029,
regarding build-arch and build-indep targets should be required
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 [hidden email]
immediately.)


--
374029: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374029
Debian Bug Tracking System
Contact [hidden email] with problems

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


Source: debian-policy
Source-Version: 3.9.4.0

We believe that the bug you reported is fixed in the latest version of
debian-policy, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [hidden email],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Russ Allbery <[hidden email]> (supplier of updated debian-policy package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [hidden email])


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Tue, 18 Sep 2012 21:35:36 -0700
Source: debian-policy
Binary: debian-policy
Architecture: source all
Version: 3.9.4.0
Distribution: unstable
Urgency: low
Maintainer: Debian Policy List <[hidden email]>
Changed-By: Russ Allbery <[hidden email]>
Description:
 debian-policy - Debian Policy Manual and related documents
Closes: 374029 571776 591791 641153 654958 661816 661933 663918 670429 676561
Changes:
 debian-policy (3.9.4.0) unstable; urgency=low
 .
   * build-arch and build-indep are now mandatory targets in debian/rules,
     implementing the Technical Committee ruling in #629385.  Wording
     review by Jonathan Nieder, Jakub Wilk, and Roger Leigh.
     (Closes: #374029)
   * Resynchronize the archive section list with ftp-master, adding tasks.
     Patch from Charles Plessy.  (Closes: #670429)
   * Policy: Copyright files must be encoded in UTF-8
     Wording: Russ Allbery <[hidden email]>
     Seconded: Guillem Jover <[hidden email]>
     Seconded: Salvatore Bonaccorso <[hidden email]>
     Seconded: Simon McVittie <[hidden email]>
     Closes: #661933
   * Policy: Prohibit deprecated < and > relations
     Wording: Jakub Wilk <[hidden email]>
     Seconded: Cyril Brulebois <[hidden email]>
     Seconded: Russ Allbery <[hidden email]>
     Closes: #663918
   * Policy: Document the Built-Using field
     Wording: Charles Plessy <[hidden email]>
     Seconded: Russ Allbery <[hidden email]>
     Seconded: Ansgar Burchardt <[hidden email]>
     Closes: #641153
   * Policy: Document the Vcs-* fields
     Wording: Charles Plessy <[hidden email]>
     Wording: Jonathan Nieder <[hidden email]>
     Seconded: Russ Allbery <[hidden email]>
     Seconded: Charles Plessy <[hidden email]>
     Seconded: Guillem Jover <[hidden email]>
     Closes: #654958
   * Policy: Document restrictions on the use of /run for wheezy
     Wording: Roger Leigh <[hidden email]>
     Seconded: Charles Plessy <[hidden email]>
     Seconded: Russ Allbery <[hidden email]>
     Closes: #676561
   * Policy: Rewrite shared library dependency policy to document symbols
     Wording: Russ Allbery <[hidden email]>
     Wording: Jonathan Nieder <[hidden email]>
     Seconded: Raphaël Hertzog <[hidden email]>
     Seconded: Julien Cristau <[hidden email]>
     Closes: #571776
   * Policy: Document generic and upstart-specific init system requirements
     Wording: Steve Langasek <[hidden email]>
     Seconded: Russ Allbery <[hidden email]>
     Seconded: Adam D. Barratt <[hidden email]>
     Closes: #591791
   * Policy: Rely on triggers instead of calling update-mime
     Wording: Charles Plessy <[hidden email]>
     Seconded: Russ Allbery <[hidden email]>
     Seconded: Guillem Jover <[hidden email]>
     Closes: #661816
Checksums-Sha1:
 c728495994bbdabc43055dfbedfd662bba5eb069 1518 debian-policy_3.9.4.0.dsc
 4c6bc2d0eb510313e1b4a0d2a932f4182ffe6f91 704838 debian-policy_3.9.4.0.tar.gz
 ac9ff5a5987343a736fb45af52d3178bae30d37e 2147892 debian-policy_3.9.4.0_all.deb
Checksums-Sha256:
 c6dbad5976931268283c02903cf0dc3f3bb8dfc86710cab462e0e6c19aab1407 1518 debian-policy_3.9.4.0.dsc
 01ae1a19f7a251dd5c2b078736427f33f04c5f7e38308f874345f1e3e194dca5 704838 debian-policy_3.9.4.0.tar.gz
 c6e22f66e4cd38cbfac944bfebb41fa5608604326c6ecb9dbbd2213f5372ebbd 2147892 debian-policy_3.9.4.0_all.deb
Files:
 e5683a409d1f740582e960158152b4ba 1518 doc optional debian-policy_3.9.4.0.dsc
 33eafa60a7c79f827adaa1bdb0cdcf83 704838 doc optional debian-policy_3.9.4.0.tar.gz
 2c5c278e5035e26489c3ae76f8c428d2 2147892 doc optional debian-policy_3.9.4.0_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJQWVEqAAoJEH2AMVxXNt51CfcH/226voYDWjhFjwJJh61d0XBI
3JRRYNqF7rZ59zl4kwEX+QFe/CoKnX1rEceBb9g3cCJ/AO6vU8Z+hhGnpr4eus1v
2BKhO4E8S6vqjtWfiXHIUmkIlGQeuxY3aBMWNZPgQzqEz9Skrc3aDel3zuuiKehE
fTk8Kse0hwTGp5h9nVaXawdZEPKFhcQT2NrhhTE/VmTHuC1EzUTcjOUDeu8tM2xy
r6Zjytz43qqvWinUQNYQXOtjt2zAVV0dw6T9nWcssXOSTD1EZLbfAbaJw9m1VG6G
B9BRhz5xs334/DktrgDw2gKjb4IF2tI3lIPRj12OuGErR+lChgZr4egrA+xyBwM=
=SP2c
-----END PGP SIGNATURE-----