$ mkdir test; pushd test $ >a.spec cat <<EOF Name: a Version: 1 Release: 1%{?dist} Summary: a License: MIT Provides: foo-a%{?_isa} = %{version}-%{release} %prep echo a > doc %description a %files %doc doc EOF $ >b.spec cat <<EOF Name: b Version: 1 Release: 1%{?dist} Summary: b License: MIT Recommends: foo-a %prep echo b > doc %description b %files %doc doc EOF $ rpmbuild -D "_builddir $(pwd)" -D "_rpmdir $(pwd)" -bb a.spec $ rpmbuild -D "_builddir $(pwd)" -D "_rpmdir $(pwd)" -bb b.spec $ createrepo_c . $ su -c "dnf --repofrompath test,$(pwd) --disablerepo='*' \ --enablerepo=test --setopt=install_weak_deps=1 --refresh install b" > Dependencies resolved. > ================================================================================ > Package Arch Version Repository Size > ================================================================================ > Installing: > b x86_64 1-1.fc30 test 6.4 k > > Transaction Summary > ================================================================================ > Install 1 Package i.e., a is not getting selected despite being a soft dependency of b. With: -Provides: foo-a%{?_isa} = %{version}-%{release} +Provides: foo-a% = %{version}-%{release} in a.spec, it works as expected. I don't see any reason the arch-qualified variant should not work as well.
I'm absolutely positive I already commented this on Friday, but that's nowhere to be seen. There's no bug here. If you use %{?_isa} in provides, you need to use it in the dependency-side too, weak dependency or otherwise. These aren't any magically interpreted strings, %{?_isa} is expanded on build-time. When dnf gets to it, it's just a simple string comparison between "foo-a(x86-64)" vs "foo-a", literally, and clearly those do not match.
TBH, I didn't look at _isa macro in detail before, and I see now: $ rpm -q --provides psmisc > psmisc = 23.1-4.fc29 > psmisc(x86-64) = 23.1-4.fc2 i.e., arch-qualified package implicitly maps to dual Provides: under the hood, so that there needs to be no extra sophistication in depsolving time. That makes sense, sense for clarification, Panu. But this automatism doesn't work with anything explicit, perhaps to avoid unexpected side-effects/behaviour. So the Right Thing in such a case may be to provide both arch-qualified and arch-less Provides: (given this is for arch-specific packaged, indeed) explicitly, so as to allow the dependant for this convenient deliberation regarding which form to select. Looks like following macro might be useful generally (assuming redundant entries will get deduplicated automatically): %define virtual_provides() Provides: %1 %{?2: = %2} %1%{?_isa} %{?2: = %2} What do you think? At least the versions are "magically" parsed for the (in)equality comparisons should the dependant be picky about the version on the providing side, correct?
* thanks for clarification
Needing both for virtual provides is fairly rare, just add both manually if you really need them. Most of the time you can get by with the archless-version anyway.
re [comment 14]: > Needing both for virtual provides is fairly rare Not that rare if you look only on the packages that carry Provides: at all; I've counted some 250+ examples within Fedora spec files. Hence raising this up to be considered: https://github.com/rpm-software-management/rpm/pull/614 Thanks.