|Summary:||skip_if_unavailable to correctly treat repos that are down during package download|
|Product:||[Fedora] Fedora||Reporter:||Jaroslav Škarvada <jskarvad>|
|Component:||dnf||Assignee:||Packaging Maintenance Team <packaging-team-maint>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||21||CC:||jsilhan, jzeleny, packaging-team-maint, petersen, pnemade, rholy, tla|
|Fixed In Version:||hawkey-0.5.3-2.fc21||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-02-20 08:32:05 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Jaroslav Škarvada 2014-07-13 10:16:03 UTC
Description of problem: I have some optional repos that are accessible only from the office or through the VPN and they have "skip_if_unavailable=1" in their .repo files. The problem is if I try to update the system outside office and without VPN and if there are update candidates in the optional repos, the update process fails. Version-Release number of selected component (if applicable): dnf-0.5.3-1.fc20.noarch How reproducible: Always Steps to Reproduce: 1. Have repo with skip_if_unavailable=1 and with update candidates 2. Let metadata to sync 3. Make the repo unavailable 4. dnf upgrade Actual results: Update fails Expected results: No failure, repo skip Additional info: I encountered this with the qa repo (http://liver.englab.brq.redhat.com/repo/) and I got the following error: [FAILED] qa-tools-workstation-3.2-278.x86_64.rpm: No more mirrors to try - All mirrors were already tried without success It seems to work if I use --disablerepo=qa or if I clean the cache/metadata by: # dnf clean all It is annoying if there are more optional repos to use --disablerepo for all of them. I think the skip_if_unavailable=1 should work here.
Comment 1 Ales Kozumplik 2014-07-14 05:06:19 UTC
Hello, thanks for the report, we'll take a look at what can be done: either provide this or update the documentation of `skip_if_unavailable`.
Comment 2 Jens Petersen 2015-02-13 09:29:49 UTC
+1 to fixing this. I see this behaviour with F21 too. I feel this this should be higher than low priority. Naively this behaviour seems to contradict https://github.com/rpm-software-management/dnf/blob/master/doc/cli_vs_yum.rst#skip-if-unavailable-enabled-by-default
Comment 3 Jens Petersen 2015-02-13 09:38:31 UTC
Ah okay sorry I understand this is about if there is only an update in the unavailable repo then: then I suggest just making an better error message to that effect.
Comment 4 Jens Petersen 2015-02-13 09:39:23 UTC
(or maybe the behaviour has improved in 0.6?)
Comment 5 Jaroslav Škarvada 2015-02-13 09:45:55 UTC
(In reply to Jens Petersen from comment #3) > Ah okay sorry I understand this is about if there is only an update in > the unavailable repo then: then I suggest just making an better error > message to that effect. The problem is that it doesn't complete the transaction. It can write any error it likes, but it should complete the transaction without the unavailable packages (which aren't deps). It is pain discovering which package belongs to which repo and disabling such repo by hand.
Comment 6 Jaroslav Škarvada 2015-02-13 09:48:07 UTC
If skip_if_unavailable=1, unavailable repos should be skipped for download, even if cached.
Comment 7 Jens Petersen 2015-02-13 10:00:12 UTC
Sorry for too many comments (I am jetlagged too): I think what I saw on F21 was just just a "repo unavailable warning": "dnf --refresh update" actually worked for me without disabling the unavailable repo. So it was just the lack of any updates that confused me.
Comment 8 Jens Petersen 2015-02-13 10:01:40 UTC
Jaroslav: is the behaviour better on F21, ie worse with F20? Under F21 dnf seems to do the expected thing I think.
Comment 9 Jaroslav Škarvada 2015-02-13 13:21:15 UTC
(In reply to Jens Petersen from comment #8) > Jaroslav: is the behaviour better on F21, ie worse with F20? > > Under F21 dnf seems to do the expected thing I think. I currently cannot say, I need to retest. But I haven't noticed this problem any more since the switch to f21, so it was probably fixed.
Comment 10 Fedora Update System 2015-02-16 00:02:56 UTC
dnf-plugins-core-0.1.5-1.fc21,hawkey-0.5.3-2.fc21,dnf-0.6.4-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/dnf-plugins-core-0.1.5-1.fc21,hawkey-0.5.3-2.fc21,dnf-0.6.4-1.fc21
Comment 11 Fedora Update System 2015-02-17 08:03:51 UTC
Package hawkey-0.5.3-2.fc21, dnf-plugins-core-0.1.5-1.fc21, dnf-0.6.4-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing hawkey-0.5.3-2.fc21 dnf-plugins-core-0.1.5-1.fc21 dnf-0.6.4-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-2139/dnf-plugins-core-0.1.5-1.fc21,hawkey-0.5.3-2.fc21,dnf-0.6.4-1.fc21 then log in and leave karma (feedback).
Comment 12 Jens Petersen 2015-02-17 09:35:52 UTC
This is an F20 bug, so not completely sure why it was included in FEDORA-2015-2139. Maybe it should be removed? Or can you summarize what changed? AFAICT there is no serious problem with F21 but I prefer yum's behaviour of only showing the warning for update not all commands like dnf seems to do. So I'd like to suggest doing the same in dnf: only print the "repo unavailable" when doing dnf update I think. I can also file a separate RFE for that behaviour...
Comment 13 Fedora Update System 2015-02-20 08:32:05 UTC
hawkey-0.5.3-2.fc21, dnf-plugins-core-0.1.5-1.fc21, dnf-0.6.4-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Comment 14 Honza Silhan 2015-03-05 14:27:58 UTC
(In reply to Jens Petersen from comment #12) > This is an F20 bug, so not completely sure why it was included in > FEDORA-2015-2139. Maybe it should be removed? Or can you summarize > what changed? This bug was still in the upstream. > AFAICT there is no serious problem with F21 but I prefer yum's > behaviour of only showing the warning for update not all commands > like dnf seems to do. So I'd like to suggest doing the same > in dnf: only print the "repo unavailable" when doing dnf update > I think. I can also file a separate RFE for that behaviour... For me it makes more sense to print it everytime you deal with available packages (when it downloads new metadata) - the way DNF does it now. No need to file RFE :)