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