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

Jaroslav Mracek jmracek at redhat.com
Fri Dec 1 08:52:49 UTC 2017


> 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 <ngompa13 at gmail.com> wrote:

> 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!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-ecosystem/attachments/20171201/322d4b68/attachment.html>


More information about the Rpm-ecosystem mailing list