Description of problem: Currently, if yum cannot completely download a metadata file, it'll start downloading the file from scratch from another mirror. (Or if it terminates, it'll start downloading from scratch in the next run). This is really problematic for slow or bad internet connections. Sometimes, the connection times out regularly when yum is downloading a database file, and it starts downloading from scratch each time. It is really frustrating (specially in PackageKit, where you don't see any progress and you wonder why it do not finish downloading repository data). Sometimes I'm forced to download those files by another tool and put it in yum cache directory manually. This is a small feature, but it improves user experience considerably (for users with bad internet connection).
Are you using the new test version of urlgrabber? As I'm sure the old version would resume for metadata files (when it could).
No, I'm using Fedora 11 urlgrabber: python-urlgrabber-3.0.0-15.fc11.noarch.rpm As far as I remember, it have not resumed for me even once (even in previous Fedora versions). It only works for packages themselves.
I'm not sure that this bug was present always (in Fedora 11 and previous versions). Please fix this really annoying bug :(
it's not really a bug - we don't reget the repodata b/c, by default, the repodata isn't uniquely named. We could enable it for fedora b/c our repos are using uniquely named repodata, but other repos do not. it's a bit of a connundrum.
So why createrepo does not generate uniquely named repodata files?! It can do it whenever it is creating a repository over an existing repository and/or updating a repository. The repodata file names can be as simple as including a sequential version number, or adding the file creating date to the file name or something like current fedora repository files (seem to be hash of something, probably the file itself?!). This feature is needed for any repository, so I think yum/createrepo should use it by default everywhere. Providing a version assignment system for repodata files are (I think) also required for the (hopefully coming) delta meta-data support.
Well, resuming the download of repository metadata could be enabled in the configuration file of a repository for repositories with unique repodata file names. It is easy and also it'll not be problematic for repositories without uniquely named repodata.
If we make --unique-md-filenames a default in createrepo then I think this is reasonable. And it might be reasonable now since fedora does unique-md-filenames now.
a patch to enable regets for metadata downloads has been submitted upstream.
Hi - I hope I'm not in the wrong place, but I was wondering if this fix has been implemented yet, and if so, how I can activate it. My office LAN is woefully under-funded, and I can't get more than a few 100kb downloaded before losing the connection. This has essentially crippled yum during office hours. Package downloads work fine, because they resume from where they broke, but the metadata is killing me (and requiring hundreds of expensive MB where only a few should really be required). Thanks
It has, although the latest fix of it requires size data on the MD. If you install pycurl from F11, you can probably install the yum from rawhide. Or download the yum from F12/updates.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
It's fixed for F-13 and F-12 (IIRC). Backporting to F-11 is really unlikely at this point.