Hide Forgot
Created attachment 1200944 [details] Reproducer of this issue Description of problem: I am trying to build a script to figure out the set of packages required to be self-hosting. While doing so, I noticed a number of packages appearing in the list that didn't make any sense (such as 0ad, a video game that doesn't Provides: anything at all). I managed to narrow it down to some sort of strange interaction when I take the pkg.requires from a query against one set of repositories (sources) and apply it to the Provides of another set of repos (binaries). Version-Release number of selected component (if applicable): python2-dnf-1.1.10-1.fc24.noarch python2-hawkey-0.6.3-6.fc24.x86_64 libsolv-0.6.23-4.fc24.x86_64 How reproducible: Every time Steps to Reproduce: 1. Run attached minimal reproducer 2. 3. Actual results: Reproducer returns 2710 packages satisfying the "gcc-c++" dependency. Expected results: Reproducer should only return the "gcc-c++" package. Additional info: It's possible I've hit an edge-case. If that's so, please recommend a different way that I can determine the BuildRequires of an SRPM and get the list of binary RPMs that satisfies it.
Looks like you just can't mix-and-match results from different repositories. James Antill pointed out that wrapping the req in str(req) was a decent workaround, which I am going ahead with.
You can mix-and-match results from different repos, but not from different sacks.
Could we make this a documentation issue, then? Please indicate somewhere in documentation that the objects returned from filtering on one sack are useful only when used within that sack.
I tested with latest upstream version dnf-2.1.0_1-25g6394542.fc25.noarch libdnf-0.8.0-0.12gde205c0.fc25.x86_64 libsolv-0.6.26-17g3edcaac.fc25.x86_64 and it works like expected. Your script only returns libstdc++-6.3.1-1.fc25.x86_64. If you want to test it, please use latest dnf from our test repository (dnf copr enable rpmsoftwaremanagement/dnf-nightly).