[Rpm-ecosystem] libhif, and grand plans

[Daniel Mach]

Dne 29.6.2015 v 17:30 hughsient at gmail.com (Richard Hughes) napsal(a):
> 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.
> * 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.
> * 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.
>
> 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
>
> [1] https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging
>

Hi,
first of all, this could be a good change if it's done properly and 
carefully. I like these libs being separated (and well scoped). If 
libhif becomes a framework that integrates all these in a better way, 
then +1 from me. If libhif should merge everything into a big blob 
without clearly scoped interfaces, then we're in disagreement.


I can imagine something like this:
libhif -- integration, basically DNF internals rewritten to C
   +- librepo -- retrieving repodata; possibly also parsing repodata
   +- libsolv -- depsolving (drop repodata parsing from libsolv)
   +- libhawkey -- queries
   +- libcomps -- package groups
   +- libunfo -- errata information (updateinfo.xml)
      https://github.com/midnightercz/libunfo; pototype; not used now


Libs should remain usable with non-RPM ecosystem, for example with 
debian packages and repodata; these may eventually get merged with 
libhiff as standalone libs or plugins.



As a release engineer and Pungi developer, I'll need following use cases 
preserved:
Pungi:
* read comps from repodata -> groups, langpacks
* read repodata -> sack
* make queries on sack -> closure on deps
   (regular depsolving doesn't work for creating composes)

Rel-eng tools:
* query repodata
* manipulate with comps
* manipulate with updateinfo
* add/remove individual package to/from repodata,
   keep the rest untouched
   - rather don't ask why :)
* manipulate with RPM header and payload (possibly out of scope)
* read data from RPM header
* manipulate with NVRs
   - such code lives in many places:
     - RHN/Satellite/Spacewalk
     - koji
     - https://git.fedorahosted.org/cgit/kobo.git/tree/kobo/rpmlib.py
     - and many other
   - ideal place for this code is RPM, DNF or libhif
* manipulate with changelog entries (both repodata and RPM header)
* verify RPM with a GPG key
* maybe some more...


All these should be available via Python interfaces.


- daniel


-- 
Daniel Mach <dmach at redhat.com>
Release Engineering, Red Hat