[Yum-devel] Integrating drpm support

James Antill james at fedoraproject.org
Mon Feb 25 15:52:57 UTC 2013


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.



More information about the Yum-devel mailing list