This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 644393

Summary: RFE: Don't return error if --disablerepo doesn't exist
Product: Red Hat Enterprise Linux 5 Reporter: Alexander Todorov <atodorov>
Component: yumAssignee: James Antill <james.antill>
Status: CLOSED NOTABUG QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: low    
Version: 5.5Keywords: FutureFeature
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-10-20 09:34:12 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Alexander Todorov 2010-10-19 11:27:53 EDT
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 11:28:43 EDT
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 11:44:13 EDT
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 11:50:02 EDT
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 04:07:25 EDT
(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.