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): dnf 2.7.5-2.fc27 How reproducible: always 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 Actual results: DNF version: 2.7.5 cachedir: /srv/var/cache/yum 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 Expected results: It will find the package and not complain Additional info: 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: <package type="rpm"> <name>grub2-pc</name> <arch>x86_64</arch> <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> <description>...</description> <packager>Fedora Project</packager> <url>http://www.gnu.org/software/grub/</url> <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"/> <format> <rpm:license>GPLv3+</rpm:license> <rpm:vendor>Fedora Project</rpm:vendor> <rpm:group>System Environment/Base</rpm:group> <rpm:buildhost>bkernel01.phx2.fedoraproject.org</rpm:buildhost> <rpm:sourcerpm>grub2-2.02-22.fc27.src.rpm</rpm:sourcerpm> <rpm:header-range start="4504" end="25932"/> <rpm:provides> <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"/> </rpm:provides> <rpm:requires>...</rpm:requires> <rpm:obsoletes>...</rpm:obsoletes> <file>/etc/grub2.cfg</file> </format> </package> This is related to Pungi issue#890 https://pagure.io/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 Error: 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: dracut file gettext 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 which 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: grub2-2.02-23.fc27.src.rpm grub2-pc-2.02-23.fc27.x86_64.rpm 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, solution=None): ... which then does: q = q.filter(arch__neq="src") I'm confused though why get_best_selectors() ends up calling get_best_solution()... Anyways: https://github.com/projectatomic/libdnf/pull/1
> 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.