Bug 1659259 - [depsolv] dnf ignores weak dependencies in case of architecture-qualified virtual Provides: being their target
Summary: [depsolv] dnf ignores weak dependencies in case of architecture-qualified vir...
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 1659462
TreeView+ depends on / blocked
Reported: 2018-12-13 22:24 UTC by Jan Pokorný [poki]
Modified: 2018-12-18 15:00 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1659462 (view as bug list)
Last Closed: 2018-12-17 12:20:24 UTC
Type: Bug

Attachments (Terms of Use)

Description Jan Pokorný [poki] 2018-12-13 22:24:28 UTC
$ 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}

echo a > doc


%doc doc

$ >b.spec cat <<EOF
Name:		b
Version:	1
Release:	1%{?dist}
Summary:	b
License:	MIT

Recommends:     foo-a

echo b > doc


%doc doc

$ 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.


-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.

Comment 1 Panu Matilainen 2018-12-17 12:20:24 UTC
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.

Comment 2 Jan Pokorný [poki] 2018-12-17 17:21:31 UTC
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?

Comment 3 Jan Pokorný [poki] 2018-12-17 17:22:24 UTC
* thanks for clarification

Comment 4 Panu Matilainen 2018-12-18 07:08:24 UTC
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.

Comment 5 Jan Pokorný [poki] 2018-12-18 15:00:03 UTC
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:



Note You need to log in before you can comment on or make changes to this bug.