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.


Reply via email to