Taskotron related discusses something like TestRequires, too:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FUWLJQYQJAGNGSSFTCA3ZEHAX43LJ7UU/

This is a good idea and I'd definitely support such a change, but an issue should probably be filed upstream with RPM.

(In reply to Jason Tibbitts from comment #2)
> This is a good idea and I'd definitely support such a change, but an issue
> should probably be filed upstream with RPM.
Unfortunately this IS RPM upstream.

anyhow I was trying to check if --nocheck defines some macro... Unfortunately I was not able to find that.

It doesn't. I remember committing the change (see bug 756531) and thinking "meh" because this is trivial to implement in specs without help from rpm (bcond with/without check) and that's how almost every spec does it already. OTOH the --nocheck and --noclean options are consistent with the other --nofoo options of rpmbuild so it's hard to argue against them either.

The de-facto way to do this in specs is:
---
# add option to build without check
%bcond_without check

%if {with check}
BuildRequires: foo
BuildRequires:  bar
%endif

[...]

%check
%if %{with check}
make test
%endif
---

It'd be nice to have --nocheck (and ditto for all the other sections) integrate with that, without breaking existing spec expectations.

*** Bug 1394870 has been marked as a duplicate of this bug. ***

Just to note: the Base Runtime team would like to request that the priority on this be increased, as it's going to be important for our modularity efforts. (Right now, the buildroot for self-hosting the base runtime is enormous, in many cases much larger than it strictly needs to be due to pulling in test dependencies.)

Well, like pointed out in comment #4 you don't actually need anything new from rpm to achieve this, it's all doable with any old rpm from the last ~12 years.

An actual BuildRequires(check) implementation would break spec compatibility and be more complicated than what works already, so when the goal can already be trivially achieved it seems like nothing but colossal waste of time. If anything is to be done in rpm wrt this, it's likely just standardizing the "%bcond_with/without check" idiom.

Fedora has packaging standards for far stranger items. I'd suggest poking FPC to define the existing de-facto standard as an actual standard and update packages where necessary.

If we're going to standardize on that (which is fine with me), then:

Can we hook the beginning of %check to exit automatically so that --nocheck just starts working on every spec (to at least not run the %check section)?  It should be possible to just emit "echo Skipping check because --nocheck was specified; exit 0" conditionally in %__spec_check_pre, shouldn't it?  Could also play with %__spec_check_shell or %__spec_check_template.  Which would be better?

A %checkonly macro which evaluates to its contents or nothing depending on the context would at least make one-liner buildrequires shorter than wrapping in %if/%endif:

%checkonly BuildRequires: foo bar

That's pretty easy to do and I can cook it up but I figured since Panu is listening I'd toss it out in case there's some corner case I'm missing which gets in the way of doing that kind of thing.

Oh, and as item 0 on the list above, can't we just do the equivalent of %bcond_without check by default in redhat-rpm-config?  I've never been absolutely clear on just how those things actually work, but looking at the definitions, it's.... pretty trivial.  But again, just asking in case there's something I'm missing.

I think BuildRequires(check) makes sense.

I must say...  I'm now pretty confident that '--without check' is
sufficient for almost everybody (nobody claimed this is not truth).
Having 'CheckRequires:' or 'BuildRequires(build,check,...)' would make it
more "declarative" and more pretty (to me, so I'd like to have it some
day) but I don't think we should feel blocked by such feature request.

I originally wanted to "fix" '--nocheck' option (because installing
something just because %check needs it is useless if --nocheck is passed),
but now I see that '--nocheck' is pretty new and gives false promises:
There are lot of packages running testsuite in %build, simply because it
is impossible to run the testsuite properly in %check.  And this makes
%check and --nocheck pretty useless (from global, distribution POV).
And for bootstrapping the distribution, we need a more ultimate answer
(standard/guideline) to resolve this.

Note both '--without check' and '--nocheck' are now supported by both
'mock' and 'rpm'.  But '--without check' should work for everybody.

'--nocheck' could imply '--without check' and vice versa, but that sounds
like brittle thing, and people using one or both could experience
compatibility issues...

* Shouldn't we document in 'man rpmbuild' that --nocheck is just for
  testing purposes (not a production packager's tool), and that --with
  check is preferred?

* Mock says about --nocheck:  "pass --nocheck to rpmbuild to skip 'make
  check' tests", that should say "skip %check phase", makes sense?  I'll
  send a patch then.

* Can we standardize '%if %{with check}' (or %{with runtests} so it
  doesn't have a relation with %check) and have '%bcond_without check'
  defined _by default_?  And fix guidelines?

* We could think about nicer syntax for
  %if %{with check}
  BuildRequires: foo
  %endif

I'm not committing to any particular details here on rpm-side because I haven't thought about it that deeply, except that whatever (if anything) is done must play nice with the "with/without check" idiom. That would mean making --nocheck and --without check more or less aliases for eachother, and %check must be skipped by either whether the spec supports it or not. And this is specifically about %check section, so don't go inventing any new names for it. Note that the concept is easily expandaple to other sections, eg --noclean vs --without clean, and perhaps others too (as an alternative means of implementing short-circuit etc). Whether that will be done is another topic...

My point in outlining this is that you dont need to wait for rpm to implement anything at all, just use the with/without check system (packages WILL need changes to implement those check-only dependencies anyway, no matter what the syntax) and FWIW you have my word that rpm will play nice with it.

BTW, for a one-liner syntax you can also use
%{?with_check: BuildRequires: foo bar zoo >= 4.3}

It might not be very pretty but I'd rather not have any magic macros to obfuscate the fact that its fundamentally just a %bcond macro. Me, I find this far more readable even if it takes two more lines:
%if %{with check}
BuildRequires: foo
%endif

(In reply to Panu Matilainen from comment #12)
> BTW, for a one-liner syntax you can also use
> %{?with_check: BuildRequires: foo bar zoo >= 4.3}

One consequence is that rpmbuild bakes BuildRequires specified
like this into SRPM file - and then the requirement is "non-conditional":

  $ rpm: --without: unknown option
  rpm -qpR <the-src.rpm> --without check

Further `rpmbuild --rebuild <scr.rpm> [--with{,out} check]` is not affected
(the conditions are somehow re-evaluated, good!), but Mock depends on
the source RPM format/requirements.