Bug 796157 - yum repository retrieval can't be canceled
Summary: yum repository retrieval can't be canceled
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-22 12:03 UTC by Kamil Páral
Modified: 2012-03-02 14:56 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-02 14:56:59 UTC
Type: ---


Attachments (Terms of Use)

Description Kamil Páral 2012-02-22 12:03:09 UTC
Description of problem:
When retrieving yum repository information about F17 main/updates/updates-testing repositories, there is a progress bar in the middle of the screen that can't be canceled. If some repository is extremely slow to respond, you have no other way than to wait. Yesterday I had to wait 30 minutes to load a SINGLE repository information. It was a frustrating experience.

Users might be afraid that if they hard reset their computer to cancel this infinite waiting, their data might get corrupted (after all, their partitions are already mounted).

Anaconda or yum should be intelligent enough to switch to a faster repository if the current one is too slow. Or use a yum-plugin-fastestmirror.

Also, anaconda should offer user *at least* a possibility to cancel current process. An option to try out a different repository would be even better.

Version-Release number of selected component (if applicable):
anaconda 17.9

How reproducible:
hard

Steps to Reproduce:
1. you have to be lucky and yum has to pick a repository that is extremely slow but not dead, or you have to set up this kind of repository yourself

Actual results:
you might get stuck almost forever

Expected results:
you should be able to get unstuck, even if it means to cancel everything

Comment 1 Chris Lumens 2012-03-02 14:56:59 UTC
Our packaging code is not at all designed to work in this way, and adding it is very non-trivial.  Given the relatively infrequent nature of this problem, I can't see us getting to it.


Note You need to log in before you can comment on or make changes to this bug.