Bug#604397: debian-policy: require build-arch and build-indep targets
On Mon, 2011-06-06 at 13:37:22 +0200, Bill Allombert wrote:
> On Mon, Jun 06, 2011 at 09:55:25AM +0200, Guillem Jover wrote:
> > > To help no existing packages today but make it easy for packages
> > > to opt in (and not break the others):
> > >
> > > 1. Introduce a Build-Options facility for packages to advertise
> > > capabilities like this.
> > > 2. Teach dpkg-buildpackage to honor it.
> >
> > I don't think Build-Options/Build-Features is a good idea, as stated
> > previously on these bug reports. For example most of my packages
> > already support build-arch/build-indep, now I have to also state that
> > explicitly? Buh. :)
>
> Only for packages that would benefit from it, i.e. packages that generates
> both arch-indep and arch-all packages and have large Build-Depends-Indep
> dependencies.
On my previous mail I already listed the only cases where it really
makes sense, and dpkg-dev already has the information to decide when
that's the case, and it could activate build-arch/build-indep
unconditionally on these cases.
> This stays an optional feature. No need to add it everywhere.
And to me that's one of the problems with Build-Options/Features,
another being the duplicated information. If we consider
build-arch/build-indep something useful enough to be widely usable
on all packages producing arch:any + arch:all packages, then making
this optional is close to keeping status quo, I expect a multi-year
period to make a dent on packages adding support for this, if at all.
(There's still packages using Source-Version substvar and a substantial
difference is that's known to break binNMUs, it was introduced around
2007...)
If this is considered only useful to a handful of packages, then
really, what's the point of all the discussions? All that energy
could have been used in NMUs instead.
regards,
guillem
Reply to: