> Are you planning to submit patches to PackageKit for any API breakage? > Or is the library interface as used by PK unchanged?
I would prefer to apply patches to PackageKit and so on, if you will agree? > 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. This is not going to change. The present discussion is not about solution selection, but about how to feed the solver > 2. urpmreorder solver flag behavior should still account for how > installations/upgrades function. This, I believe, is more or less > automatic. Yes, more less automatic, and the changes here should be only for good reason. > 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. > Documentation of stable API is of ours major goal. Have a nice day Jaroslav On Thu, Nov 30, 2017 at 9:45 PM, Neal Gompa <[email protected]> wrote: > 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
