Description of problem:
DNF fails to find a match for a package. However there is a package in the repo that provides the given name.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
$ dnf install grub2 --repo r --repofrompath=r,https://kojipkgs.fedoraproject.org/compose/updates/Fedora-27-updates-20180405.0/work/x86_64/repo --installroot=/srv/ -v --releasever 27
DNF version: 2.7.5
Added r repo from https://kojipkgs.fedoraproject.org/compose/updates/Fedora-27-updates-20180405.0/work/x86_64/repo
r 74 MB/s | 42 MB 00:00
not found deltainfo for: r
not found updateinfo for: r
r: using metadata from Thu 05 Apr 2018 01:04:59 PM UTC.
Last metadata expiration check: 0:00:09 ago on Tue 10 Apr 2018 07:56:14 AM UTC.
* Maybe you meant: grub2
No match for argument: grub2
Error: Unable to find a match
It will find the package and not complain
The repo is not really usable from everywhere, the packages are only available on the local filesystem, but the command fails even in situation when the filesystem is available.
This is the relevant section of the repo metadata:
<version epoch="1" ver="2.02" rel="22.fc27"/>
<checksum type="sha256" pkgid="YES">de719fc51853fc7faadfe92d5c6a81057350ec5cc1e8cdc7f296fe3cfc6721c0</checksum>
<summary>Bootloader with support for Linux, Multiboot, and more</summary>
<time file="1516743477" build="1516742769"/>
<size package="26112" installed="0" archive="276"/>
<location xml:base="file:///mnt/koji/" href="packages/grub2/2.02/22.fc27/data/signed/f5282ee4/x86_64/grub2-pc-2.02-22.fc27.x86_64.rpm"/>
<rpm:header-range start="4504" end="25932"/>
<rpm:entry name="config(grub2-pc)" flags="EQ" epoch="1" ver="2.02" rel="22.fc27"/>
<rpm:entry name="grub2" flags="EQ" epoch="1" ver="2.02" rel="22.fc27"/>
<rpm:entry name="grub2-pc" flags="EQ" epoch="1" ver="2.02" rel="22.fc27"/>
<rpm:entry name="grub2-pc(x86-64)" flags="EQ" epoch="1" ver="2.02" rel="22.fc27"/>
This is related to Pungi issue#890
The same happens when the repository is specified by file:///mnt/koji/... URL, it does not seem to be caused by repodata being accessed by HTTP but actual packages being on local filesystem.
I see the issue. This is a problem of source package. You want to install grub2-pc but you use the provide grub2. This is fine. But dnf try first to identify packages according to NEVRA, but in your set there is a grub2.src package. Therefore query returns successful result, but then the package is excluded, therefore nothing to install.
I believe that -x grub2.src will fix your problem
Adding -x grub2.src still gives me a rather confusing error message:
Last metadata expiration check: 0:01:04 ago on Mon Apr 16 15:11:38 2018.
--> Starting dependency resolution
--> Finished dependency resolution
Problem: conflicting requests
- nothing provides which needed by grub2-pc-1:2.02-22.fc27.i686
- nothing provides which needed by grub2-pc-1:2.02-22.fc27.x86_64
I was also confused until I tried "dnf repoquery --requires grub2-pc" and I saw:
grub2-common = 1:2.02-22.fc27
grub2-pc-modules = 1:2.02-22.fc27
grub2-tools = 1:2.02-22.fc27
grub2-tools-extra = 1:2.02-22.fc27
grub2-tools-minimal = 1:2.02-22.fc27
It means that there is no package that provides which.
> You want to install grub2-pc but you use the provide grub2. This is fine. But dnf try first to identify packages according to NEVRA, but in your set there is a grub2.src package.
Right, I see this happen in the code. Though I'm not sure it's right behaviour. I definitely agree that in most cases, you want to prioritize HY_FORM_NAME vs Provides (see also https://github.com/rpm-software-management/libdnf/pull/224). But it feels like if the only matches are src pkgs, we should at least also check if we can find non-src pkgs when matching by Provides?
IOW, given a repo with the following packages:
ISTM that querying for the subject "grub2" should pick "grub2-pc", no? (And then installing the src specifically can be "grub2.src"?). IMO, I think most users would be surprised to see the opposite happen.
> Adding -x grub2.src still gives me a rather confusing error message
Talking to Lubomír on IRC, the closest rpm-ostree version of this is adding "exclude=grub2.src" to the repo file. But that doesn't work right now because libdnf processes excludes expecting an exact package match. We should probably fix this (I think yum allowed this, no?), though it'd be nicer if we could tweak things as mentioned above instead.
Offhand...I don't understand why we're not doing
`hy_query_filter(query, HY_PKG_ARCH, HY_NEQ, "src")`
globally. For rpm-ostree in particular we simply never ever want to install a source package. I am less certain of the dnf use cases for this...but let me spin up a strawman patch.
dnf might not need to "install" source packages either but being able to query them is a fundamental requirement.
Right, of course. When I said "globally" I was thinking of the codepaths called from `dnf_context_install()`.
Currently libdnf has:
def _get_best_selectors(self, base, forms=None, obsoletes=True, reponame=None, reports=False,
which then does:
q = q.filter(arch__neq="src")
I'm confused though why get_best_selectors() ends up calling get_best_solution()...
> It means that there is no package that provides which.
This is because you need the "gold" repository enabled too. Adding `--repo fedora` to the cmdline changes the error to be the expected: "No match for argument: grub2 ".
Then -x grub2.src works for me, i.e. the full cmdline is:
# dnf --nogpgcheck install -x grub2.src grub2 --repo fedora --repo r --repofrompath=r,https://kojipkgs.fedoraproject.org/compose/updates/Fedora-27-updates-20180405.0/work/x86_64/repo --installroot=/srv/ -v --releasever 27
But anyways the best fix is in rpm-ostree for now, though we should clearly fix libdnf too (and make dnf use libdnf's logic).
was this fixed upstream in https://github.com/rpm-software-management/libdnf/pull/468 / https://github.com/rpm-software-management/libdnf/commit/6360ef112158fa1d9bf1a5c1865de7d3d53ac9e5 ?
No, problem was not yet solved in DNF itself. But we are working on patch.
Final patch is here: https://github.com/rpm-software-management/dnf/pull/1112
The issue is solved by libdnf-0.15.1-1 that was released into rawhide.
Rawhide build rpm-ostree-2018.6.42.gda27b94b-1.fc29 contains the libdnf fix for this.