[Rpm-ecosystem] libhif, and grand plans

[Radek Holy]

----- Original Message -----
> From: "Richard Hughes" <hughsient at gmail.com>
> To: rpm-ecosystem at lists.rpm.org
> Sent: Tuesday, June 30, 2015 10:33:30 AM
> Subject: Re: [Rpm-ecosystem] libhif, and grand plans
> 
> On 30 June 2015 at 04:52, Neal Gompa <ngompa13 at gmail.com> wrote:
> > Sorry, I didn't mean to write "we", but I am looking to use hawkey for
> > something without librepo, as it's not for rpm-md repos. That said, the
> > point is that I don't see a strong case to remove the modularity that was
> > just introduced.
> 
> I see an exceptionally strong case: things keep breaking. We've had 3
> instances in the last 18 months where Fedora updates stop working
> because either librepo or hawkey changed behaviour in a subtle way
> which broke assumptions in the stack above. That's 3 times we've had
> to ask people to run a specific low-level command to fix their system
> as we couldn't ship an automated update to fix the broken update.

Yes, and you always showed your anger so visibly that we are really careful not to repeat these mistakes again.

> Also, because librepo, hawkey and libhif release at different times we
> have to test all combinations of old and new, upgrading a first, then
> b, and also a+b at the same time, sometimes jumping two minor
> versions. The QA matrix is simply crazy for three small essential
> libraries that do actually very little.

This can be solved by backwards compatibility commitment. I guess you are not going to merge the rest of the dependencies because of the same reason.

> The other reason is clarity. What do we tell people when they ask "how
> do I download a package in C"? What about Python? What about
> Javascript? With a simple GObjectIntrospection interface we can tell
> people one way to do something rather than the long convoluted answer
> we currently have.
> 
> The fact that the library is larger than they might need is no issue;
> merging the libraries actually saves space as you don't need to do
> three sets of linker invocations, and you have a smaller surface for
> testing. I'm totally for exposing more API in libhif for people to
> use, even it's just a 1:1 wrapper for the depsolver underneath. I also
> don't buy the argument put forward by some people that the GObject dep
> is too large as it's basically impossible to build a system without
> glib these days.
> 
> What we do need to do is show the few people brave enough to be riding
> the wave how to port to libhif away from the lower libraries, which
> will mean writing some tutorials and sample code. The current stack
> isn't maintainable and isn't working. It's too complicated and has too
> many interconnected parts. Just looking at conversion functions like
> https://github.com/rpm-software-management/libhif/blob/master/libhif/hif-package.c#L648
> you can see what we have now is a mess and needs cleaning up.

After the merge, it becomes even more complicated...

> Richard.
-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech