[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#604397: debian-policy: require build-arch and build-indep targets

On Mon, 2011-06-06 at 12:29:20 +0200, Jakub Wilk wrote:
> * Guillem Jover <guillem@debian.org>, 2011-06-06, 09:55:
> >I'd even go further and combine that with dpkg-buildpackage
> >stopping to set compilation flags on the environment, so we only
> >have to deal once with possible mass FTBFS on the archive.
> I don't think this is a good idea. To enable build-arch, we'll
> probably need quite a few NMUing volunteers, and it IME is very
> demotivating when you have to fix a seemingly simple bug (e.g.
> missing build-arch target) only to discover tha the package would
> mysteriously FTBFS anyway (e.g. because it relied on *FLAGS exported
> by dpkg-buildpackage).

We could certainly do it in another slot, if it feels like going to
be more painful than needed.

> Just to provide some statistics:
> - There are 16491 source packages in unstable[0].
> - Out of these, 2206 source package build both arch:all and arch:any
> binaries[1].
> - Out of these, 214 already FTBFS in unstable[2].
> - Out of remaining 1992 packages:
>   + 486 use so called "tiny" debhelper rules.
>   + 664 use cdbs.
>   + At least 175 defines both build-arch and build-indep explicitly.
> So that leaves us with at most 667 packages to fix (plus an unknown
> number of packages that define build-{arch,indep}, but do so
> incorrectly). This is still a big number, we'd roughly double the
> number of currently observed FTBFS bugs if we announced flag day
> *today*.

I think those could be reduced even more by splitting into two stages,
by first only activating build-arch for packages w/ Build-Depends-Indep,
and then the ones w/o.

The second round would benefit only from possible split building, the
first from reduced build dependencies.


Reply to: