Bug 1565647 - No match for a package that exists in the repo
Summary: No match for a package that exists in the repo
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jaroslav Mracek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Triaged
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-10 13:21 UTC by Lubomír Sedlář
Modified: 2018-08-01 14:56 UTC (History)
10 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-06-28 08:02:08 UTC


Attachments (Terms of Use)

Description Lubomír Sedlář 2018-04-10 13:21:22 UTC
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

Comment 1 Lubomír Sedlář 2018-04-11 05:48:16 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.

Comment 2 Jaroslav Mracek 2018-04-16 12:28:53 UTC
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

Comment 3 Lubomír Sedlář 2018-04-16 13:14:57 UTC
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

Comment 4 Jaroslav Mracek 2018-04-17 14:14:26 UTC
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.

Comment 5 Jonathan Lebon 2018-04-18 17:39:48 UTC
> 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.

Comment 6 Colin Walters 2018-04-25 21:03:48 UTC
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.

Comment 7 Panu Matilainen 2018-04-26 05:03:46 UTC
dnf might not need to "install" source packages either but being able to query them is a fundamental requirement.

Comment 8 Colin Walters 2018-04-26 13:48:48 UTC
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

Comment 9 Colin Walters 2018-04-26 13:59:43 UTC
> 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).

Comment 11 Jaroslav Mracek 2018-06-05 14:43:48 UTC
No, problem was not yet solved in DNF itself. But we are working on patch.

Comment 12 Jaroslav Mracek 2018-06-18 12:35:26 UTC
Final patch is here: https://github.com/rpm-software-management/dnf/pull/1112

Comment 13 Jaroslav Mracek 2018-06-28 08:02:08 UTC
The issue is solved by libdnf-0.15.1-1 that was released into rawhide.

Comment 14 Jonathan Lebon 2018-08-01 14:56:13 UTC
Rawhide build rpm-ostree-2018.6.42.gda27b94b-1.fc29 contains the libdnf fix for this.


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