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
