Tim Lauridsen wrote:
Florian Festi wrote:
* Your patch fails to make sure that the problematic packages are not
readded by dependencies. If that happens you run into an endless loop.
The right solution would be an excluded_pkgs set that is ignored for
all depsolving operations. If pkgs are removed from the transaction
they get put into that set. This way we can never get back to the same
situation and can not run into an endless loop.
Added some code to clean out the added deps to a package with problems
Hmm, while this is a good idea it does not fix the cases I had in mind. I
tried to come up with an test case but we need some fixes to make that work.
I'll have to talk to James Bowes to get that fixed up as be both have the
half of the solution in our repositories
* As your patch works on the packages that have problems and not on
the packages that cause the problems there might be interesting side
effects.
Yes, this is the problem with trying to solve depsolve problem
foo-2.0 can't update foo-1.0, because bar require foo = 1.0.
So bar is causing the issue, foo-2.0, but i would not be sane to remove
bar. So we used remove foo-2.0 from the transaction, to get on with
other stuff.
As the .process*() methods know the situations quite good it might be an
idea to do different things depending on what the actual problem is in there.
* Like readding a package (by removing the erase txmbr) that has been
updated - resulting in the old and the new packages beeing installed
(welcome to the world of multilib file conflicts!)
I am not sure i understand this, please give some example.
If there is an update and removing the older pkg produces a problem you are
removing the transaction member that removes that packages. This means you
are adding that package again. If I understood the code right the new
package is not removed so you end up with the old and the updating package
installed.
Btw: you don't need to check for inclusion before adding to a set. You can
just call .add()
Florian
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
