Bug 644393 - RFE: Don't return error if --disablerepo doesn't exist
Summary: RFE: Don't return error if --disablerepo doesn't exist
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum
Version: 5.5
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: James Antill
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-19 15:27 UTC by Alexander Todorov
Modified: 2014-01-21 06:19 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-10-20 13:34:12 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Alexander Todorov 2010-10-19 15:27:53 UTC
Description of problem:
Yum will return an error if a repository listed in the --disablerepo switch doesn't exist. For example:

yum update --disablerepo="no-exist"
Loaded plugins: rhnplugin, security


Error getting repository data for no-exist, repository not found


This is a RFE to allow yum to continue if the repository is not existing.


Version-Release number of selected component (if applicable):
yum-3.2.22-26.el5

How reproducible:
Always

Comment 1 Alexander Todorov 2010-10-19 15:28:43 UTC
The impact of this bug is that some automated test cases require special handling for RHEL5/6 where repo names are different.

Comment 2 James Antill 2010-10-19 15:44:13 UTC
We should probably fix this upstream, but I'm less sure about how important it is in RHEL-5 ... and there is a work around:

yum update --disablerepo="no-exist"  == fail
yum update --disablerepo="no-exist," == works

...due to the fact that we allow:

yum update --disablerepo="exists,no-exist"

Comment 3 seth vidal 2010-10-19 15:50:02 UTC
so I'm torn on this one:

on one side:
 - If we don't bail out and the user has just fat-fingered a repo name then they could get unanticipated results and cause any number of other problems

 - If we do bail out then the user just has to correct the command line for the right repo name and start again.


I am leaning on the side of caution and I'd rather bail out.

If the impact is that rhel5 and rhel6 require different testing then I'm inclined to say 'yes, that's true, they are different.'

Is there an impact to our users/customers?

Comment 4 Alexander Todorov 2010-10-20 08:07:25 UTC
(In reply to comment #3)

> Is there an impact to our users/customers?

Customers - likely not. For QE it makes live a bit easier but anyway we did a work around already.


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