[Yum-devel] [PATCH/RFC] New processConflict implementation

Florian Festi ffesti at redhat.com
Mon Nov 5 13:36:11 UTC 2007


Tim Lauridsen wrote:
> What if some one want to use the desolve class directly, it will fail 
> because there is no update method, there need to be some virtual method 
> raising NotImplemted or something like that.

We need to move that method to the Depsolve class anyway because we (ehm... 
I) introduced that dependency already with patch 
141377905b5851f937e8f76b0255ebac67b76ff7. Raising NotImplemented is the 
wrong answer here, IMHO. We should just move the code to the right place.

Btw: There's probably more code that could be move around between the 
different classes of the yum hierarchy (mainly Depsolve, YumBase, 
YumBaseCli). I think the depsolver should rely more on code from (now) 
YumBase (install, update, remove, bestPackagesFromList, ...)(I already 
started that and this patch is another step in that direction). Same is true 
for YumBaseCli which should also call code currently found in YumBase (from 
installPkgs, updatePkgs, erasePkgs, localInstall, ...). This could lead to a 
more compact code base which should be easier to maintain and to keep 
consistent.

To make that happen the current YumBase methods need to be move to Depsolve 
and to be fortified to work in a bigger number of scenarios. They have to 
get along with an already filled transaction set. This could also simplify 
the current depsolving methods as they could just "try to update to that 
version" and if that fails "try install that pkg" and then fail - without 
checking for any possible situation in advance.

In the long run it would be nice if that class hierarchy would also offer 
levels of abstraction that would - for example - not require YumBaseCli to 
fiddle with transaction members.

Florian



More information about the Yum-devel mailing list