redhat abe

[Jeff Johnson]

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
>
>
>  
>