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):
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
No failure, repo skip
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.
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`.
+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
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.
(or maybe the behaviour has improved in 0.6?)
(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.
If skip_if_unavailable=1, unavailable repos should be skipped for download, even if cached.
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.
Jaroslav: is the behaviour better on F21, ie worse with F20?
Under F21 dnf seems to do the expected thing I think.
(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.
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.
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:
then log in and leave karma (feedback).
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
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...
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.
(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 :)