Proposal: stop holding composes for preupgrade bugs at Alpha and Beta phases

Horst H. von Brand vonbrand at inf.utfsm.cl
Tue Apr 10 14:03:21 UTC 2012


John Reiser <jreiser at bitwagon.com> wrote:
> On 04/09/2012 07:18 PM, Dan Mashal wrote:
> > As I said in the meeting let's just deprecate it [in favor of yum+network].
> 
> The problems I have seen with using only yum+network to perform a distro
> version upgrade are:

[...]

>   2. yum is stupidly slow about collecting the upgrade .rpms.
>      First there is downloading itself: yum downloading [of any kind]
>      is single threaded.  Often this wastes 30% to 50% of available
>      bandwidth (at the server and/or in the pipe.)
>      A close-to-optimal strategy for typical cable modem ISP is:
>           1. Sort the download list by size of file to be downloaded.
>           2. Run two parallel threads.  The first thread downloads
>              from large to small, the second from small to large.
>              Stop when the threads meet somewhere in the "middle".

I don't understand why this should be better than each thread just getting
the next available one.

>      [Debian has a two-thread download for "apt upgrade".  It does not
>      use the optimal strategy, but it is still effective.]
> 
>      Second, yum does not download the remaining .rpm (whose .drpm
>      are not available) while it is reconstituting the other .rpm
>      from .drpm.  The waste can be significant for the common case
>      when there are enough .drpm for some large .rpms (kernel,
>      libreoffice-*, etc.)

All this is purely a yum problem, fixing that would go a long way to making
regular updates smoother.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  +56 32 2797513


More information about the test mailing list