Re: Bug#604397: Request for TC to rule on a course of action for supporting build-arch
Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr> writes:
> I have proposed an alternative in the past (which did not get any
> support, though): Decide that packages that have a Build-Depends-Indep:
> field must implement build-arch/build-indep. This is probably already
> the case.
> This has the same advantage than Build-Options: a program can check if
> dpkg-buildpackage will call build-arch just by looking at the control
> file.
This is a hack, though, that relies on the assumption that any package
with separate build-arch and build-indep targets will have additional
dependencies for build-indep. This is not necessarily true. For example,
building architecture-independent bearoff databases for GnuBG doesn't
require any additional packages.
> There should be a well-defined interface to know whether
> dpkg-buildpackage will call build-arch or build, that does not depend on
> a specific dpkg-buildpackage implementation.
I don't agree with this statement in the long run. I don't see any reason
not to have a goal of having dpkg-buildpackage call build-arch
unconditionally. The most maintainable, most easily testable, and least
complex way to implement an option in a software system is to not make it
an option.
My goal is to allow everyone developing for Debian three years from now to
not care that this debate ever happened.
> Concerning the long-term complexity: If you look at the bug log, you
> will see that developpers objected that the build-arch/build-indep split
> was unnecessary complexity for packages that would not get any benefit
> of it, so Build-Options was proposed which allowed the split to be
> optional (so only packages that get some benefit of it would have to
> implement it).
I think that the dh program and its widespread adoption has mostly made
that objection obsolete. For those who are still listing separate targets
in debian/rules, making build-arch and build-indep just depend on build is
not generally difficult.
> (PS: I am unsure how this bug fit the purpose of the TC. There is only
> one alternative that have been implemented or even drafted at this
> stage.)
The TC is currently considering four different options, all of which are
either already implemented or fairly easy to implement in a short time
frame. I don't think all the options have to be at the point of being
appliable patches before the TC can consider something.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: