Bug 1565647
| Summary: | No match for a package that exists in the repo | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Lubomír Sedlář <lsedlar> |
| Component: | dnf | Assignee: | Jaroslav Mracek <jmracek> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 27 | CC: | dmach, dustymabe, jlebon, jmracek, mhatina, packaging-team-maint, pmatilai, rpm-software-management, vmukhame, walters |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-06-28 08:02:08 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: | |||
|
Description
Lubomír Sedlář
2018-04-10 13:21:22 UTC
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. |