Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1812596 - repoquery suddenly missing results in --whatrequires on Fedora 32+ (seem to be related to virtual provides)
Summary: repoquery suddenly missing results in --whatrequires on Fedora 32+ (seem to b...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 32
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: amatej
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
Depends On:
Blocks: F32FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2020-03-11 16:17 UTC by Miro Hrončok
Modified: 2020-04-06 19:44 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-05 12:28:13 UTC
Type: Bug
Embargoed:
mhroncok: fedora_prioritized_bug?


Attachments (Terms of Use)

Description Miro Hrončok 2020-03-11 16:17:00 UTC
On Fedora 31:

# dnf --version
4.2.18
  Installed: dnf-0:4.2.18-1.fc31.noarch at Wed Mar  4 05:47:45 2020
  Built    : Fedora Project at Wed Jan 15 13:58:49 2020

  Installed: rpm-0:4.15.1-1.fc31.x86_64 at Wed Mar  4 05:47:44 2020
  Built    : Fedora Project at Tue Nov 19 09:40:20 2019

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


On Fedora 32:

# dnf --version
4.2.19
  Installed: dnf-0:4.2.19-1.fc32.noarch at Wed 11 Mar 2020 11:18:59 AM GMT
  Built    : Fedora Project at Mon 24 Feb 2020 05:44:09 PM GMT

  Installed: rpm-0:4.15.1-2.fc32.1.x86_64 at Wed 11 Mar 2020 11:12:43 AM GMT
  Built    : Fedora Project at Thu 30 Jan 2020 06:22:57 PM GMT


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




Note that pipenv buildrequires 'python3dist(flaky)' which is provided by the python3-flaky package.

Comment 1 Miro Hrončok 2020-03-11 16:26:07 UTC
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

Comment 3 Miro Hrončok 2020-03-28 12:55:13 UTC
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.

Comment 4 Parag Nemade 2020-03-30 11:03:49 UTC
+1 to get this fixed soon in Fedora 32.

Comment 5 Miro Hrončok 2020-03-30 12:16:31 UTC
Proposing this as a prioritized bug.

Comment 6 Jens Petersen 2020-03-30 15:10:33 UTC
Proposing as a potential F32 Blocker

Comment 7 Geoffrey Marr 2020-03-30 19:03:27 UTC
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

Comment 8 Fedora Update System 2020-03-31 15:18:49 UTC
FEDORA-2020-024485d896 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-024485d896

Comment 9 Parag Nemade 2020-03-31 15:22:07 UTC
Huh! This bug has really caused me frustration now that I mistakenly used it as reference to fix fonttools package.

Comment 10 Fedora Update System 2020-04-01 02:15:07 UTC
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.

Comment 11 Parag Nemade 2020-04-01 02:52:35 UTC
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.

Comment 12 amatej 2020-04-02 07:21:56 UTC
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.

Comment 13 Parag Nemade 2020-04-02 07:34:59 UTC
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.

Comment 14 Miro Hrončok 2020-04-02 07:51:07 UTC
> 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?

Comment 15 amatej 2020-04-02 11:22:08 UTC
> 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.

Comment 16 Fabio Valentini 2020-04-02 11:33:25 UTC
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 :(

Comment 17 Fedora Update System 2020-04-03 11:20:12 UTC
FEDORA-2020-6ba2550a4e has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6ba2550a4e

Comment 18 Fedora Update System 2020-04-04 00:45:43 UTC
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.

Comment 19 Fabio Valentini 2020-04-05 11:47:32 UTC
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 ...

Comment 20 Fabio Valentini 2020-04-05 11:57:06 UTC
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.

Comment 21 Miro Hrončok 2020-04-05 12:28:13 UTC
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.

Comment 22 Adam Williamson 2020-04-06 18:54:31 UTC
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...

Comment 23 Miro Hrončok 2020-04-06 19:44:49 UTC
> 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


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