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/
(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?
(low prio at this point, possibly involved resolution and only limited demand for the feature)
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.
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.
talking with MLS about this here: to filter all provides down to the best suiting packages we want to look at policy_filter_unwanted().
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.
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.
(clearing needinfo)