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-core | Assignee: | Jan Kolarik <jkolarik> | |
| Status: | CLOSED ERRATA | QA Contact: | Eva Mrakova <emrakova> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | low | |||
| Version: | 8.5 | CC: | james.antill, jkolarik, mbanas, mdomonko, ppisar | |
| Target Milestone: | rc | Keywords: | Triaged | |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
|
| 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
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. > 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.
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.
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
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 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. Please, consider printing also some warning message if --define is used with src.rpm 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 Cloned into RHEL9 ticket https://bugzilla.redhat.com/show_bug.cgi?id=2077820. (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 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 |