Bug 979353

Summary:	[rfe] [rel-eng] best_package() and direct_deps() functions
Product:	[Fedora] Fedora	Reporter:	Daniel Mach <dmach>
Component:	hawkey	Assignee:	Packaging Maintenance Team <packaging-team-maint>
Status:	CLOSED DEFERRED	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	rawhide	CC:	jsilhan, jzeleny, mls, packaging-team-maint
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-07-22 11:14:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1022940, 1080837

Description Daniel Mach 2013-06-28 09:53:37 UTC

As a release engineer, I'm interested in rewriting pungi[1] (Fedora compose tool) to use hawkey instead of yum internals.

The problem is that my use case is slightly different than installation,
because composes can contain conflicting packages or even broken deps (during development cycle, when we produce nightly composes). We also use various algorithms to pull langpacks or multilib packages in, pungi can run in greedy (pulling in all possible packages satisfying each particular dependency) or nogreedy mode.

That's why I need to use a more low-level approach than goal.install() && goal.run().


1) best package
I'm looking for an alternative to yum's _bestPackageFromList([package_objects]).

Example:
$ repoquery postfix
postfix-2:2.10.0-2.fc19.x86_64
postfix-2:2.10.0-2.fc19.i686
postfix-2:2.10.1-1.fc19.x86_64
postfix-2:2.10.1-1.fc19.i686

get_best_package([postfix_pkgs]) -> postfix-2:2.10.1-1.fc19.x86_64
(latest, native arch)

The original _bestPackageFromList considered also number of installed deps, package name length and couple more metrics. I'm not sure if I really need anything from these now, especially if I get the direct_deps() function.

If you're reluctant implementing this function, I could probably write something on my own...


2) direct deps
I can list package's requires and find all packages with matching provides to get direct deps. But the list is actual superset of what I really need, because some requirements can be provided by multiple packages.
I'm interested in getting a *minimal* list of direct deps.
It should consider already installed packages as priority deps (to keep package set minimal).

Example #1:
a package Requires: MTA

$ repoquery --whatprovides MTA
postfix-2:2.10.1-1.fc19.x86_64
exim-0:4.80.1-3.fc19.x86_64
sendmail-0:8.14.7-1.fc19.x86_64
postfix-2:2.10.0-2.fc19.x86_64

direct_deps(pkg) -> [postfix-2:2.10.1-1.fc19.x86_64]

Example #2:
a package Requires: MTA
sendmail is already installed (or included in the Goal already)

$ repoquery --whatprovides MTA
postfix-2:2.10.1-1.fc19.x86_64
exim-0:4.80.1-3.fc19.x86_64
sendmail-0:8.14.7-1.fc19.x86_64
postfix-2:2.10.0-2.fc19.x86_64

direct_deps(pkg) -> [sendmail-0:8.14.7-1.fc19.x86_64]



[1] https://git.fedorahosted.org/cgit/pungi.git/

Comment 1 Ales Kozumplik 2013-07-01 06:53:09 UTC

(In reply to Daniel Mach from comment #0)
> 2) direct deps
> I can list package's requires and find all packages with matching provides
> to get direct deps. But the list is actual superset of what I really need,
> because some requirements can be provided by multiple packages.
> I'm interested in getting a *minimal* list of direct deps.
> It should consider already installed packages as priority deps (to keep
> package set minimal).

The key here, or why just adding a package to a transaction and resolving won't help you, is that you only want the first level of dependencies, not the dependencies of dependencies etc.

Michael, can libsolv do something for us here?

Comment 2 Ales Kozumplik 2013-07-01 06:56:46 UTC

(low prio at this point, possibly involved resolution and only limited demand for the feature)

Comment 3 Daniel Mach 2013-08-23 12:40:00 UTC

Any update on this?
It's a blocker for release engineering; we cannot stop using yum in our tools without having these features available in hawkey.

Comment 4 Ales Kozumplik 2013-08-23 13:36:32 UTC

Hi Dan, when progress is made on this I'll make sure to update the bugzilla. Unfortunately it's not even on the roadmap now.

Comment 5 Ales Kozumplik 2014-02-06 12:37:17 UTC

talking with MLS about this here: to filter all provides down to the best suiting packages we want to look at policy_filter_unwanted().

Comment 6 Ales Kozumplik 2014-02-06 12:41:43 UTC

For the direct deps functionality, MLS suggests looking in detail at what Pungi really needs/does. We probably do not want to use the usual depsolving process here---the special handling will needed to be in hawkey.

Comment 7 Honza Silhan 2015-07-22 11:14:08 UTC

We don't have use case for `best_package` in DNF and it's already in Pungi. If anyone wants this in DNF, feel free to reopen and we will reconsider moving it to DNF.

Comment 8 Michael Schröder 2016-05-30 13:09:41 UTC

(clearing needinfo)