On Thu, 05 Sep 2019 at 06:30:34 +0200, Guillem Jover wrote:
> «noinstcheck» would also map equally to autotools «make installcheck»,
> in the same way «nocheck» maps to «make check».
To me, "check" would imply actively checking something - most likely
by *running* the tests - rather than merely building/installing some
test-cases so that we can run them (use them to check the package) later.
If anything, I would expect a noinstcheck profile to be about whether
to run `make installcheck DESTDIR=$(CURDIR)/debian/tmp`, or other build
systems' equivalents if they have one, during build (but in practice we
don't do that anyway).
GNOME-style installed-tests are not quite the same thing as Autotools
`make installcheck`: they have similar goals (improving test coverage
of the installed code), but different constraints. GNOME-style
installed-tests test the package under more realistic conditions, so
they are less prone to false positives and false negatives than either
`make check` or `make installcheck`. The price they pay for that is that
to set up those more realistic conditions, they require the package under
test to be "properly installed" in its final location, and for example
cannot be run within the constraints we place on buildds. In Debian terms,
`make check` has to happen during build, GNOME-style installed-tests have
to be an autopkgtest, and `make installcheck` could be used for either.
A few packages like dbus do use the same code for installed-tests and
installcheck, but it takes additional effort to make the same tests work
for both (similar to the additional effort needed to make a build-time
test usable as an installed test). installcheck has access to the built
source tree (like autopkgtest with the needs-build restriction), but
needs to cope with the installed package having been installed to a
DESTDIR rather than to its final location (so for example it needs to
set LD_LIBRARY_PATH to pick up any newly-installed libraries - which can
prevent genuine bugs from being noticed).
smcv
