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

Dan Mashal dan.mashal at
Tue Apr 10 05:05:12 UTC 2012

1) Yum should be intelligent enough to recognize this

2) yum-plugin-fastestmirror solves this problem.

3) I think we all upgraded from 14.4k modems a few years ago.


On Mon, Apr 9, 2012 at 8:35 PM, John Reiser <jreiser at> 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:
>  1. It's a poor idea to be running almost anything else on the box
>     at the same time as a distro version upgrade.  It is quite likely
>     that an app will encounter difficulties because of mismatched versions
>     of the components on which it relies.  [For instance, I've run across
>     situations where software-initiated reboot *hangs* after distro version
>     upgrade; I had to push the reset button.]  Thus single user mode should
>     be considered a requirement for distro version upgrade via yum+network,
>     although often it happens to work in multi-user mode if the box
>     is "otherwise idle".
>  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".
>     [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.)
>  3. If distro version upgrade via yum+network fails (power failure,
>     network failure, configuration failure, operator error, ...),
>     then you have a big mess.
>     The .rpm are not saved, so re-downloading might be substantial.
>     If an expert is not available for hands-on analysis and repair,
>     then a fresh install might be the best choice to achieve
>     shortest down time.
> Thus effective downtime can be reduced substantially if preupgrade
> manages to parallelize the collection of the anticipated .rpms
> (download .drpm and .rpm, reconstitute .rpm from .drpm)
> with normal multi-user operation of the machine under the old
> distro version.
> --
> --
> test mailing list
> test at
> To unsubscribe:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the test mailing list