Re: autobuilding and embedded timestamps

[Edmund GRIMLEY EVANS <edmundo@rano.org>]

Daniel Jacobowitz <dan@debian.org>:

> > Do Debian's autobuilders compile repeatedly until the system
> > converges? If so, how do they detect convergence?
> 
> Heck no.  Nothing gets built more than once.  It causes all sorts of
> problems, but convergence is essentially impossible - we're building
> ALL of the debian archive, remember?  We can't pick and choose 20
> packages; we have to deal with 4000 instead.

Why impossible?

I don't see that the number of packages changes anything essentially.
In practice the cost is linear in the number of packages. If you can
solve the problem of embedded timestamps, then you end up doing an
extra 4000 builds for each test cycle, which should be feasible.

The main difference between my toy set-up and Debian is that I install
all my 20 packages, whereas Debian has packages that conflict with
each other.

So you should probably define a core set of packages that are always
installed at build time and make each package declare any other build
dependencies it may have. When you build a package, you have only
those packages installed. Use a chroot environment to keep it really
clean.

That way, you can change most packages without having to rebuild any
other packages.

The main advantage of doing this:

* You know for certain that the released binary packages can be
rebuilt with the released source on the released system, which is good
for security.

The cost:

* You need a more complex autobuilder.

* You need some extra CPU power for the autobuilder (roughly
equivalent to rebuilding every package on each test cycle).

* You force package maintainers to get rid of embedded timestamps (but
presumably you help them by providing some tools for this).

PS: If a package accidently contains an embedded timestamp, the
autobuilder should detect the situation rather than go into a loop.

Edmund