What do we really mean by "reproducible"?

Paul Sherwood paul.sherwood at codethink.co.uk
Mon Jan 16 14:32:30 UTC 2017



On 2017-01-16 14:28, Santiago Vila wrote:
> On Mon, Jan 16, 2017 at 02:19:44PM +0000, Paul Sherwood wrote:
>> On 2017-01-16 11:26, Santiago Vila wrote:
>> > Before I use this rationale more times in some discussions out there,
>> > I'd
>> > like to be sure that there is a consensus.
>> >
>> > What's the definition of reproducible? It is more like A or more like B?
>> >
>> > A. Every time the package is attempted to build, the build succeeds,
>> > and the same .deb are always created.
>> 
>> I may be wrong, but I believe that it's not possible to guarantee that 
>> the
>> build succeeds every single time, even once we've locked all inputs to 
>> be in
>> a known state. Cosmic rays would be one potential breakage, or 
>> corruption of
>> a built intermediate artifact etc.
> 
> But I'm not speaking about cosmic rays or disk failures, but things
> which are intrinsic to the package itself:
> 
> A very simple and funny example: Would we call a package having this
> bug "reproducible"?
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838828
> 
> (It has a mathematically-proved probability > 0 of failure).

I would say that's *not* reproducible.



More information about the Reproducible-builds mailing list