Bug#1019742: should reproducible builds vary nocheck?

Rebecca N. Palmer rebecca_palmer at zoho.com
Sat Dec 14 20:47:47 GMT 2024


Should we merge #786644 and #1019742?  Or should we consider #1019742 to 
be "have the option" and #786644 to be "enable it by default"?

I'm willing to try implementing this, if we agree that having it is a 
good idea.  Maybe use _PROFILES rather than _OPTIONS and allow it to be 
more general than just nocheck?

There is a way to vary nocheck but continue to check for test failures 
in the less-standard environment: make the *first* build the nocheck 
build.  (timezone is precedent that the first build is allowed to do 
non-default things.  No strong opinion on whether we actually want that.)

On whether nocheck even should always mean no change to output:

DEB_BUILD_PROFILES=nocheck (which requires also setting 
DEB_BUILD_OPTIONS=nocheck) *is* defined (at 
https://wiki.debian.org/BuildProfileSpec#Registered_profile_names ; 
Policy doesn't describe build profiles at all, #757760) as not changing 
the build result.  (Packages that ship test results/tools and want to 
make this optional are probably supposed to use 
DEB_BUILD_PROFILES=noinsttest instead.)

However, I'm not aware of any systematic attempts to check this, and 
hence, I don't know how often it is violated in practice.  There appears 
to have been at least one mass rebuild with nocheck, but it only seems 
to have filed bugs for packages that failed to build *at all* with 
nocheck (e.g. #1086765).

Hence, I suggest implementing the option but not initially making it the 
default, doing a large (maybe archive-wide) run with it enabled, and 
only then deciding whether to enable it by default.

On the time/resource savings:

I suggest that this run also record the duration of each build, to 
provide an estimate of the time/resource saving.

Users that care about resource use may already be making *both* builds 
nocheck, e.g. some of my packages have SALSA_CI_REPROTEST_ARGS: 
"--append-build-command=-Pnocheck" (Salsa reprotest defaults to a 1hr 
time limit).  Hence, any implementation of this should probably avoid 
breaking such existing mechanisms.



More information about the Reproducible-builds mailing list