Bug 140143 - yum ignores enabled=0 when mirrorlist is specified
yum ignores enabled=0 when mirrorlist is specified
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
: 141039 143816 149448 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-11-19 23:53 EST by Albert Strasheim
Modified: 2014-01-21 17:50 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-19 02:18:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Albert Strasheim 2004-11-19 23:53:58 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3)
Gecko/20041026 Firefox/1.0RC1

Description of problem:
yum seems to still try to access a mirrorlist even when enabled=0 is
specified in a .repo file.

However, changing the mirrorlist to an invalid URL when enabled=0
causes the .repo file to be ignored.

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

How reproducible:

Steps to Reproduce:
1. enabled=0 in repo file
2. Specify a mirrorlist
3. yum update

Actual Results:  yum tries to load the mirrorlist

Expected Results:  yum should not load a mirrorlist specified in a
disabled repo file

Additional info:

Workaround: comment out the mirrorlist line in .repo files you really
want to disable.
Comment 1 Seth Vidal 2004-11-30 00:48:42 EST
*** Bug 141039 has been marked as a duplicate of this bug. ***
Comment 2 Seth Vidal 2004-11-30 00:55:13 EST
So the reason it does this is b/c it has to check out the validity of
the repo. If a repo is not enabled but is invalid(ie: doesn't have any
urls of any type to use as the repo) then it won't be included in the
repo list at all (enabled or disabled).

Think about this for a gui. someone runs a gui, with repo: foo disabled.

they decide they want to turn it on. It would be bad to find out,
then, that the repo is screwed up. Don't give them the option unless
it's going to do _something_.
Comment 3 Albert Strasheim 2004-11-30 10:06:32 EST
I'm not quite sure I follow your argument above. Are you saying that
accessing the mirrorlist is required even for disabled repos in order
to determine whether the repos are valid? Or did I get it wrong?

In my opinion, yum should work something like this:

If repo is disabled, ignore it.

If repo is enabled, get a list of URLs from baseurl. Try the baseurl
URLs according to failovermethod. If one succeeds, we're done. If they
all fail, go on to the mirrorlist.

Try to fetch the mirrorlist. If this fails, print a warning. If it
succeeds, try the mirrors in roundrobin order until you find one that

If all the baseurl URLs and the mirrorlist or all the mirrors failed,
you can now retry the entire operation according to the retries
option. If all the retries fail, we can terminate the operation or
move on to the next repo (depending perhaps on some an option called
something like reporequired).
Comment 4 Peter Smith 2004-12-01 18:04:24 EST
Seth, I also don't seem to follow your argument above.  It seems to me
that if you "disable" a repository, it should "disable" it.  You are
saying that we need, instead, a "ignore" boolean flag on top of "enabled"?
Comment 5 Seth Vidal 2005-01-04 11:01:42 EST
*** Bug 143816 has been marked as a duplicate of this bug. ***
Comment 6 Seth Vidal 2005-01-19 02:18:29 EST
Okay, fine - be that way :)

repositories that are disabled don't get their mirrorlists looked at anymore. It
happens explicitly on repositories being enabled, though.
I can't and won't change that.
so this bug is fixed in cvs. when yum 2.1.13 comes out - you'll have this resolved.

you'll have other bugs, I'm sure, but this one will be resolved :)
Comment 7 Seth Vidal 2005-02-22 22:28:02 EST
fixed in 2.1.13 and 2.2.0 closed.
Comment 8 Seth Vidal 2005-02-22 22:28:37 EST
*** Bug 149448 has been marked as a duplicate of this bug. ***

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