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.
_______________________________________________
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
