Cloned from yum to dnf. We're building a "next-gen yum" from scratch and fixing the errors of the past, and this is a perfect fit I think :) +++ This bug was initially created as a clone of Bug #867389 +++ 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 --- Additional comment from Freddy Willemsen on 2013-01-18 08:37:00 CET --- 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. --- Additional comment from Fedora End Of Life on 2013-04-03 18:58:16 CEST --- 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 --- Additional comment from Kamil Páral on 2013-07-15 13:10:12 CEST --- 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. --- Additional comment from Kamil Páral on 2013-07-15 13:12:40 CEST --- [1] https://build.opensuse.org/
This is reasonable, will implement.
Fixed by 086cb61, will be included in dnf-0.3.10.
hawkey-0.3.16-1.git4e79abc.fc19, dnf-0.3.10-1.giteb9dddb.fc19, librepo-0.0.5-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/dnf-0.3.10-1.giteb9dddb.fc19,librepo-0.0.5-2.fc19,hawkey-0.3.16-1.git4e79abc.fc19
Package hawkey-0.3.16-1.git4e79abc.fc19, dnf-0.3.10-1.giteb9dddb.fc19, librepo-0.0.5-2.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing hawkey-0.3.16-1.git4e79abc.fc19 dnf-0.3.10-1.giteb9dddb.fc19 librepo-0.0.5-2.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-13415/dnf-0.3.10-1.giteb9dddb.fc19,librepo-0.0.5-2.fc19,hawkey-0.3.16-1.git4e79abc.fc19 then log in and leave karma (feedback).
hawkey-0.3.16-1.git4e79abc.fc19, dnf-0.3.10-1.giteb9dddb.fc19, librepo-0.0.5-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.