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 _______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
