On Thu, Nov 30, 2017 at 2:45 PM, Jaroslav Mracek <[email protected]> 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! _______________________________________________ Rpm-ecosystem mailing list [email protected] http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
