On Mon, Jun 06, 2011 at 01:04:59PM -0700, Russ Allbery wrote: > Andreas Barth <a...@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. <ballo...@debian.org> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110609222124.GC31035@yellowpig
