#1346 Cannot make buildopts work
Closed: Invalid 4 years ago by mprahl. Opened 4 years ago by mprahl.


This works fine for me using %bcond_with and %bcond_without for example:

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.

That makes me wonder, are those buildopts passed only to the main rpm build, not to all 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.

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)

4 years ago

Login to comment on this ticket.

Metadata