On Wed, 04 Sep 2019 at 11:09:27 +0100, Simon McVittie wrote: > I would like to propose this build profile for addition to > <https://wiki.debian.org/BuildProfileSpec>. I'll add it to the wiki if > there seems to be rough consensus. > > Name: noinsttests > Changes content of binary packages: No ("C: N" on the wiki) > Changes set of binary packages: Yes ("S: Y" on the wiki) > Description: > Binary packages consisting entirely of automated tests, manual tests, > example/demo programs and test tools should not be generated.
Summary of the thread started by the above message: I think there is consensus that this concept is a desirable build-profile (and I've already been asked to add it to dbus and glib2.0 to break a circular build-dependency). The only thing that attracted discussion was the name. * Helmut Grohne and Johannes Schauer asked for noinsttest (without the pluralizing s), to be more consistent with nocheck and nodoc. I intend to accept that change and rename it to noinsttest. * Ansgar requested a name without abbreviations, like no-installed-tests. Helmut Grohne pointed out that popular build-profiles appear many times in package metadata, which is a reason to prefer a short name. Short names are also consistent with the existing build-profiles. So I intend to reject that change and keep noinsttest. * Helmut Grohne and Guillem Jover wondered whether it should be noinstcheck[s] to be consistent with nocheck, particularly since Autotools has 'make installcheck'. I think this would be more misleading than beneficial, for two reasons: - To me, "check" implies checking something, which is not actually what this profile controls. Instead, it controls whether test-cases (test executables, tests) are built and installed - but not run! - so that you can use them to check something later. - In Autotools packages, it doesn't map to whether 'make installcheck' is to be run. If we ran 'make installcheck' during build to test the just-built binaries, disabling that would be in-scope for nocheck. So I intend to reject that change and keep noinsttest. Is there anything to add, or anything I have summarized inaccurately? Does anyone feel strongly enough about this to veto the addition of this build-profile under the name "noinsttest"? If there are no objections, I'll add this to the list of standard build profiles next week. Thanks, smcv