seth vidal wrote:
Ditto wrto smartpm.
/me looks at the smartpm code.
it doesn't seem like it's using the rpm depsolver overly much. It's using it for the transaction - but it's solving the deps all by itself.
Yep. smartpm has a different, and more elegant, dependency graph and a better depsolver.
Nodes in a smartpm dependency graph are packages+operation, not just package.
That permits relations (in the topological sort sense) to be explicitly written between
identically named nodes, unlike what rpmlib currently does, which is handle
install/upgrade/erase operations as a function on the dependency graph.
So in a very real sense, smartpm has a better depsolver than rpmlib already.
One noticeable deficiency in rpmlib is that erased packages are not topologically
sorted, basically because I could not figure how to code the function that
traversed the dependency graph with "package" nodes.
The solution to ordering erasures and upgrades is obvious (to me anyways) when the nodes are labeled with "package+operation", and so can be ordered more reliably and more correctly.
But yes, I can and will teach rpmlib the same trick. Coding with nodes and edges ain't hard at all, what takes thought is the concepts, which smartpm (and Gustavo) does better than rpmlib atm.
rpmlib (and everything that uses) is quite stupid about choosing between
multiple provides, for one obvious example. Multilib, and kernel's, are
other known deficiencies in rp[mlib mechanism (or, if you will, the
lack of better policy mechanisms for depsolvers).
yep - which is why I'm looking forward to using the new check objects
that paul was talking about - to better identify the requiring package.
"check objects" is a mystery to me, just as much of a mystery as rhel-abe was this morning.
73 de Jeff
-sv
