Bug 1119030 - skip_if_unavailable to correctly treat repos that are down during package download
skip_if_unavailable to correctly treat repos that are down during package dow...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
21
Unspecified Unspecified
low Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-13 06:16 EDT by Jaroslav Škarvada
Modified: 2015-03-05 09:27 EST (History)
7 users (show)

See Also:
Fixed In Version: hawkey-0.5.3-2.fc21
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-20 03:32:05 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jaroslav Škarvada 2014-07-13 06:16:03 EDT
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 01:06:19 EDT
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 04:29:49 EST
+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 04:38:31 EST
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 04:39:23 EST
(or maybe the behaviour has improved in 0.6?)
Comment 5 Jaroslav Škarvada 2015-02-13 04:45:55 EST
(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 04:48:07 EST
If skip_if_unavailable=1, unavailable repos should be skipped for download, even if cached.
Comment 7 Jens Petersen 2015-02-13 05:00:12 EST
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 05:01:40 EST
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 08:21:15 EST
(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-15 19:02:56 EST
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 03:03:51 EST
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 04:35:52 EST
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 03:32:05 EST
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 09:27:58 EST
(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 :)

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