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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
