On Mon, 2013-02-25 at 10:18 -0500, Zdenek Pavlas wrote: > > > - download of .drpm and .rpm files now may run in parallel. > > > > It's almost certainly worth sorting these so that drpms still > > download > > first, and then they can rebuild while the .rpms (and other .drpms) > > download. > > Good idea, this should always help. Also, with separate .drpm > code I may drop the .to_drpm() and .to_rpm() hacks- but that > would require re-implementing getPackage() and verifyLocal(), > I'm not sure it's worth it.
Well I was thinking more of creating some special "drpm" package objects which are used just for the download. They can easily contain a pointer to the real package object, and it seems like it'd be much easier to manage. I'm not 100% against the current to_drpm/to_rpm thing, it just feels like it'll hit weird issues. Worst case put the real data inside the package instead of the containing presto. object, so that anything further down the stack can look at the real data if it needs to. > --- a/yum/__init__.py > +++ b/yum/__init__.py > @@ -2182,7 +2182,9 @@ much more problems). > a = apo.getDiscNum() > b = bpo.getDiscNum() > if a is None and b is None: > - return cmp(apo, bpo) > + # deltas first to start rebuilding asap > + return cmp(bpo in presto.deltas, apo in presto.deltas) \ > + or cmp(apo.size, bpo.size) > if a is None: > return -1 > if b is None: > > I'm also tempted to sort files > from small to large ones. Small files try few mirrors, > large ones then use more accurate statistics. Meh. I'm not sure the stats. will work that way. Also note that I did this change a few years ago ... and while we didn't have parallel downloading there is a psychology aspect that most people go with their first impressions (so people assume downloads are faster if the first downloads are faster). But it didn't tend to work out that way, one big problem was that PK refused to do a useful progress (just showed % of downloaded packages) and so everyone complained that the PK progress bar was really bad ... but people also complained that the yum progress was too misleading. > > Can you add the specfile obsoletes to the patchset? > > Yes. There's no conflict, one may enable both... > But doing so does not make any sense. Yeh, in the past we've still obsoleted even when there's no conflict. _______________________________________________ Yum-devel mailing list Yum-devel@lists.baseurl.org http://lists.baseurl.org/mailman/listinfo/yum-devel
