Filing from https://bugzilla.redhat.com/show_bug.cgi?id=1729985
This works fine for me using %bcond_with and %bcond_without for example:
%bcond_with
%bcond_without
https://src.fedoraproject.org/modules/eclipse/blob/2019-06/f/eclipse.yaml#_106
Maybe you can work around it that way for now?
That link points somewhere into the "middle" of the .yaml file, but if I understood it correctly, then my .yaml can have something like this:
buildopts: rpms: macros: | %_with_eds_dbus_services_prefix org.gnome.Evolution
which I should be able to reference in the .spec file of any of the
components: rpms:
components, thus I added into one of them:
%if 0%{with eds_dbus_services_prefix} != 0 echo "may use dbus prefix:,%{with eds_dbus_services_prefix}," exit 1 %else echo "no eds dbus prefix:,%{with eds_dbus_services_prefix}," exit 1 %endif
(the exit 1 is used for early stop of the build, just for the test purposes) and the result in the build log is:
DEBUG: RPM build errors: DEBUG: + echo 'no eds dbus prefix:,0,' DEBUG: + exit 1
In other words, I need to pass custom string into the rpm build of certain subpackage (or all the .yaml file builds, that's why I prefix the variable name).
The _with.... doesn't work even when I define it as 1 instead of a custom string in the .yaml file.
_with....
1
That makes me wonder, are those buildopts passed only to the main rpm build, not to all components?
components
Oops, I clearly edited the file after linking to it. The relevant section is:
buildopts: rpms: macros: | %_with_jp_minimal 1
Then in my spec file I can have this, for example:
%bcond_with jp_minimal .... %if %{without jp_minimal} BuildRequires: <some_extra_req> Requires: <some_extra_req> %endif
This case works perfectly for me, for all RPM components given in the yaml file.
A little update after some code reading and debugging:
I see the
%_with_eds_dbus_services_prefix org.gnome.Evolution
in the # Macros set by module author: section of the macros.modules file in /tmp/module_build_service-build-macrosXXXXXXXX/SOURCES directory, thus it's properly passed somewhere from the .yaml file.
# Macros set by module author:
macros.modules
/tmp/module_build_service-build-macrosXXXXXXXX/SOURCES
Err, of course, the problem was on my side. I'm sorry for a false report.
Tow workaround waste of resources, network bandwidth and time, I have created a local repository where I place packages downloaded during the build, thus they can be reused. I also add packages from the build itself, thus when I find an error in one of the BuildRequire-s I do not need to rebuild already built packages. I also included module-build-macros packages in this repository, thus even the mbs created a new package with the added buildopts, the dnf/yum picked previously built module-build-macros instead, that without added custom macro. Once I clean up my local repository it begun to work as expected.
Again, I'm sorry. I (obviously) didn't know what I'm doing.
Metadata Update from @mprahl: - Issue close_status updated to: Invalid - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.