Re: draft ballot: please rule on how to implement debian/rules build-arch
On Sat, 23 Jul 2011, Bdale Garbee wrote:
> On Sat, 23 Jul 2011 15:45:08 +0200, Steve Langasek <vorlon@debian.org> wrote:
> > BTW, another option for the long-term solution which we haven't really
> > addressed head-on is that dpkg-buildpackage could detect whether both
> > arch-indep and arch-dep packages are present in debian/control, and use
> > build-arch *only* when both are present. This does not require either
> > heuristic detection (the presence or absence of arch-indep/arch-dep packages
> > is *definitional* of whether a separate build-arch rule is relevant, and
> > dpkg-buildpackage already parses debian/control), or the use of redundant
> > declarations (i.e, Build-Options). Should we incorporate this into the
> > ballot options? (For the avoidance of combinatoric proliferation, I'd
> > prefer to decide this question by acclamation and either incorporate it into
> > all the ballot options, or not.)
>
> I'd be willing to consider this, and would probably vote it ahead of the
> make -qn options, though as in all the other cases, I'd be happier if
> someone actually had a patch that implements this ready to go.
FWIW, I would implement this if it was voted. But even if you reduce the
set of concerned packages to 2206 thanks to this, the number of instantly
broken packages would be too high to be acceptable (>600).
So we should keep auto-detection to fallback to "build" for the transition
period. Thus my favorite option is still 1 or 5 (either inconditionnaly or
only for packages witch arch-dep and arch-indep packages).
> Actually, the more of my own packages I touch and fix, the more inclined
> I am to place option [4] first on my list! Fixing source packages just
> isn't that painful in practice, and I like the idea of just getting over
> the policy hurdle quickly without stopgap measures.
One should also consider that I plan to backport dpkg (because a
substantial number of recent features will be used by packages and without
a dpkg backport it will difficult to backport all the packages which use
those features).
A squeeze system with a backported dpkg without auto-detection will fail
to build many squeeze packages even if we manage to fix them all in sid.
That would be a sad state that would require me to drop that feature in my
backported dpkg.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: