On Thu, Aug 9, 2012 at 5:55 PM, Zdenek Pavlas <zpav...@redhat.com> wrote:
> > parallel download should have been disabled by default for API users > > and then could have be been turned on by yum-cli > > Yes, probably. But (apart from the custom progress callback bit) > this was a fully compatible change. > Yes, no smoke, just a lot of weird un-needed output in log, like in the BZ report :) > > > What way would be the best way to handle this in a GUI like yumex, > > that works from EPEL6 to F18, should it disable parallel download in > > some way ? > > It's per-repo switch, "repo._async = False" disables multi > downloading for that repo. To have both multi-file downloads > and custom progress, we'd need: > A method of switching this would be nice and maybe a one in repoStorage to set for all repos. repo._async = False It not nice, it like messing with the object internal private vars. > > a) setMultiProgressBar() API: That's fine, but You have to implement > 2 APIs. > > b) we could detect a custom progress CB (that's anything but None > or the Yum's default text object) and do a "compat" layer: > > Whenever a file is finished, just send .start(), .update() and .end() > events. This way downloads are serialized and we can pretend > they were sequential. No in-file progress, but better than > breaking the API user. > > 2 callback API's is no a big problem, as long as the old one works as in previous releases (except for not getting progress during single file download) Callback base classes for multifile download callback should be added to yum/callbacks.py for easier overloading. Tim
_______________________________________________ Yum-devel mailing list Yum-devel@lists.baseurl.org http://lists.baseurl.org/mailman/listinfo/yum-devel
