Bill Allombert <bill.allomb...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- 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/8762oezlk4....@windlord.stanford.edu
