Hi all,
if I read the docs[1] correctly, it is enough for a %_with_XXX feature to be defined, the value does not matter. So setting it to 0 does not disabled it.
TL;DR: Is it possible to to un-define a %_with_XXX at project level in the prjconf?
I already tried defining %_without_XXX, but that did not work, apparently as %_with_XXX was still defined.
In my case I am trying to package some rubygems for SLES15/Leap15 using a newer ruby. I managed to get the ruby to be co-installable without causing harm, and if I drop large parts of the rubygems-gem2rpm spec file, I get building packages. But as the rubygems-gem2rpm spec file has these nice little %bcond_with_ruby21 and "%if %{with ruby21}" things, I tried to built without touching it. I succeeded in getting some packages to build by just building for ruby21 and ruby31, but as soon as a package requires ruby > 2.5 it falls apart.
Hence my question: Can I un-define or disable a %_with_ruby21 or similar at project level? Or do I need to modify the spec file?
Kind Regards Johannes
[1] https://en.opensuse.org/openSUSE:RPM_conditional_builds https://en.opensuse.org/openSUSE:Build_Service_prjconf#%25bcond
On 12.12.22 at 07:36 Johannes Kastl wrote:
Hi all,
if I read the docs[1] correctly, it is enough for a %_with_XXX feature to be defined, the value does not matter. So setting it to 0 does not disabled it.
TL;DR: Is it possible to to un-define a %_with_XXX at project level in the prjconf?
Forgot an important part: "Is it possible to to un-define a %_with_XXX at project level in the prjconf? If I build against a build target that already defines this in its prjconf and I would like to remove/disable it?"
I already tried defining %_without_XXX, but that did not work, apparently as %_with_XXX was still defined.
On Dez 12 2022, Johannes Kastl wrote:
TL;DR: Is it possible to to un-define a %_with_XXX at project level in the prjconf?
No. The prjconf format (which follows the format of an RPM macro file, see `Configuration using Macros' in https://rpm-software-management.github.io/rpm/manual/macros.html) does not have a way to undefine predefined or previously defined macros. You can only redefine a macro, possible with an empty value (which won't help in your case).
I already tried defining %_without_XXX, but that did not work, apparently as %_with_XXX was still defined.
Yes, that is a shortcoming of the %with machinery.
On 12.12.22 10:28, Andreas Schwab wrote:
On Dez 12 2022, Johannes Kastl wrote:
TL;DR: Is it possible to to un-define a %_with_XXX at project level in the prjconf?
No. The prjconf format (which follows the format of an RPM macro file, see `Configuration using Macros' in https://rpm-software-management.github.io/rpm/manual/macros.html) does not have a way to undefine predefined or previously defined macros. You can only redefine a macro, possible with an empty value (which won't help in your case).
%define %_with_foo %{nil}
might help.
On Dez 12 2022, Stefan Seyfried wrote:
On 12.12.22 10:28, Andreas Schwab wrote:
On Dez 12 2022, Johannes Kastl wrote:
TL;DR: Is it possible to to un-define a %_with_XXX at project level in the prjconf?
No. The prjconf format (which follows the format of an RPM macro file, see `Configuration using Macros' in https://rpm-software-management.github.io/rpm/manual/macros.html) does not have a way to undefine predefined or previously defined macros. You can only redefine a macro, possible with an empty value (which won't help in your case).
%define %_with_foo %{nil}
might help.
As I already said, defining to an empty value does _not_ help in his case.
On 12.12.22 at 13:34 Andreas Schwab wrote:
On Dez 12 2022, Stefan Seyfried wrote:
%define %_with_foo %{nil}
might help.
As I already said, defining to an empty value does _not_ help in his case.
Unfortunately, setting to %nil does not work.
So I have no other way than fumbling with the spec file. OK, so be it. At least I know that I did not misunderstand the whole %_with_XXX business.
Thanks for the help and confirmation, Andreas and Seife!
Kind Regards, Johannes