On Wed, 2008-02-13 at 13:57 +0100, Florian Festi wrote: > Ooops, I still owe Seth an answer here... > > seth vidal wrote: > > On Tue, 2008-02-12 at 14:32 +0100, Florian Festi wrote: > >> BTW: I am still unhappy with the result of .update() and friends. It is > >> still quite complicated the find out what they actually did. Reason for > >> this > >> is the IMHO insane API of TransactionInfo that returns just arbitrary > >> transaction member objects in its .add* methods. > > > > Why is returning the txmbrs insane? update/install/remove all return the > > list of items that they added to the transaction set. The members > > themselves provide the why and the what. > > Returning the txmbr is not insane. Insane is that it is not granted that the > txmbrs returned really got added. > > TransactionInfo.addUpdate (for example) creates a TransactionMember object, > passes it to .add() and then returns it. But .add() might just ignore the > txmbr if there already is one with the same pkg and state. As a result the > caller of .addUpdate() (YumBase.update() in this case) ends up with a list > of txmbrs that are not only not newly added but also not even in the > transaction(info). > > This makes it quite difficult to find out what was actually done within the > .update() method and if the problems got resolved.
Okay, this is a reasonable critique and _should_ be fixable w/o too much pain. We just need add() to return a value/raise an exception if it just ignored the txmbr so the caller can know that the action didn't _do_ anything. -sv _______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
