Adrian Bunk: > On Wed, Aug 16, 2017 at 03:43:00PM +0000, Ximin Luo wrote: >> Adrian Bunk: >>> On Wed, Aug 16, 2017 at 11:37:00AM +0000, Ximin Luo wrote: >>>> [..] >>>> >>>> Fair enough. I actually spotted that but thought it was better to get >>>> "something" into Policy rather than nitpick. I guess other people were >>>> thinking similar things. Well, lesson learnt, I will be more forceful next >>>> time. >>>> ... >>> >>> What is the point of getting "something" into policy, when it is known >>> to not match existing practice and that what is being added to policy >>> will be ignored by everyone? >>> >>>> The sentence I amended said "most environment variables" so our intent is >>>> clear. >>>> ... >>> >>> This is not about "intent", this is about giving an exact definition >>> of reproducibility for Debian. >>> >>> The definition should then match what is recorded in .buildinfo >>> and what the reproducible builds infrastructure is testing. >>> >> >> The exact wording that was added, was a too-loose requirement. I'm now >> proposing to make the requirement more strict, in accordance with the tests >> that we're running. Do you have any comments on my proposal? >> ... > > Will both dpkg-genbuildinfo and the reproducible builds infrastructure > implement this definition? > > Any definition is fine for me as long as it will match what is actually > being done.[1] > > [1] not excluding future changes, but at the time the policy will be > published it should match reality >
dpkg-genbuildinfo isn't about testing reproducibility, it's about recording the build environment: https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles#Semantics "A buildinfo file is a record of what a particular builder did to build some binary output. It contains as much information about the build environment as is reasonable to distribute, and attempts to include all information needed to reproduce that build. It does NOT imply that everything contained within "should" be necessary to reproduce the build. [..]" AIUI, the tests.reproducible-builds.org infrastructure does already include what I suggested to be added. That is, it doesn't report "unreproducible" if varying those reserved variables, would change the binary hash. It could be a bit clearer in the UI on which suites vary the build-path however, that is an improvement to be made. For buster (where the build-path is not varied) then an "unreproducible" status would mean it's not meeting the definition (that includes my addition of these "reserved variables"). It is true that we might report "reproducible" even if the output varies based on the envvar UNIQUERANDOMENVVAR, because we don't explicitly vary that. But a lot of other QA-related tests in Debian would give "good" results even for "bad" packages that are bad in a very esoteric way. It's the intent that matters, and I think that's captured well in the policy, especially with my proposed newer wording, and also in the practical tests that we're already running. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
