Re: [Rpm-ecosystem] rpm-ostree's usage of libhif/hawkey merge

[Honza Šilhan]

> From: "Neal Gompa" 
> Honestly, at this point, I'm wondering why we don't just rename libhif
> to libdnf (or something else, but DNF would be the primary consumer).
> Now that the hawkey/hif merger is (mostly) complete and it's one
> library that was ultimately designed to be the foundations of both DNF
> and PackageKit frontends, I think it would make sense to call it
> libdnf from this point on. That would allow the hif backend to remain
> frozen at 0.2.0 and the new integrated code could be a new library.

I don't mind about renaming the library but I don't know if it would really
solve the problem. We bumped soname during the libhif/hawkey merge and the
stable API will be frozen in libhif-1.0.

> DNF would also eventually migrate from the hawkey python API to the
> libdnf gi based API in Python.

The hawkey API seems to be designed well, especially queries. We reuse generated
GI python bindings to reduce current Python bindings in C code. We would still
do a light layer to GI python bindings to stay compatible (and maybe still call
that layer python-hawkey)

> From: "Colin Walters" 
> 
> See for example:
> https://github.com/rpm-software-management/libhif/pull/62#issuecomment-147811600
>
> There's also:
> 
> https://github.com/rpm-software-management/libhif/pull/69

If you have found a better approach in handling multiple connections then the 
change
should be within librepo. DNF would like to take advantage of it too.

we can discuss PRs at the meetings. libhif should be the base for DNF, PK and 
rpm-ostree.
Most of the demands from these package managers should be implemented in the 
libhif.
If rpm-ostree has extra requirements then we will find a way how to expose 
additional API.
When librepo will be part of libhif we will hide the details too so WRT PR 62 I 
would
expose librepo handlers and result with some deprecation warning that it will 
be removed
in the libhif-1.0 or next soname version.

> I have a concrete suggestion: what if we made libhif suitable for use as a
> git submodule
> for now (install to e.g. $libdir/rpm-ostree/libhif.so) ?  That way I can
> iterate quickly
> on API changes without blocking for a long time.  If I can't actually make
> use of a change
> I've submitted for weeks it just dramatically impacts iteration time.  I'd
> obviously keep sending patches
> upstream.

I am rather against submoduling. Everyone would have it's own version and that's
actually against the goal of hawkey/librepo/libhif merge. We had similar story
up until now where we worked independently on code refactoring and autotools to 
cmake
transition. We ended up with huge rebase where cmake didn't work and had to be 
reworked
again.


Honza
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] rpm-ostree's usage of libhif/hawkey merge

[Colin Walters]

On Tue, Jan 26, 2016, at 11:27 AM, Neal Gompa wrote:

> That would break way too many things. 

What would break, exactly?  

> The problem with what your
> suggesting that it implies you are the only consumer of libhif. 

I guess I didn't spell out that I was also suggesting we still
support installing it as a shared library.  But maybe Richard
or Jan would want to change dnf/PackageKit to also use it
as a submodule, I don't know.

> On top
> of that, using libhif as a git submodule implies that you'd be editing
> the codebase directly.

Yes.  For a while.

> We can't really afford to have people do stuff like that.

Your use of the term "we" here seems odd given I have
commits in most of the git repos under discussion here, while you
have zero.
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] rpm-ostree's usage of libhif/hawkey merge

[Colin Walters]

On Tue, Jan 26, 2016, at 12:54 PM, Neal Gompa wrote:

> Well, if you keep altering all the interfaces, especially the public
> ones used by PackageKit and DNF, then there will be problems for
> developers and consumers of these programs. 

What I'm trying to say is that given we know we need to break
APIs for two reasons:

 1) To merge libhif/hawkey
 2) To expose more lower-level APIs for rpm-ostree

(At least those two)

There's going to be a lot of churn.  My offhand take here is
that both rpm-ostree and PackageKit should embed libhif,
and we collaborate on reviewing patches upstream, but
accept temporary levels of forking.

koschei should stick with hawkey-python for now.

dnf is the hard one, particularly given the desire to better
integrate PK and dnf (and the whole daemon vs not daemon thing).
Maybe they could try having a branch that uses a new libhif?
I think in practice it'd be better to have finalized some of the concepts
of the C API before we start trying to rebase dnf on libhif.

But I'm just making things up here.

> That's uncalled for there.
> 
> I have spent the last four months painstakingly working on integration
> of DNF into Mageia[1] and I've also been working for the last three
> months on integration of the stack for Unity Linux, and I have indeed
> committed code to DNF and its various plugins repositories.

Okay.  I had only seen you comment once or twice.  I felt your response
was not addressing my concerns - in fact you skipped over the fact
that I have multiple outstanding PRs to libhif that were linked in
the original message.

___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] rpm-ostree's usage of libhif/hawkey merge

[Neal Gompa]

On Tue, Jan 26, 2016 at 1:12 PM, Colin Walters  wrote:
>
>
> On Tue, Jan 26, 2016, at 12:54 PM, Neal Gompa wrote:
>
>> Well, if you keep altering all the interfaces, especially the public
>> ones used by PackageKit and DNF, then there will be problems for
>> developers and consumers of these programs.
>
> What I'm trying to say is that given we know we need to break
> APIs for two reasons:
>
>  1) To merge libhif/hawkey
>  2) To expose more lower-level APIs for rpm-ostree
>
> (At least those two)
>
> There's going to be a lot of churn.  My offhand take here is
> that both rpm-ostree and PackageKit should embed libhif,
> and we collaborate on reviewing patches upstream, but
> accept temporary levels of forking.
>
> koschei should stick with hawkey-python for now.

If we can consider that hawkey-python is essentially frozen API wise
(or at least pretty much remaining compatible), then it may work
temporarily for Koschei and DNF, as DNF currently consumes the hawkey
Python API, rather than the C API.

>
> dnf is the hard one, particularly given the desire to better
> integrate PK and dnf (and the whole daemon vs not daemon thing).
> Maybe they could try having a branch that uses a new libhif?
> I think in practice it'd be better to have finalized some of the concepts
> of the C API before we start trying to rebase dnf on libhif.
>
> But I'm just making things up here.
>

Honestly, at this point, I'm wondering why we don't just rename libhif
to libdnf (or something else, but DNF would be the primary consumer).
Now that the hawkey/hif merger is (mostly) complete and it's one
library that was ultimately designed to be the foundations of both DNF
and PackageKit frontends, I think it would make sense to call it
libdnf from this point on. That would allow the hif backend to remain
frozen at 0.2.0 and the new integrated code could be a new library.
DNF would also eventually migrate from the hawkey python API to the
libdnf gi based API in Python.

>> That's uncalled for there.
>>
>> I have spent the last four months painstakingly working on integration
>> of DNF into Mageia[1] and I've also been working for the last three
>> months on integration of the stack for Unity Linux, and I have indeed
>> committed code to DNF and its various plugins repositories.
>
> Okay.  I had only seen you comment once or twice.  I felt your response
> was not addressing my concerns - in fact you skipped over the fact
> that I have multiple outstanding PRs to libhif that were linked in
> the original message.

Perhaps there needs to be more aggressive work on the new code to
address your concerns. Do you talk to Richard much about this?


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem