[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