Re: nocheck (don't run) vs nodoc (don't build)

[Christian Kastner <ckk@debian.org>]

Hi Russ,

thanks for the fast reply!

On 2023-04-26 20:42, Russ Allbery wrote:
> Christian Kastner <ckk@debian.org> writes:
>> 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.
> 
> I think this may be semi-accidental stemming from the affect on build
> dependencies.  One of the points of nodoc is to avoid needing to install
> (and thus have available) all the build dependencies that are used only
> for building the documentation, which often involves a full TeXLive
> installation and thus poses time, space, and bootstrapping issues.  So I
> think we made specific note that the documentation wouldn't be built so
> that those build dependencies wouldn't be required.

Yep, that was my understanding, too.

> The same argument probably applies to the test suite, I think?  It's just
> less common (although certainly not unheard of) for test suites to have
> test-suite-only build dependencies (as opposed to test-only runtime
> dependencies, which are very common in at least the Perl world).

We (the ROCm team) have a few instances of such test suites, namely
header-only libraries. Upstream ships tests that require compilation,
and we'd like to ship these tests for autopkgtest purposes.

[Tangential: our autopkgtests cannot be run on official infra yet as
they require an AMD GPU to run, but that's another avenue we're working
on. The issue here should also apply to any other header-only library.]

> Anyway, I think this warrants a bug and some work on figuring out what we
> really want to say, and I'd want the folks working on bootstrapping and
> build profiles to weigh in.  The nocheck build profile sort of implies
> that the test suite shouldn't be built either:
> 
>     No test suite should be run, and build dependencies used only for that
>     purpose should be ignored. Builds that set this profile must also add
>     nocheck to DEB_BUILD_OPTIONS
> 
> It still doesn't say this explicitly, but it says build dependencies
> should be ignored, so presumably the build would fail if it required any
> build dependcies, implying that it shouldn't be run.

Strictly speaking, it says build dependencies for the purposes of
_running_ should be ignored, which makes perfect sense of course. But
what if there is another purpose, specifically shipping autopkgtests?
Like packages 'systemd-tests', or 'fwupd-tests'?

For a Python package, this is easy: I can skip any build dependencies
needed for build-time testing (eg: python3-pytest), and since Python
test suites generally don't need builds, I can still ship full test
suite as an autopkgtest. So nocheck "just works".

For a C or C++ library though, skipping build dependencies for tests
means empty autopkgtests. So far, I just assumed that this was
wrong/contradictory, and thus always built them.

But then I remembered nodoc, and how that too can lead to possibly empty
and thus unusable packages. And how that's ok, since such builds aren't
meant for general use, but for the specific use of the caller who
explicitly requested nocheck/nodoc in the first place, so they know what
they are doing.

> Anyway, I think this warrants a bug

I'll try to improve and to compact my reasoning, and will file one when
it's done -- unless you'd prefer me not to do it myself, or somebody
else beats me to it.

But that will take me a while, as I clearly need to think this through a
bit more. Because it just dawned me that for a header-only library, the
argument could be made that autopkgtests should always build the tests
from scratch anyways. Or maybe even both (run, and build-and-run).

Best,
Christian