Bug 2077820

Summary: dnf builddep option --define rpm macro does not work with src.rpm
Product: Red Hat Enterprise Linux 8 Reporter: Mikhail Campos <Mikhail_Campos-Guadamuz>
Component: dnf-plugins-coreAssignee: Jan Kolarik <jkolarik>
Status: CLOSED ERRATA QA Contact: Eva Mrakova <emrakova>
Severity: unspecified Docs Contact:
Priority: low    
Version: 8.5CC: james.antill, jkolarik, mbanas, mdomonko, ppisar
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: dnf-plugins-core-4.0.21-16.el8 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of:
: 2121655 (view as bug list) Environment:
Last Closed: 2023-05-16 09:06:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2121655    

Description Mikhail Campos 2022-04-22 10:26:36 UTC
Description of problem:
I try to reproduce "dnf builddep" behavior from 

https://koji.mbox.centos.org/pkgs/packages/perl/5.32.1/471.module_el8.6.0+1067+91b0b3d4/data/logs/x86_64/root.log

While everything work OK there, I have problem with installing additional pkgs in my own machine (which I want to skip installing):

 perl-generators
 perl-interpreter

perl.spec defines the following:

 %if !%{defined perl_bootstrap}
BuildRequires:  perl-interpreter
BuildRequires:  perl-generators
%endif

Ok, I tried to use:

 dnf builddep --define "perl_bootstrap 1" perl-XXXXX.src.rpm

But it never worked. Even adding 'perl_bootstrap 1' somewhere to /etc/rpm/macros does not work.

Meanwhile as at is seen from log above, CentOS guys get correct builddep installation even without declaring "perl_bootstrap 1" anywhere in buildroot!
A pure magic as it usually has been with building perl since el8!

Could you please transform  '--define' so it can work with src.rpm correctly?


Version-Release number of selected component (if applicable):
python3-libdnf-0.63.0-3.el8.x86_64
libdnf-0.63.0-3.el8.x86_64
dnf-4.7.0-4.el8.noarch
python3-dnf-4.7.0-4.el8.noarch
python3-dnf-plugins-core-4.0.21-4.el8_5.noarch
dnf-data-4.7.0-4.el8.noarch
dnf-plugins-core-4.0.21-4.el8_5.noarch

How reproducible:
Always

Steps to Reproduce:
Described above

Actual results:
"--define" does not affect rpm macros expansion in spec inside src.rpm

Expected results:
"--define" affects rpm macros expansion in spec inside src.rpm

Comment 1 Petr Pisar 2022-04-25 11:42:53 UTC
The magic is installing module-build-macros. That package delivers RPM macros specified in buildopts section of a modulemd YAML file of a module the linked root.log is part of.

Comment 2 Mikhail Campos 2022-04-25 11:49:15 UTC
> But it never worked. Even adding 'perl_bootstrap 1' somewhere to /etc/rpm/macros does not work

Note, as I wrote above, simulating module-build-macros does not work, for some reason. Seems like a separate bug.

Anyway, it would be nice to use dnf builddep "--define" as a second option.

Comment 3 Jaroslav Mracek 2022-07-11 13:59:10 UTC
We add the macro into rpm using following code:

        for macro in self.opts.define:
            rpm.addMacro(macro[0], macro[1])

Therefore I am still not convinced if it is a bug or not.

Comment 4 Michal Domonkos 2022-07-12 10:47:15 UTC
An SRPM records its build dependencies as normal "requires".  When dnf-builddep(8) runs against an SRPM, it looks at those (see "rpm -qR perl-XXXXX.src.rpm").  Passing a --define to dnf-builddep won't change anything since the SRPM is already built.

You need to either rebuild the SRPM with rpmbuild(8) and pass it the desired --define, or install the existing SRPM ("rpm -i perl-XXXXX.src.rpm") first and then run dnf-builddep on the SPEC file (by default at ~/rpmbuild/SPECS/*.spec) in which case passing the --define would work.

Here's a simple SPEC to demonstrate this:

Name: foo
Version: 1
Release: 1%{?dist}
Summary: Foo package

License: GPL

%if %{defined bar}
BuildRequires: bar
%endif

%description
%{summary}.

%prep
%build
%install
%files

$ rpmbuild -bs foo.spec
[...]
$ rpm -qR /path/to/foo.srpm | grep bar
$ rpmbuild -bs --define "bar 1" foo.spec
[...]
$ rpm -qR /path/to/foo.srpm | grep bar
bar

Comment 5 Michal Domonkos 2022-07-12 10:49:34 UTC
The difference between the SRPM and SPEC variants with dnf-builddep was also recently discussed here: https://bugzilla.redhat.com/show_bug.cgi?id=2087703

Comment 6 Jaroslav Mracek 2022-07-12 11:32:40 UTC
Thank you very much Michal for your expertise. I am proposing to only add a note in documentation that define is not applied to srpm arguments.

Comment 7 Mikhail Campos 2022-07-12 14:00:24 UTC
Please, consider printing also some warning message if --define is used with src.rpm

Comment 8 Jan Kolarik 2022-08-11 12:16:20 UTC
A note was added to the man page and also warning is shown when using -D or --define with source rpm files.

Following PRs were queued to fix this:

fix:   https://github.com/rpm-software-management/dnf-plugins-core/pull/461
tests: https://github.com/rpm-software-management/ci-dnf-stack/pull/1142

Comment 10 Jan Kolarik 2022-08-26 06:46:59 UTC
Cloned into RHEL9 ticket https://bugzilla.redhat.com/show_bug.cgi?id=2077820.

Comment 11 Jan Kolarik 2022-08-26 06:49:51 UTC
(In reply to Jan Kolarik from comment #10)
> Cloned into RHEL9 ticket https://bugzilla.redhat.com/show_bug.cgi?id=2077820.

Sorry, wrong link. This is RHEL9 clone: https://bugzilla.redhat.com/show_bug.cgi?id=2121655

Comment 18 errata-xmlrpc 2023-05-16 09:06:30 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (dnf-plugins-core bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2975