Saturday, 5 December 2015

Re: Build priority

On Fri, Dec 04, 2015 at 10:39:03PM +0200, Anca Emanuel wrote:
> The current algorithm for building 12000 packages for an new architecture is:
> For a* to z* try build.

That's not actually true. Here's the real algorithm for build scoring:

Lexicographical ordering is a tie-breaker after all that.

> Of course you will need lib* and *dev first, and you will waste a lot
> of time trying to compile things.
> And a lot of (manual) retries.

Most retries are in fact automatic, in those cases (the typical ones)
where we can automatically determine the dependencies we need to wait

> My proposal: try to find an algorithm for dependencies.
> If package A depends on package B to be build, B gets an +1 for priority.
> Do that for the entire archive.

For bootstrapping, it generally isn't actually that important. We
always have to have a bootstrap set prepared first, which takes care of
a lot of the ordering issues, and building main and nominated package
sets first handles nearly all the rest. If we have a respectable number
of builders, then throwing things against the wall until they stick is a
perfectly viable strategy. While the problem does exist, it is usually
rather negligible.

We have certainly thought of using dose-builddebcheck to ensure that we
only dispatch builds to builders once their build-dependencies are
satisfied. That's what Debian does for their buildd network, and it
generally works well there. However, our problem is rather more
complicated since we have to handle PPAs as well, and dose-builddebcheck
wouldn't scale very well to handle a very large number of overlapping
package index files like that; it would also be vitally important that
we don't err on the side of incorrectly refusing to dispatch a package,
since that could be rather difficult for people to sort out manually.

So, for the time being, the current system works well enough in
practice, even though it's relatively crude (but not nearly as crude as
you think!).


Colin Watson []

ubuntu-devel mailing list
Modify settings or unsubscribe at: