[Rpm-ecosystem] libhif, and grand plans

[Neal Gompa]

On Tue, Jun 30, 2015 at 10:12 AM, Colin Walters <walters at verbum.org> wrote:

>  On Mon, Jun 29, 2015, at 11:52 PM, Neal Gompa 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.
>
>
> libsolv is obviously still separate.  Things get a little weird here
> because hawkey does have a better API in some cases, but it also has random
> bits like kernel detection which might not apply to your case.
>
>

​I don't currently need the kernel detection bits, but I do plan on
handling that in the future with my little project, so it would be nice to
have. The API in hawkey looked much easier to use than that of plain
libsolv, so I've been tinkering with using that.​


>
> That said, the point is that I don't see a strong case to remove the
> modularity that was *just* introduced. I've personally never seen a
> scenario where that wasn't regretted later.
>
>
> The proposed plan still far retains a lot of that modularity - each
> sub-library is focused on a task.  What libhif does is help tie together a
> lot of the common cases "download a set of rpm-md repos with librepo and do
> a depsolve".
>
> Going forward though, it's not entirely clear to me yet how much those C
> library interfaces will be retained as they are today versus tighter
> integration.
>
> What this list is for though is exactly the sort of feedback you're
> providing, so let's keep the discussion open!
>
>

​Personally, I would prefer to have very clear APIs from the libraries that
can be independently used. I​f they are merged into a single project, I
would like for CMake to generate the individual libraries and provide
headers and stuff along with libhif too.



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