[Rpm-ecosystem] LIBDNF - code reduction + important further changes

[Neal Gompa]

On Thu, Nov 30, 2017 at 2:45 PM, Jaroslav Mracek <jmracek at redhat.com> wrote:
> Dear colleagues,
>
> As you could notes we try to reduce the code of LIBDNF and I believe that so
> far without any breakage. The last huge code reduction
> (https://github.com/rpm-software-management/libdnf/pull/390) is planned to
> be merge soon if there will be no complains, but it is not going to be
> released before the end of this year.
>
> In future I also would like to reduce multiple paths for example for filling
> the goal, but this will require closer cooperation of developers and
> maintainers of PackageKit, rpm-ostree, and microdnf. At the present time we
> support for example for install paths using DnfPackage (hy_goal_install) or
> HySelector (hy_goal_install_selector). In future I would like to support
> only selector path, because it provides more flexibility. We also know that
> the second approach has a problem with SOLVER_WEAK flag. I will be very
> happy for cooperation and any feedback.
>

My main concerns boil down to two things:

1. install/builddep need to be able to install by provides and prefer
equivalent packages of the primary architecture, even when differently
named (this currently works with dnf 2.7.5 + libdnf 0.11.1 + libsolv
git master). For example lib64foo1.x86_64 = 2.0.0 and libfoo1.i686 =
2.0.0 both provide libfoo1 = 2.0.0. A "dnf install libfoo1" or "dnf
builddep libfoo1" should resolve correctly.

2. urpmreorder solver flag behavior should still account for how
installations/upgrades function. This, I believe, is more or less
automatic.

As long as these two are covered, I am fine with this.

What I hope to see is that libdnf actually provides a comprehensible
(and documented!) API for writing applications to interact with
package management.

-- 
真実はいつも一つ！/ Always, there's only one truth!