yum download order according to size

I used to like F10 for its ordered download in accordance with size. It used to suite me on my slower net connection at home and strong connection at work place.

Today I wrote a small plugin today called yum-download-order with ( an evil hack, for which I have reasons) because order by size has been removed for long. It downloads packages in accordance with size (smallest first) or largest first.

I have put in fedora review request at:
https://bugzilla.redhat.com/show_bug.cgi?id=507410

http://rakesh.fedorapeople.org/yum/yum-download-order-0.1.tar.gz

http://rakesh.fedorapeople.org/srpm/yum-download-order-0.1-1.fc11.src.rpm

http://rakesh.fedorapeople.org/misc/yum-download-order-0.1-1.fc11.noarch.rpm

From README file:

Usage
======

Configure
=========

File: /etc/yum/pluginconf.d/download-order.conf

Options: for downloadorder can be ‘default’, ‘smallestfirst’,
‘largestfirst’ and by default ‘smallestfirst’ is selected.

e.g
[main]
enabled=1
downloadorder=smallestfirst

Options with yum command
========================

Yum command options will override configure file options.

e.g yum –download-order=largestfirst install or
yum –download-order=smallestfirst install

I was planning to put in a download-by-deps ordering also, but first though about looking for use cases. So, in case you find it useful — i.e download by size or by deps .. please mention the use case here ?

Thanks,

Advertisements

11 thoughts on “yum download order according to size

  1. My opinion the best way to sort packages is by size. For most peoples who run yum from console the main question is – how many time left before yum download procedure is finished.

    One way to do that show ETA. But here is some problems: for most connections hard to approximate ETA with different size of packet. That happens because small packet can take same time as medium size packets (1-5 mb), and most of time is spend for establish connection.

    In this case most intuitive way to show ETA by sorting package by size (from small to big)

  2. Yeah agreed .. and this plugin gives the choice .. and is not a core change and is completely optional.

    http://lists.baseurl.org/pipermail/yum-devel/2009-June/005661.html

    Seth doesn’t seem to agree … anyway it is just a plugin … everyone seems to be more concious about more number of packages download completes quickly on a small internet connection, rather then waiting for one big file to take all the time .. at start only.

    I am looking for fore use cases for size as well as group of releated packages (download-by-deps)

    Thanks

  3. IMHO, smallest first is completely evil and misleading and I’m glad it got dropped. It always makes you think, “great, 100/130 packages are downloaded, we’re almost done” when actually only 5% of the download is complete. That’s really frustrating.

  4. yeah, right .. but it also has the same component of “think” .. while you think this way I have seen folks .. think other way round .. on a slow net at home download as many small packages as possible earlier and big packages later .. moreover I am planning to extend it to … download-by-deps .. so in a big tree of packages .. depth first download should occur .. beside these changes are not in core …. so acceptance of upstream does not really matter … if one wants he can simply install plugin … 🙂

  5. Hi!, Congratulations for this excelente idea.

    I use Fedora 11, and have problem with you plugin.

    Yum give me the follow message:
    Plugin “download-order” can’t be imported.

    Can you help me?

  6. Do you have an update for fc14? Both yum-download-order-0.1-3.fc11.noarch.rpm and yum-plugin-download-order-0.2-1.fc11.noarch.rpm are having installation problems because they require python2.6, whereas fc14 has python2.7. Or, does the latest yum have download order option built into it? Thanks.

    –vv

    • This package is dead now. It was not based on hooks and was a hack which used to overwrite an internal function inside yum. Right now yum does not provide a sane way of doing it. In F14 when it was rawhide me and Seth decided it was best to discontinue it because it was breaking other plugins as well. It would have taken lots of effort to make this work again and was not worth it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s