[Rpm-ecosystem] libhif, and grand plans

[Neal Gompa]

On Mon, Jun 29, 2015 at 11:30 AM, Richard Hughes <hughsient at gmail.com>
wrote:

> Hi all,
>
> I've moved the libhif repo from my personal github space to
> rpm-software-management. What I'm going to propose I do then is:
>
> * Merge the hawkey subtree[1] to ./hawkey
> * Merge the librepo subtree to ./librepo
> * Add the extra Makefile.am for the librepo and hawkey projects
> * Install the old non-introspection files as before
> * Stop installing the librepo and hawkey .h files unless
> --enable-deprecated is used
> * Stop installing the librepo and hawkey shared libraries unless
> --enable-deprecated is used
> * Build libhawkey and librepo into libhif.so
> * Kill the configure checks for librepo and hawkey in configure.ac
> * Obsolete and provide the old librepo and hawkey packages in the
> libhif.spec
>
>
​​Why in the world are you merging hawkey and librepo into libhif? We use
them separately and others will want to use them separately. The fact you
have configure checks for them further indicates that it makes little sense
to obsolete the separate existence of these libraries. ​​



> Some comments:
> * I don't want to maintain everything! I think it's right the
> respective maintainers have control over the two different
> directories.
> * We can keep the cmake stuff that make sense in the two other
> projects if you're more comfortable using those; libhif is really just
> linking together some objects and building a tarball.
>

​Why not use CMake on libhif instead of making the other two use autotools?
Honestly, I find using autotools to be very annoying, and CMake is
generally easier for integrating into other projects, in my view​



> * We can nuke --enable-deprecated when we are sure atomic/service side
> depsolving has enough API in libhif.h to make it work.
> * when we nuke the compat switch, we can start changing API in librepo
> and hawkey, for instance using GList throughout and making the shared
> constants have the same #define name.
> * I don't think the code style being 100% the same is a huge problem,
> and changing it kills git blame.
>
>
​I'm not sure what to say on this, as I haven't really examined the code of
the libraries yet. But I'm uncomfortable with the idea of treating these
libraries as a singular unit, especially since they weren't designed that
way to begin with.​



> So comments welcome. If I don't hear anything by the end of the week
> I'll assume everything is fine and start merging trees! Feel free to
> nak with comments if you think I'm treading on toes.
>
> Richard
>
>
>
​Comments given. ;)​




-- 
真実はいつも一つ！/ Always, there's only one truth!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-ecosystem/attachments/20150629/476c196b/attachment.html>