>>>>> "Simon" == Simon McVittie <s...@debian.org> writes:

    Simon> On Wed, 26 Apr 2023 at 18:59:46 +0200, Christian Kastner wrote:
    >> Policy 4.9.1 states that (emphases mine): * "[nocheck] says not
    >> to *run* any build-time test suite" * "[nodoc] says to skip any
    >> *build* steps"
    >> 
    >> My reading with regards to 'nocheck' was that where tests were
    >> available and needed to be built, then they should always be
    >> built, just not run.
    >> 
    >> A typical example might be a C library package that builds those
    >> tests and ships them as autopkgtests, maybe even in a dedicated
    >> package.
    >> 
    >> I thought this line of reasoning was sound, but then I remembered
    >> the 'nodoc' tag and now I am no longer sure. Maybe I'm taking the
    >> 'nocheck' description too literally.

    Simon> With RFC 2119 terms, my opinion would be:

    Simon> - packages built with the nocheck option SHOULD NOT run tests

Agreed.

Simon> - the nocheck option SHOULD NOT alter the contents of any
    Simon> binary package

I agree this is true--possibly even as a MUST--for the nocheck build
profile, but
I think DEB_BUILD_OPTIONS are allowed to modify the contents of binary
packages.
As an example nostrip certainly modifies the size of things, and noopt
can modify the behavior and performance.

My assumption was that if you were specifying the nocheck build option,
you don't want to run tests, possibly because they are flaky and/or you
are trying a build for some local reason even though you know the tests
will fail.

If you actually want to avoid building the tests, use the nocheck build
profile (assuming that can be done without modifying binary packages).

If my reasoning is correct, my interpretation is that nocheck option
can build tests or not, depending on whatever is convenient.

I guess that's consistent with RFC 2119.
And RFC 2119 SHOULD means that the requirement is RECOMMENDED, and an
implementation that does not follow the SHOULD needs to have a reason
for not following the recommendation.

Reply via email to