Bug 1455452 (ovirt-dnf-2.0-support) - [Tracker] Adapt to dnf-2.0
Summary: [Tracker] Adapt to dnf-2.0
Keywords:
Status: CLOSED DEFERRED
Alias: ovirt-dnf-2.0-support
Product: otopi
Classification: oVirt
Component: Plugins.packagers
Version: master
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
: ---
Assignee: Yedidyah Bar David
QA Contact: Lucie Leistnerova
URL:
Whiteboard:
Depends On: 1441164 1455456 1455482 1542492 1542529
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-25 08:53 UTC by Yedidyah Bar David
Modified: 2020-06-26 16:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-01 14:47:42 UTC
oVirt Team: Integration
Embargoed:
ylavi: ovirt-4.3+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1344270 0 medium CLOSED dnf: Check package signature 2021-05-01 16:57:05 UTC

Internal Links: 1344270

Description Yedidyah Bar David 2017-05-25 08:53:49 UTC
Description of problem:

dnf-2.0 [1], to be included in fedora 26, drops all non-official functions [2].

This bug is to track all current such uses in otopi.

[1] https://fedoraproject.org/wiki/Changes/DNF-2.0
[2] http://dnf.readthedocs.io/en/latest/dnf-1_vs_dnf-2.html#all-non-api-methods-and-attributes-are-private

Comment 1 Michal Skrivanek 2020-03-19 15:41:37 UTC
We didn't get to this bug for more than 2 years, and it's not being considered for the upcoming 4.4. It's unlikely that it will ever be addressed so I'm suggesting to close it.
If you feel this needs to be addressed and want to work on it please remove cond nack and target accordingly.

Comment 2 Yedidyah Bar David 2020-03-22 06:58:14 UTC
Closing current bug means we slightly raise the chance that dnf will break otopi unexpectedly. I can live with that, as long as this is clear.

I actually looked at it a few days ago, and the summary IIRC is:

We already simply use private dnf methods (can break anytime), except for one case (IIRC not tracked by current bug, even indirectly): We stopped checking signatures completely, waiting for dnf to officially expose means to do that. See bug 1339617 and bug 1344270. I think I'll simply push a patch to use the private method _sig_check_pkg and forget about it as well, until it breaks.

Comment 3 Michal Skrivanek 2020-04-01 14:47:42 UTC
Closing old bug. Please reopen if still relevant/you want to work on it.


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