Description of problem: == Background == Today I needed to have a look at F18 yum groups on a F17 system. So I executed: $ yum grouplist --releasever=18 But that failed horribly: > $ yum grouplist --releasever=18 > Loaded plugins: changelog, langpacks, presto, refresh-packagekit, remove-with-leaves, show-leaves > http://linux.dropbox.com/fedora/18/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found : http://linux.dropbox.com/fedora/18/repodata/repomd.xml > Trying other mirror. > http://linux.dropbox.com/fedora/18/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found : http://linux.dropbox.com/fedora/18/repodata/repomd.xml > Trying other mirror. > Error: failure: repodata/repomd.xml from Dropbox: [Errno 256] No more mirrors to try. The contents of dropbox.repo is this: $ cat /etc/yum.repos.d/dropbox.repo [Dropbox] name=Dropbox Repository baseurl=http://linux.dropbox.com/fedora/$releasever/ gpgkey=http://linux.dropbox.com/fedora/rpm-public-key.asc Guess what, they are sloppy and they don't include skip_if_unavailable=True in it. Playing with --releasever isn't common between general users, but if the dropbox repository is inaccessible for some reason, I would get the same error. Now, is that really their problem? == The Problem == Basic building blocks like yum have to struggle really hard to provide reasonable defaults, so that external developers are required to do as little work as possible and the system is made to be as little error-prone as possible. But defaulting to skip_if_unavailable=False is quite the opposite. It's very easy to forget it, if you don't read documentation properly. General users then complain that Fedora is broken, because they added such "broken" third-party repository and it's currently unavailable, taking down the whole yum functionality. == The Solution == We need to ensure that very important repositories are functional. Those basically are just the official Fedora repositories. And we have 100% control over them. We can easily add skip_if_unavailable=False line to all official .repo files and we are covered. Third-party repositories, on the other hand, should default to skipping errors, because it is not reasonable to fail if just a single third-party repository is down. If the user or the repository authors believe this third-party repository is absolutely vital, they can always add this line. And this is exactly the behavior we will receive if we default to skip_if_unavailable=True. In summary, defaulting to skip_if_unavailable=True improves current the experience for a lot of users, while bringing no obvious disadvantages. Version-Release number of selected component (if applicable): yum-3.4.3-29.fc17.noarch
I second this change. I am using a bunch of external repositories (adobe, rpmfusion, virtualbox) which are not always available so it seems. I am now manually adding the skip_if_unavailable to all of them, but having the default changed would be much easier.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Repo files generated by OpenSUSE Build Service [1], which is used _a lot_ for packaging various FLOSS programs, also does not include "skip_if_unavailable=True" line. Neither Google Chrome does. All those applications "break Fedora" if their master server is unavailable for just a while, or if they don't support the freshly released Fedora version.
[1] https://build.opensuse.org/
I understand why you think this is a good idea, there are often two classes of repo. where one is "I really need this" and the other is "meh. it's cool, if it works" and the repos. in the first category also tend to be the most available. But it's just not better to classify everything as broken by default. Defaulting to "I really need this": 1. is historically what all package managers have meant when you added a repo. 2. is the only thing all any documentation anywhere assumes. 3. is what people creating repos. expect. 4. is what users adding repos. expect. ...the huge problem with #3 is kind of fixed by 985354, in that the few repos. we _know_ almost all users really need will now be marked correctly again. Ofc. we somehow have to do the same thing for RHN/CM/pulp/etc. created repos. and a significant amount of work in #2 to educate users (but likely not, someone will just be on the support end of random "my repos. sometimes don't work" questions). But then how many people that have created a .repo file would willingly say "yes, my repo. is worthless feel free to ignore it". I can certainly imagine that someone will open a similar bug to 985354 bug for rpmfusion, given that pretty much all the users who installed that repo. won't want it to just disappear randomly ... except the most compelling example from the user side is when using --releasever and that almost always hits rpmfusion. After a change like this I'd guess that the only thing stopping adobe and/or most other repos. adding the magic "yes, this repo. is not worthless" flag will be ignorance with a distant second option of apathy. And the gain is very minimal, having even a single broken repo. enabled with skip_if_unavailable=true just turns yum from "doesn't work and tells me why" to the _best_ outcome of "yum is a lot slower, and prints these annoying messages about FOO repo."
I'm not sure what you mean by "disappear randomly" and "a lot slower". I see this from the perspective of a general user, and third-party repos are mainly used for adding a single-program repository, like dropbox, google chrome, adobe or anything from opensuse build service. Rpmfusion is the largest third-party repo I know about that is heavily used, and it's used mostly for multimedia codecs, drivers and VLC/VirtualBox. If such a repository isn't available at the time of "yum update", nothing extraordinary happens, those packages just won't get updated. From a corporate deployment view, I think that these enviroments are pretty well able to decide whether a repo should be mandatory or optional. But general users can't, so _they_ need to be the target of the sane defaults. If my computer "stops working" (e.g. can't install anything) just because a dropbox server is down, well, that's not a reliable OS for me. Originally I assumed that PackageKit is affected by this yum implementation decision, but now I've tried it and I'm quite surprised it is not. It can operate even with a dropbox repo down, which brings yum to its knees. So that's good, gpk-application is not affected. But I know many "general users" who learned yum basics just because gpk-application is so terrible. So these will be affected. I believe that if yum printed reasonable error messages in the first place, I wouldn't be so annoyed to report this bug, and many users would be spared these problem. But this is *not* a helpful message: $ yum install foo Loaded plugins: changelog, langpacks, refresh-packagekit http://linux.dropbox.com/fedora/19/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. Error: failure: repodata/repomd.xml from Dropbox: [Errno 256] No more mirrors to try. http://linux.dropbox.com/fedora/19/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found It doesn't tell me in human language what just happened. It doesn't ask me to continue and ignore the failed repo. It doesn't tell me which repo is affected (I have to guess from the URL). It doesn't tell me how to easily avoid these problems (moreover without editing the repo files). So, the slightly advanced users are absolutely clueless. If yum printed something like: "Repository dropbox (which is marked as system essential) is not available at the moment. If you want to ignore this problem, run this command: yum install foo --disablerepo=dropbox" or even better, if the question was interactive, then it would be much more helpful to less-skilled users and maybe I wouldn't have reported this bug. By the way, I have no proof of this, but I believe most of third-party repos really don't intend to break Fedora when their servers are not available, and they are missing skip_if_unavailable=true just because of their ignorance. I can easily imagine their programmers saying "what's the easiest way to create a yum repo?", firing up google, copying a random example and bam! repo is here. They won't spend hours studying dozens of options; the example worked, so what's the problem, right? (Btw skip_if_unavailable is documented almost at the end of man yum.conf, which lowers the chances of anyone actually reading it). So, I don't really expect dropbox/anyone else to add skip_if_unavailable=true to their repo files, once the default is flipped. Because there is nothing to win, just lose (annoyed user base). I understand that there is some price to be paid in corporate environment (the tools must be adjusted to produce skip_if_unavailable=true if their repos are essential). There is no price to be paid for general users, just benefits. So that's why I asked dnf to implement this, we expect slight differences between yum and dnf and I think this one is not that problematic. I can understand that this can get rejected in yum. But maybe yum could at least improve the error messages, if nothing else?
*** Bug 1003112 has been marked as a duplicate of this bug. ***
> I'm not sure what you mean by "disappear randomly" and "a lot slower". yum will seem functional, but repos. will disappear ... that's what skip_if_unavailable does. yum will be a lot slower because everytime it does anything it'll spend time trying to do a connection to the unavailable repos. ... for a lot of commands hitting the network at all is a guaranteed perf. hit of 2x+ (and that's assuming a 404 and not a timeout or something). > It doesn't tell me in human language what just happened. It doesn't ask me to > continue and ignore the failed repo. I updated the messages, so it prints a giant message telling you what has happened and the different things you can do to fix it (including how to set skip_if_unavailable for that repo., if that's what the user wants). I think that should be in f19 by now.
I tried yum-3.4.3-108.fc19.noarch (not yet in updates) and it seems to work well. The text is really extensive, and it documents the problem well. Thanks. For book-keeping purposes an example output is below. > $ yum install foo > Loaded plugins: changelog, langpacks, refresh-packagekit > http://linux.dropbox.com/fedora/19/aaa/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found > Trying other mirror. > > > One of the configured repositories failed (Dropbox Repository), and yum doesn't have > enough cached data to continue. At this point the only safe thing yum can do > is fail. > There are a few ways to work "fix" this: > > 1. Contact the upstream for the repository and get them to fix the problem. > > 2. Reconfigure the baseurl/etc. for the repository, to point to a working > upstream. This is most often useful if you are using a newer > distribution release than is supported by the repository (and the > packages for the previous distribution release still work). > > 3. Disable the repository, so yum won't use it by default. Yum will then > just ignore the repository until you permanently enable it again or use > --enablerepo for temporary usage: > > yum-config-manager --disable Dropbox > > 4. Configure the failing repository to be skipped, if it is unavailable. > Note that yum will try to contact the repo. when it runs most commands, > so will have to try and fail each time (and thus. yum will be be much > slower). If it is a very temporary problem though, this is often a nice > compromise: > > yum-config-manager --save --setopt=skip_if_unavailable=true Dropbox > > failure: repodata/repomd.xml from Dropbox: [Errno 256] No more mirrors to try. > http://linux.dropbox.com/fedora/19/aaa/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
(In reply to Kamil Páral from comment #9) > > yum-config-manager --save --setopt=skip_if_unavailable=true Dropbox Hmm, actually, this doesn't seem to work. Is that a correct command? It just prints output to the terminal, but doesn't really update the .repo file.
Yep, it does not work :) The correct command is: # yum-config-manager --save --setopt=Dropbox.skip_if_unavailable=true I've fixed this in HEAD.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
yum is dead, and dnf accepted this as default. Closing.