Bug#604397: Request for TC to rule on a course of action for supporting build-arch
On Mon, Jun 06, 2011 at 01:04:59PM -0700, Russ Allbery wrote:
> Andreas Barth <aba@not.so.argh.org> writes:
>
> > Option 1 also implies forcing debian/rules to be a Makefile, which is
> > think is sensible.
>
> Policy already requires this. The only package in the archive for which
> this is not already the case is "leave".
>
> I don't like option #3 because it's something we'll be stuck with forever
> and requires packagers update both debian/rules and debian/control to
> configure things properly. One of the reasons why I'm personally fond of
> #4 is that it reduces our long-term complexity. #3 increases our
> long-term complexity, I think unnecessarily.
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.
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 am afraid that any makefile trickery would not be stable enough
for that purpose.
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).
(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.)
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: