I feel a bit concerned about the user experience when a third party repository breaks. Suppose there were an important Fedora update, and a third party repository is unavailable.

Perhaps it would be good if the proposal included dnf printing a suggestion to the user about how they can override this behavior when they hit a missing repository? Perhaps something like this:

$ sudo dnf upgrade
<snip>
Error: Failed to synchronize cache for repo '<repo_ID>'
Hint: You can use --skip-if-unavailable true to ignore broken repositories.

What do you think?

The problem with that is that it'll recommend that when OUR repos break. (E.g. mirrormanager is having a bad day). Maybe we should try suggesting:

"Hint: If this repository is not required for normal operation, you can disable it temporarily with --disablerepo=<repo_ID>"

"Hint: If this repository is not required for normal operation, you can disable it temporarily with --disablerepo=<repo_ID> or permanently be editing <repo_file_path>."

Those alternatives sound fine to me.

I'm not sure DNF has the repo file path available to it at the point where this message would be emitted, but we could suggest reading the docs on skip_if_unavailable.

I think we're coming to a consensus at least, so I'll formalize a proposal:

Proposal: FESCo approves this Change, contingent on a new message informing the user of how to work around issues when a repo is unavailable.

On Thu, 2019-05-02 at 19:04 +0000, Stephen Gallagher wrote:

Proposal: FESCo approves this Change, contingent on a new message
informing the user of how to work around issues when a repo is
unavailable.

+1

I'm +1 to the change... I'm not sure we should make approval contingent on it. They may have a design for when and where they notify users about things and there may be implementation details (like the repo not being known), etc. Perhaps dnf folks could chime in on that?

I'm +1 to the change... I'm not sure we should make approval contingent on it. They may have a design for when and where they notify users about things and there may be implementation details (like the repo not being known), etc. Perhaps dnf folks could chime in on that?

That's why I phrased the proposal to avoid specifying when and where the notification takes place, just that it does.

I don't understand the reasoning for this change. All of the repos that Fedora ships in fedora-repos already have a skip_if_unavailable line in the .repo files, overriding the default setting.

This means that this change only affects 3rd party repos that don't override the key and would change nothing for Fedora repos.

For 3rd party repos I think it makes sense to have the default as skip_if_unavailable=true since otherwise a random broken 3rd party repo could prevent updates from core Fedora repos being applied.

I don't really care what the default is. What I'm concerned about is the "silent" way we are changing it:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LSVUKBCGFIOIWQZDTREWL3VXD5JIK5A6/

Generally, I'd say explicit is better than implicit and would be much happier if we decided to demand the option be set.

AGREED: F31 System-Wide Change: Set skip_if_unavailable default to false is approved (+7,0,-1)

Leaving open because I believe a couple of people wanted to express some UX concerns

It has been 20 days and no further concerns were raised in this ticket. Closing.

I'd like to reopen this ticket for discussion, because I've just stumbled over an issue that I don't think we adequately considered when we approved this.

I have on my system several third-party repositories (some are for internal Red Hat tools, one is for Dropbox support in Nautilus). I upgraded today from Fedora 30 to Fedora 31 and subsequently was unable to run dnf update or dnf list updates successfully. Why? Because some of these repositories did not explicitly list skip_if_unavailable=True.

At the same time, I received multiple notifications of unreachable repositories, with no clear indication of which ones were failing and being skipped versus failing and causing operations to cease. In fact, there was little distinction between the the repo that caused the transaction to abort and the repos that were just unreachable (because they didn't yet have a Fedora 31 $releasever path)

The major problem with this situation is that once you are in it, you need to know how to modify repo configuration files to get out of it (and you cannot receive updates until and unless you do so). We cannot fix this with an update (since they can't update anyway) and we have no control over third-party repository configs anyway.

I propose that we revert this change until such time as the UX provides enough information for a non-expert user to be able to resolve such situations.

Isn't that exactly what we've agreed upon?

Leaving open because I believe a couple of people wanted to express some UX concerns

...

It has been 20 days and no further concerns were raised in this ticket.

For the reference: https://meetbot.fedoraproject.org/fedora-meeting/2019-05-03/fesco.2019-05-03-15.00.log.html

For the reference: https://meetbot.fedoraproject.org/fedora-meeting/2019-05-03/fesco.2019-05-03-15.00.log.html

Yeah, I reviewed that beforehand, but I don't think we really understood that actual end-user impact at the time. This will result in many of our users not receiving updates. I don't think that's acceptable. I'm asking for us to reconsider it.

The biggest risk will be right around release day, when third party repos haven't yet updated to understand $releasever==31 and so refuse connections. The end result here is that no updates are received. The second-largest risk is when a third-party has an outage (or goes away entirely). The latter may mean that this user will never see another update.

I'd like to see this Change reverted and I'd like to propose that we go a release or two with a new warning message that the skip_if_unavailable option will be changing defaults (or, even better, that as of F32 or F33 it will no longer be optional).

The biggest risk will be right around release day, when third party repos haven't yet updated to understand $releasever==31 and so refuse connections. The end result here is that no updates are received. The second-largest risk is when a third-party has an outage (or goes away entirely). The latter may mean that this user will never see another update.

That was exactly my concern too. See https://pagure.io/fesco/issue/2125#comment-568714

I'd like to see this Change reverted and I'd like to propose that we go a release or two with a new warning message that the skip_if_unavailable option will be changing defaults (or, even better, that as of F32 or F33 it will no longer be optional).

That sounds reasonable. See also https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LSVUKBCGFIOIWQZDTREWL3VXD5JIK5A6/

The change needs to be reverted, it's overall a bad UX, but it's also a security risk. The user goes to install a 3rd party repo RPM, the repo isn't available, and now they aren't getting updates, and it's non-obvious why.

It's sad we go around in circles. skip_if_unavailable used to default to False in yum. In those times, your package manager failed to function randomly once per week, because some third-party repo had a bad day. And there wasn't a better solution than to disable the repo temporarily until their infra worked again, or edit the repo and add the skip_if_unavailable=True line, and then repeat that each time you upgraded your Fedora version or each time their repo file changed. Users like my parents (whom I installed their PC) were of course incapable of doing any of that, and so their package managers sometimes simply didn't work and they had to wait a day or two.

Because I was really depressed about the state of things, I convinced Alez Kozumplik to change the default in DNF, once it got born. And things improved considerably. Third party repos were no longer blocking system updates or installing Fedora-provided software.

And now the default was flipped back with (I feel) a poor justification. All the third party repos will again start breaking our package managers. I already filed bugs against workstation extra repos and rpmfusion repos, but those are the easy fixes. We won't be able to add the necessary line to dropbox repo, atom repo, flash repo, skype repo, or whatever else third-party repo is out there. And their maintainers won't care to change it, because we already were in this situation, and they clearly didn't care.

I feel the default is being flipped because of Server/Cloud use cases, in which cases you don't work interactively with the system at all, all you do is run dnf update -y through ansible, and therefore it's easy to miss warnings about inaccessible repos. But that's also the very environment where it's trivial to override skip_if_unavailable in dnf.conf. For Fedora desktop users, though, I feel that this is a disservice and a wrong move.

Anyway, I'd prefer the UX to be better, but based on experience, I don't trust it will happen, so consider me +1 to revert (but I'd happily reconsider if the error is actionable).

Just wanted to back up @kparal , @chrismurphy , @sgallagh etc. here: I also think this was a mistake and should be reverted. You can see 'bad' scenarios either way, but I think the least bad choice is definitely True. If a third party repo thinks it's so goddamn important it can always set skip_if_unavailable=False explicitly in its config, then at least it's clearly that repo's fault and not ours.

7 days after the proposal, it only got +2. If we get one more, it gets approved.

+1 to revert

APPROVED (+3, 0, -0) We revert this change until such time as the UX provides enough information for a non-expert user to be able to resolve such situations.

I've opened https://bugzilla.redhat.com/show_bug.cgi?id=1752249

I missed the vote, but I agree that this is a good decision. Looking at the repos I have, non-fedora repo's all either set skip_if_unavailable=True OR don't have anything set. "Promoting" those that don't have anything set to skip_if_unavailable=False seems unexpected and wrong.

Late since I was travelling last week, but for the record, I agree with the revert. The user experience with F31 as it is now is certainly not optimal.