On Fedora 33:

# dnf --version
4.2.19
  Installed: dnf-0:4.2.19-1.fc33.noarch at Mon Mar  9 22:30:02 2020
  Built    : Fedora Project at Mon Feb 24 15:39:29 2020

  Installed: rpm-0:4.15.1-2.fc32.1.x86_64 at Mon Mar  9 22:30:02 2020
  Built    : Fedora Project at Thu Jan 30 18:22:57 2020

# dnf --refresh repoquery --repo=rawhide{,-source} --whatrequires python3-flaky
python-ipykernel-0:5.1.4-1.fc33.src

I have created a PR to fix the bug: 
https://github.com/rpm-software-management/libdnf/pull/914

Also some tests:
https://github.com/rpm-software-management/ci-dnf-stack/pull/807
https://github.com/rpm-software-management/ci-dnf-stack/pull/805

The upstream PR was merged. Is there an ETA for this to land in F32?

This has a potential of destructive actions by package maintainers based on the incomplete results.

+1 to get this fixed soon in Fedora 32.

Proposing this as a prioritized bug.

Proposing as a potential F32 Blocker

Discussed during the 2020-03-30 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker" was made as there is no indication that this breaks any of the release criteria, or any other justification for blocking release on this.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-03-30/f32-blocker-review.2020-03-30-16.00.txt

FEDORA-2020-024485d896 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-024485d896

Huh! This bug has really caused me frustration now that I mistakenly used it as reference to fix fonttools package.

FEDORA-2020-024485d896 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-024485d896`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-024485d896

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

I have been trying to edit bodhi update yesterday madly like for 1 hour but it did not allowed me to edit it. The update was not even in lock state. Looks like Bodhi project is also in danger with lack of support? anyways sorry again.

Our current policy is to only backport blocker bugs at this stage of F32 schedule so I am afraid this is going to land in F32 only after its released.

Do you provide any nightly kind of builds (say copr repo)? I can point my system to that repo and have this bug fix installed on my system.

> Our current policy

I kindly ask you to break this policy here. This bug is very bad, but it has no blocker potential.

Who do I have to convince to ship this?

> Do you provide any nightly kind of builds (say copr repo)?
yes, we have: https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf-nightly/

I will ask about backporting this on our tomorrows morning meeting.

It would be really nice if we could get this fixed in f32 *before* GA.

It might not be a candidate for an official BlockerBug, but it's blocking *me* from upgrading my main machine to f32,  due to the work I do for the Stewardship SIG and the fedora-health-check project - both of which rely on "repoquery" actually returning correct results :(

FEDORA-2020-6ba2550a4e has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6ba2550a4e

FEDORA-2020-6ba2550a4e has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

FTR, I already commented on the bodhi update, but I'll include my feedback here as well for completeness:

I am still getting incomplete results when querying with virtual provides:

```
$ sudo dnf repoquery --whatrequires python3-poetry
poetry-0:1.0.5-1.fc32.noarch
python3-chaospy-0:3.0.17-1.fc32.noarch

$ sudo dnf repoquery --whatrequires "python3dist(poetry)"
python3-chaospy-0:3.0.17-1.fc32.noarch
```

So the fix looks incomplete ...

Though it looks like the issue from my last comment is not a regression on fedora 32 but is already present on fedora 31 as well ... so this is definitely not high priority right now.

That was always the case. You need to use the real package name to also get results for all the virtual provides it has.

What you want is a valid RFE (I was thinking about that myself quite recently), but not related to this problem.

Wait, that seems like it would be a misfeature to me?

What even would be the feature? "If I query for a given virtual provide, also return anything that requires anything else provided by any package which provides that virtual provide"? That seems like a very odd feature. Why, if I do "dnf repoquery --whatrequires system-release", would I also want to know what requires fedora-release or generic-release ?

At the very least such a feature should be switchable. (And in fact it should also be possible to query only for things that literally require "python3-poetry", not things that require *anything provided by the package python3-poetry*).

Apologies if I misunderstood...

> What even would be the feature?

So if I for example do `--whatrequires python2` I am interested on what requires the package that provides python2, not what package requires "python2" exactly.

But this gets fuzzy, if I do `--whatrequires bundled(libx)` I am most likely checking that nothing requires this than "what requires any package that bundles libx".

In either way both queries do make sense to me.


> And in fact it should also be possible to query only for things that literally require "python3-poetry", not things that require *anything provided by the package python3-poetry*

You can:

  --alldeps             check non-explicit dependencies (files and Provides); default
  --exactdeps           check dependencies exactly as given, opposite of --alldeps