Disable building of "test" subpackages / multibuild packages
Hi all, is there a way to disable building of test subpackages (or multibuild packages or whatever the proper term is) on a per-project base? Like e.g. python-setuptools which has a test "multibuild":
https://build.opensuse.org/package/show/devel:languages:python/python-setupt...
I think I could modify each and every _multibuild file or remove the test spec files from the packages, but I would rather like to avoid that and just set some flag on the project itself. In my case I am just linking together several packages that are being tested somewhere else and would like to avoid having to link in all the test dependencies and their dependencies and dependency hell etc. Thanks in advance! Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi, Am Montag, 18. Juli 2022, 15:58:11 CEST schrieb Johannes Kastl:
Hi all,
is there a way to disable building of test subpackages (or multibuild packages or whatever the proper term is) on a per-project base?
Like e.g. python-setuptools which has a test "multibuild":
https://build.opensuse.org/package/show/devel:languages:python/python-setupt...
I think I could modify each and every _multibuild file or remove the test spec files from the packages, but I would rather like to avoid that and just set some flag on the project itself.
In my case I am just linking together several packages that are being tested somewhere else and would like to avoid having to link in all the test dependencies and their dependencies and dependency hell etc.
You can add "BuildFlags: excludebuild:python-setuptools:test" to the prjconf. Or coordinate a way with all relevant packages so that a macro disables tests in all of them, in %if 0%{?disable_tests}\nExclusiveArch: do_not_build\n%endif style. Cheers, Fabian
Thanks in advance!
Kind Regards, Johannes
-- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de
B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi Fabian, On 18.07.22 at 16:08 Fabian Vogt wrote:
Am Montag, 18. Juli 2022, 15:58:11 CEST schrieb Johannes Kastl:
Hi all,
is there a way to disable building of test subpackages (or multibuild packages or whatever the proper term is) on a per-project base?
You can add "BuildFlags: excludebuild:python-setuptools:test" to the prjconf.
Or coordinate a way with all relevant packages so that a macro disables tests in all of them, in %if 0%{?disable_tests}\nExclusiveArch: do_not_build\n%endif style.
The latter would require modifying each and every spec file, which I would like to avoid (as those are linked packages, where the diff might break if the source spec changes to much...). So I will try the former, which is only 5 lines for five packages I have. Thanks for the help! Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Am 18.07.22 um 16:11 schrieb Johannes Kastl:
Hi Fabian,
On 18.07.22 at 16:08 Fabian Vogt wrote:
Am Montag, 18. Juli 2022, 15:58:11 CEST schrieb Johannes Kastl:
Hi all,
is there a way to disable building of test subpackages (or multibuild packages or whatever the proper term is) on a per-project base?
You can add "BuildFlags: excludebuild:python-setuptools:test" to the prjconf.
Or coordinate a way with all relevant packages so that a macro disables tests in all of them, in %if 0%{?disable_tests}\nExclusiveArch: do_not_build\n%endif style.
The latter would require modifying each and every spec file, which I would like to avoid (as those are linked packages, where the diff might break if the source spec changes to much...).
So I will try the former, which is only 5 lines for five packages I have.
Thanks for the help!
Kind Regards, Johannes
Note that this probably saves you from test-specific packages but many packages only marked with BuildRequires in the :test multibuilds are still install requirements of the main package.
On 18.07.22 at 16:20 Ben Greiner wrote:
Note that this probably saves you from test-specific packages but many packages only marked with BuildRequires in the :test multibuilds are still install requirements of the main package.
Thanks for the hint, Ben. This is mostly a cosmetic issue, as all of the actual packages are building fine, but I want to have an ocean of green and not several failed or unresolvable packages that I do not care about. :-) Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Am 18.07.22 um 16:20 schrieb Ben Greiner:
Note that this probably saves you from test-specific packages but many packages only marked with BuildRequires in the :test multibuilds are still install requirements of the main package. What makes you think so? That would be a bug in the specific spec file. Buildrequires are one of the most frequent reason for multibuild flavors after all.
Greetings, Stephan
Am 18.07.22 um 16:33 schrieb Stephan Kulow:
Am 18.07.22 um 16:20 schrieb Ben Greiner:
Note that this probably saves you from test-specific packages but many packages only marked with BuildRequires in the :test multibuilds are still install requirements of the main package. What makes you think so? That would be a bug in the specific spec file. Buildrequires are one of the most frequent reason for multibuild flavors after all.
Greetings, Stephan
We are talking about Python modules here, not shared libraries which are found automatically. The most frequent reason for Python packages having multibuild :test flavors is specifically to prevent a BuildRequires depcycle. They the main package then has only Requires: but no BuildRequires: on the install dependencies. Sometimes (and I prefer this), the :test flavor BuildRequires the main package and thus there is no explicit BuildRequires: for the runtime dependencies [Example A], but this is not strictly necessary [Example B]. ## Example A: https://build.opensuse.org/package/show/devel:languages:python:mailman/pytho... %if %{with test} BuildRequires: %{python_module flufl.testing} BuildRequires: %{python_module nose2} BuildRequires: %{python_module pytest} BuildRequires: mailman3 = %{version} %endif %package -n mailman3 Summary: A mailing list manager ... Requires: %{mypython}-flufl.bounce >= 4.0 ... ---> main package: builds, but is not installable, because flufl.bounce is in another project :test unresolvable: nothing provides python39-flufl.bounce >= 4.0 needed by mailman3 (This is all resolved in staging https://build.opensuse.org/project/show/openSUSE:Factory:Staging:adi:21, where we are still waiting on uwsgi, BTW) ## Example B: https://build.opensuse.org/package/show/devel:languages:python/python-hypoth... Requires: python-hypothesis >= 5.46 Requires: python-lark-parser >= 0.7.2 Requires: python-libcst >= 0.3.8 %if %{with test} BuildRequires: %{python_module black} BuildRequires: %{python_module hypothesis >= 5.46} BuildRequires: %{python_module lark-parser >= 0.7.2} BuildRequires: %{python_module libcst >= 0.3.8} BuildRequires: %{python_module parso} BuildRequires: %{python_module pytest-xdist} BuildRequires: %{python_module pytest} %endif %check %if %{with test} # multibuild: test the source dir, nothing is installed export PYTHONPATH=$(pwd)/src %pytest -n auto %endif - Regards, Ben
Am 18.07.22 um 17:13 schrieb Ben Greiner:
https://build.opensuse.org/package/show/devel:languages:python/python-hypoth...
Requires: python-hypothesis >= 5.46 Requires: python-lark-parser >= 0.7.2 Requires: python-libcst >= 0.3.8 %if %{with test} BuildRequires: %{python_module black} BuildRequires: %{python_module hypothesis >= 5.46} BuildRequires: %{python_module lark-parser >= 0.7.2} BuildRequires: %{python_module libcst >= 0.3.8} BuildRequires: %{python_module parso} BuildRequires: %{python_module pytest-xdist} BuildRequires: %{python_module pytest} %endif
I think I misread your statement actually - thanks for clarifying. Greetings, Stephan
participants (4)
-
Ben Greiner -
Fabian Vogt -
Johannes Kastl -
Stephan Kulow