[Rpm-maint] The Future of Yum

[Ales Kozumplik]

Hello,

Over the last couple of months the Packaging Team has been busy 
discussing where we can focus our development over the next year or 
three to provide the most progress.

Yum currently includes a lot of features one would want from such 
software on both an enterprise machine or a desktop (updates, downloads, 
groups, repository management), and there are multiple clients using 
it's API including a few graphical ones. However these all tend to be 
separate projects, and there are problems with adding more API users.

So while we will still be looking to add features, integration and "API 
accessibility" will be a focus. As a first step on that path we are 
going to be integrating the #rpm and #yum IRC channels to #yum+rpm and 
the developer mailing lists (they are both fairly low traffic, and the 
majority of developers are on all channels and lists already).

Our next immediate goal is to build a library for metadata handling and 
dependency resolving, which can be used by both rpm and yum. In search 
of something to jump start our effort with (so as not to reinvent the 
wheel) we looked at libsolv[1], a library created and actively developed 
at SUSE, designed to address the need of efficiently representing and 
working with package metadata as not to take too much time or memory 
during computations over large amounts of packages. SUSE uses this 
library with a lot of success in the lower part of their package 
management stack. We also experimented with libzypp, the layer SUSE 
employs directly above libsolv, a heavy-weight library providing all 
sorts of packaging functionality. We decided against adopting it, mainly 
because it's implemented in C++, but there are also signals SUSE might 
be moving away from it[2].

Because libsolv's abstractions are below the level of what a client 
application (like rpm or yum) would like to deal with, we will have to 
build a suitable higher level API around it, something I have actually 
started working on, calling the new interface Hawkey [2].

Following the success of that we are looking at other pieces of yum we 
can move out to C libraries with defined APIs for each of the subsystems 
(the main ones under consideration: metadata handling and querying, 
repository management, download manager). These would replace and unify 
what is currently implemented in yum and would be directly usable by 
other client applications.

In summary, in the future yum itself will gradually be more of a client 
application that sits on top of C libraries below it, with the new 
libsolv API forming the first piece of the puzzle there. Hopefully at 
least by late 2012 we'd like to have an installable package out for 
people to try and test the new yum and the new API library itself. If 
you are interested in joining this effort with ideas, or better yet 
patches, there's no better time than now. We'll be pleased to hear 
from you.			


Ales Kozumplik

[1] http://en.opensuse.org/openSUSE:Libzypp_satsolver
[2] http://lists.opensuse.org/zypp-devel/2011-08/msg00018.html
[3] https://github.com/akozumpl/libsolv-api/tree/hawkey