[Rpm-ecosystem] libhif, and grand plans

[Jan Silhan]

> From: "Neal Gompa" <ngompa13 at gmail.com>
> 
> 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
> 
> Some comments:
> * I don't want to maintain everything! I think it's right the
> respective maintainers have control over the two different
> directories.

I share the same opinion. The changes across these projects will be discussed
via PRs.

> * 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​

I agree with Neal. If libhif just links librepo and hawkey, making CMakeLists
for libhif should not be a problem. Mixing autotools and cmake seems strange
to me.

> * 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 see we all use the same braces format for function definition and if-else
statements.  We don't mind changing the indentation. So far we are mixing
spaces and tabs (8 spaces width). We actually planed to switch to just 4 spaces.

Honza