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

Re: possible MBF: automatically detecting unused build dependencies

On Tue, Jul 08, 2014 at 06:22:49AM +0200, Johannes Schauer wrote:
> Quoting Steve Langasek (2014-07-08 00:07:29)
> > On Mon, Jul 07, 2014 at 09:14:44PM +0200, Johannes Schauer wrote:
> > > Nevertheless, those "false positives" that were generated this way are
> > > still useful to be later marked with <!profile.stage1> once build profiles
> > > are allowed in the archive because they are obviously droppable.

> > No, marking build-dependencies with build profiles should be driven by what
> > is needed to break build-dep loops, not by what build-deps are "droppable"
> > without further modification of the packages.  Excessive stage1 profile
> > tagging will result in unnecessary extra builds during a bootstrap.

> Bootstrapping should not get into the way of the normal packaging.

But it absolutely does have this effect if we add bootstrap-specific
metadata unnecessarily, because:

 - it introduces a syntax incompatibility with older versions of the package
 - it makes the packaging more complex to understand

The latter point is as likely to cause problems for the bootstrappers
themselves as it is for the maintainers, since the more maintainers who have
to get this metadata right and keep it up to date, the more it's going to

> The downside you list "unnecessary extra builds" are easy to avoid in
> practice.  Botch contains algorithms to find a close to minimum set of
> source packages to modify to make a dependency graph acyclic (a feedback
> vertex set).  Even if all source packages in the dependency graph had
> removable build dependencies it would only choose a small set of them
> (currently 60-70 are needed) to actually build with a stage1 profile
> active.

I'm happy that tools like botch exist and think botch has been a useful
accelerator for bootstrappability of Debian.  However, my own goal is to see
that future port bootstraps can be done using the standard buildd
infrastructure (for each of Debian and Ubuntu), which doesn't currently make
use of such techniques - rather, they work by building everything which is
buildable.  If you plan to wire up botch to wanna-build for archive-friendly
bootstrappability, that would be great to see!  But until that's happened, I
stand by my claim that stage1 data not needed for breaking build-dep loops
is counterproductive for bootstrapping ports.

> > > I did not plan to run this script more often yet. I'll probably do another
> > > run after having added a detection for meta packages as suggested by you
> > > below.

> > > Running it more regularly might not require any big discussion because the
> > > "problem size" might be small enough that maintaining a white list would be
> > > enough.

> > If you really want to systematically detect misbuilds on missing
> > build-dependencies, it's a much bigger problem than just detecting this for
> > the build-dependencies which are metapackages.

> Why? The build dependencies which are not metapackages are not listed as
> false positives because they get weeded out in the first phase.

Because "package misbuilds when a metapackage it build-depends on is broken"
is an arbitrary subset of "package misbuilds when build-depends are broken",
and it does not benefit Debian to have maintainers focusing on such an
arbitrary subset.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: