I have a some of misgivings about this "reproducibility light" definition in 

- it's not where we actually want to be, meaning that we will want to 
ratchet up that definition over time to allow more variation (environment, 
cwd etc). That means we already consider packages to be buggy but we haven't 
yet codified how/why.

- it's annoying for maintainers to put work into fixing reproducibility 
problems and to then have the goal posts moved.ยน

- this definition does not match what is being shown to maintainers on 
tracker.debian.org, UDD's Dashboard (dmd.cgi), etc; this definition does not 
match the patches that are being sent to the BTS to fix reproducibility 
issues in that those patches go much further. This definition does not match 
standard practice.

Policy is not a stick but policy can document where we want to be, 
particularly when we are talking about standard practice. It is already 
standard practice that packages build reproducibly with things like build-
path variation -- we have upwards of 80% of the archive doing that. 

A broader definition of reproducibility in policy is also not making 
packages instabuggy. It already is standard practice that we expect packages 
to build reproducibly with build path variation -- we already consider the 
packages that do not do so to be buggy, we file bugs and we send patches.

I don't want a search for the perfect definition of reproducibility to delay 
doing anything, but can we not already do more than this right now?


1. I, for one, was reasonably grumpy when build-path-variation was suddenly 
introduced and 'undid' my work of making all my packages reproducible. I 
know it didn't actually undo that work but it felt like it when suddenly the 
dashboard went red again.

Stuart Prescott    http://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/         stu...@debian.org
GPG fingerprint    90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Reproducible-builds mailing list

Reply via email to