On 05. 06. 20 16:26, Richard W.M. Jones wrote:
On Fri, Jun 05, 2020 at 04:10:20PM +0200, Tomas Orsava wrote:
Hi,
I think it would be useful to have a standard way of disabling the
running of tests during RPM build (in the %check section of a spec
file).
I see a lot of packages already having %bcond's or other macro
definitions to archieve this, but each package has their own way,
there's no real standard. Thus you have to first look into the spec,
locate the appropriate %bcond or macro name and only then you can
disable the tests.
I would like to propose two approaches:
(a) Add a *SHOULD* rule to the guidelines that specifies what is the
preferred way to conditionalize the tests.
(b) Or, if that's too strong, mention in the guidelines the common
methods that are being used (e.g. %bcond tests and %bcond check) so
that new packagers have something to use.
What's the motivation for disabling tests globally?
Bootstrapping mostly.
I have some packages where tests fail on particular architectures at
particular times, and what I do there is (a) file a BZ (b) surround
the %check section with %ifarch/%ifnarch and a comment linking to the
bug, and this seems to me a practical and lightweight approach that
requires no special support in the toolchain.
Also rpmbuild itself can happily disable tests, just add the --nocheck
flag.
However rpmbuild itself doesn't support "CheckRequires", so the bcond often
looks like this:
BuildRequires: python3-devel
BuildRequires: python3-setuptools
%if %{with tests}
BuildRequires: python3-pytest
BuildRequires: python3-hypothesis
%endif
...
%if %{with tests}
%check
%pytest
%endif
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
