source-only builds and .buildinfo
infinity0 at debian.org
Wed Jun 21 10:09:00 UTC 2017
> On Wed, Jun 21, 2017 at 09:28:00AM +0000, Ximin Luo wrote:
>> Adrian Bunk:
>>> On Tue, Jun 20, 2017 at 02:47:20PM -0400, Daniel Kahn Gillmor wrote:
>>>> Hi Ian--
>>>> On Tue 2017-06-20 18:10:49 +0100, Ian Jackson wrote:
>>>>> A .buildinfo file is not useful for a source-only upload which is
>>>>> veried to be identical to the intended source as present in the
>>>>> uploader's version control (eg, by the use of dgit).
>>>>> Therefore, dgit should not include .buildinfos in source-only uploads
>>>>> it performs. If dgit sees that a lower-layer tool like
>>>>> dpkg-buildpackage provided a .buildinfo for a source-only upload, dgit
>>>>> should strip it out of .changes.
>>>> I often do source-only uploads which include the .buildinfo.
>>>> I do source-only uploads because i don't want the binaries built on my
>>>> own personal infrastructure to reach the public. But i want to upload
>>>> the .buildinfo because i want to provide a corroboration of what i
>>>> *expect* the buildds to produce.
>>> If you expect that, then your expectation is incorrect.
>>> If you upload a package right now, chances are the buildds will use both
>>> older versions of some packages  and more recent versions of some
>>> other packages  than what you used.
>> I think what dkg means here (and what we the R-B team has wanted for ages and is working towards), is not that the buildds use the *versioned dependencies* listed in the buildinfo, but produce the same *output hashes* as what's in the buildinfo.
>> The point being specifically that the dependencies used could change, but if the output remains constant, we're more assured that the build was done properly and reproducibly.
> How is that supposed to work when the compiler is not exactly identical?
> As an example, gcc-6 6.3.0-18 and gcc-6 6.3.0-19 will likely produce
> different output for every non-trivial piece of software.
> The reason is that every new gcc upload usually contains whatever
> bugfixes are on the upstream branch.
It would depend on the situation which dependencies should be "irrelevant" towards the final output, right. If the dependencies are different and the buildinfo is different, it does not necessarily mean there is a problem, the upload does not need to be rejected. But it's a signal that other people (including the uploader) might want to re-try the build with the newer dependencies.
OTOH if the outputs match, we get more certainty, which is a good thing.
We also need to get some real data on this, it could be that a change from -18 to -19 would only affect a small number of packages, and most other ones would actually be compiled identically.
More information about the Reproducible-builds