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
