This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 644393 - RFE: Don't return error if --disablerepo doesn't exist
RFE: Don't return error if --disablerepo doesn't exist
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: yum (Show other bugs)
5.5
All Linux
low Severity medium
: rc
: ---
Assigned To: James Antill
BaseOS QE Security Team
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-19 11:27 EDT by Alexander Todorov
Modified: 2014-01-21 01:19 EST (History)
0 users

See Also:
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:


Attachments (Terms of Use)

  None (edit)
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.

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