Bug#604397: Request for TC to rule on a course of action for supporting build-arch
On Mon, Jun 06, 2011 at 03:37:07PM +0100, Roger Leigh wrote:
> On Mon, Jun 06, 2011 at 03:59:15PM +0200, Bill Allombert wrote:
> > On Mon, Jun 06, 2011 at 12:09:34PM +0200, Bill Allombert wrote:
> > > On Mon, Jun 06, 2011 at 02:15:37AM -0700, Steve Langasek wrote:
> > > > 1) Implement support for calling 'debian/rules build-arch' in place of
> > > > 'debian/rules build' by checking for the presence of the target using
> > > > 'make -qn'.[1]
> > > >
> > > > 2) Implement support for calling 'debian/rules build-arch' with a fallback
> > > > to 'debian/rules build' by checking whether the output of the build-arch
> > > > target matches that of a dummy target.[2]
> > > >
> > > > 3) Implement support for calling 'debian/rules build-arch' in place of
> > > > 'debian/rules build' if a Build-Options field is set in debian/control
> > > > of the source package specifying that this target is supported.[3]
> > >
> > > For the record, I have been working to the patch that implement 3) to get accepted,
> > > see bug #229357.
> >
> > Still for the record this patch has been accepted in dpkg as of today:
> > http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=14d48ef
> > Does that make this bug moot for all concerned ?
> >
> > I plan to repropose #218893 with updated wording to match this dpkg change.
>
> This is great, thanks for doing this!
Thanks for your support. I have been fighting for ten years to get that issue
fixed.
> The question to consider here is whether or not this particular build
> feature is "transitional" or if it will remain indefinitely.
>
> Needing to explicitly enable a target that should be the default is
> something I'm not that happy with. While it's fine to do this as a
> means of transitioning with minimal breakage, and I'm totally OK with
> this as a means of getting the transition done, I would prefer it not
> be a requirement in perpetuity. Once the archive has sufficient
> coverage to make mandating the targets a realistic possibility, I
> would be all for making it mandatory.
If you read the original discussion in bug #218893, a lot of developers were
unhappy with having to add a build-arch target to packages that only build a
single kind of package (all arch-all or all arch-indep) or which did not have a
Build-Depends-Indep field, because this was useless, so this leads to the
proposal for an optional build feature. The dpkg developers at the time were
also very much concerned with preserving backward compatibility. So this is
a compromise solution. As such I would suggest we deploy it and then we can
discuss whether there is a consensus to make build-arch mandatory.
> We don't currently have an option to build /only/ binary-indep
> packages, but this might be useful for arch-all autobuilding if we
> don't want to build them at the same time as for binary-arch.
> In this case, would we still want to install Build-Depends and
> Build-Depends-Indep? (I would think so.)
There is such option now: dpkg-buildpackage -A.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: