[Yum-devel] Resolving dependencies for postresolve-plugin actions

[seth vidal]

On Mon, 2006-02-20 at 09:31 -0500, Paul Nasrat wrote:
> On Mon, 2006-02-20 at 03:13 -0800, Panu Matilainen wrote:
> > Just got reminded of something that has bothered me for a while now by
> > getting bitten by it: we should have a second run of resolveDeps() if 
> > postresolve-stage plugin changes the transaction set. Otherwise it can 
> > leave rpmdb in inconsistent state - for example installonlyn plugin 
> > decides to remove old kernels but any kernel-module packages depending on 
> > it are still left on the system. Ditto for any other changes in 
> > postresolve, not having postresolve actions depsolved limits its usability 
> > in various other ways as well.
> > 
> > Something like this would be needed (just checking for tsInfo size isn't 
> > really sufficient but you'll get the idea):
> 
> SortedTransactionData uses a changed state on add/remove which we could
> put in the parent class.
> 

I like this better, I think.

it seems nicer to know the state changed within the class.

-sv