[Rpm-maint] Anybody using rpm solve database / --aid?

Panu Matilainen pmatilai at redhat.com
Fri Sep 21 08:18:39 UTC 2007


On Fri, 21 Sep 2007, Ralf Corsepius wrote:

> On Fri, 2007-09-21 at 09:27 +0300, Panu Matilainen wrote:
>
>> My original mail also had this: "Distros seem to be doing fine without
>> shipping a solve database, but do people have local specialized uses for
>> it?" I haven't really get an answer to that (the real use-cases). For the
>> average use of installing and updating packages from a distro, --aid as
>> currently implemented is fundamentally broken as it doesn't integrate with
>> any of the update-mechanisms distros use, but instead relies on a separate
>> metadata source, and an expensive & cumbersome one at that.
> Can't rpm be changed (may-be as an optional (compile-time) feature
> underneath of --aid) to use yum/apt caches to dynamically generate this
> metadata?

Generating an entire rpmdb from limited information in outside metadata is 
not practical or feasible. s/generate/use/ in the above and it gets more 
interesting - if rpm could ask from yum/apt/whatever "which package in 
your known package universe provides X" --aid could provide up-to-date and 
useful information.

Hmm.. actually there might be something just around the corner to make 
this quite feasible: PackageKit knows how to talk to a number of backends 
(including yum and apt) and can be used as an uniform interface to 
retrieve information about packages. So instead of teaching rpm to talk to 
yum, apt, smart and whatnot, rpm (cli) could just be taught to talk to 
PackageKit. If that were possible (ignoring details such as whether 
PackageKit currently supports that, competing for rpmdb through PK backend 
access etc for the moment):
- the solvedb wouldn't be needed 
- rpm could provide useful suggestions
- --aid could provide actual (remote) package locations for getting the
   packages

This might well be something to look into, the solvedb is the ugly 
duckling here, not the --aid the feature.

>> Yum is not a measure for removing features from rpm, things like "does
>> this belong in the core package manager", "can something else do a better
>> job" are.
> This raises another question: Doesn't depsolving actually belong into
> rpm instead of yum?

It's an interesting question :) Obviously rpm needs to be able to verify 
that package requirements are met on installation/erase for integrity and 
verification purposes. But knowing where in the world to obtain, and 
possibly which of several equal choices to choose a package providing 
feature X that something requires is a different question entirely - rpm 
has no knowledge of the world outside (and that's the way it should be 
IMO)

The problem is that rpm only operates on actual rpm headers, and headers 
are a very expensive way to distribute metadata (they carry lots of data 
that's totally irrelevant for depsolving). Apt-rpm "native" repository 
format is just a headerlist where unneeded data is stripped out and some 
extra data inserted. Yum prior to 3.0 used to fetch the actual package 
headers, feed to rpm and based on the information given by rpm depsolve 
algorithm locate packages in it's known universe and feed more headers to 
it. That's pretty much the way things would optimally work, it's just that 
headers are impractical (and can't be easily constructed from information 
obtained from other sources)

Improving the interactions between rpm and depsolvers would certainly be a 
good thing.

 	- Panu -



More information about the Rpm-maint mailing list