seth vidal wrote:
On Wed, 2007-11-21 at 08:04 +0100, Tim Lauridsen wrote:
seth vidal wrote:
On Fri, 2007-11-16 at 21:36 -0500, James Bowes wrote:
On Thu, Nov 15, 2007 at 11:22:42AM +0100, Tim Lauridsen wrote:
I have created at patch to add skip-broken functionality to YumBase.
While I'm not against adding skip-broken to core yum, or other things
like downgrades and pinning (though others may disagree ;) ), I don't
know how comfortable I am adding features to the depsolver right now vs
hardening the existing behaviour and speeding it up.
not to mention that skip-broken internally equivalently makes our
progress bars go backward :(
-sv
Maybe its to early in the morning for me, but i don't have a clue what
you are talking about :) :)
Progress events for depsolving. It seems like if we're restarting the
depsolve process in that way we'll end up with reducing how much
progress we've made.
so we'll have a progress bar which goes:
=====================>
========================>
================>
======================>
=========================>
=================>
================>
or maybe I'm just thinking about it oddly.
-sv
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
I was not aware of any progress events for depsolving, i sounds a little
hard to do, because if we start with 1 package in the transaction
when we start the depsolving, but who know how many packages there will
be pulled in by the depsolver and need to be depsolved too.
If we don't know the amount of work to be done, how can we have a
progressbar ?.
The skip-broken code don't change that as far as i can see. we we remove
package from the transaction reduce the work to be done, so i there is a
progress it should not step backward because there is less work to do.
Tim
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
