Re: Raising the severity of reproduciblity issues to "important"
On Fri, Sep 01, 2017 at 11:07:17AM +0100, Simon McVittie wrote:
> The problem with maintainer-built binaries around NEW is that if they
> wait in the NEW queue for (let's say) 1 month, then by the time they
> reach the archive, they were built with a 1 month old toolchain and
> build-dependencies, not an up-to-date toolchain and dependencies.
> Reproducible builds don't help with this, because a package can
> typically only be reproducible when holding the toolchain and
> dependencies constant.
I fail to see the problem here. Of course the maintainer-built binaries
should be accompanied with the relevant .buildinfo file telling what
versions of dependencies were used - just like any buildd-built package.
Packages can sit in unstable for months - even years - without being
updated and thus their binaries do use years old toolchain and
build-dependencies. What you describe does happen to buildd-built
packages. The key to reproducibility here is using the .buildinfo and
replicating the installation used for the original build (using
snapshot.d.o).
Whatever point you were trying to make around NEW, your argument is not
very convincing. I think Holger is right here: Where the package is
built should not matter. Presence of .buildinfo and reproducibility
does.
Regarding Guillem's point: I don't think disallowing binary uploads is
going to be a problem to bootstrapping. Ubuntu has been doing this for
years. They have a small set of people who can (carefully) inject binary
packages and that mechanism is sufficient. Restricting binary uploads to
a small subgroup of Debian Developers does make sense to me from a
bootstrap pov, because uploading binaries could be a rare thing to do.
We should be less shy in copying the good stuff from Ubuntu. :)
Helmut
Reply to: