Hi.

I've seen several cases where a package is considered not reproducible
just because the build environment changed between build1 and build2.

It would be great if, by design, this did never happen, but I
understand this will not be easy to implement.

However, I can think of some workarounds:

* If the only difference is in the buildinfo files, consider that the
package is reproducible.

* If the buildinfo files differ, discard everything and put the
package in the queue again.

* Do not start any build for some amount of time before the mirror pulse,
to avoid either build1 or build2 to happen in the middle of a mirror sync.
The problem with this is that we don't know when the mirror sync will happen.

* Start build1 and build2 at the same time in different jobs (this is
not such a silly idea considering that we have a lot of processors).

* Make build1 and build2 in the same job (not in two independent ones).
Hopefully, the build-dependencies installed for build1 will serve for
build2 as well, since the source package is still the same. Just do
not remove them between build1 and build2.

Sorry not to be a programmer myself, but I hope some of these ideas
make some sense.

Thanks.

_______________________________________________
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Reply via email to