On Wed, Apr 24, 2019 at 7:04 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:

...

== Detailed Description ==

Dnf team wants to change a default setting for the repo option `skip_if_unavailable` to `FALSE`. The option is responsible for behavior when metadata of a repository is unavailable. When it is set to false, it will stop on the first unavailable repository with raising an error. The default behavior could be overwritten by a configuration of each repository or in dnf by configuration in /etc/dnf/dnf.conf.

The behavior is not new, because it was used already by YUM, and the behavior is really essential because all Fedora ropos are already shipped with `skip_if_unavailable=FALSE`.

Do I understand correctly that this is the global default, and the setting in each repo file overrides the setting for that repo? Most repos contain either skip_if_unavailable=False or skip_if_unavailable=True and they will not be affected by this?

That was my understanding, yes. If it is set in the repo file, that will override the default.

On 25/04/19 09:35 +0200, Dridi Boukelmoune wrote:

Also please note that fedora-cisco-openh264.repo ships with "skip_if_unavailable=true".

off-topic: which in fact doesn't matter much, since you'll, sooner or later and whether you want or not, receive non-free (in a sense) binaries over the native Firefox channel (guidelines yada yada yada) anyway: https://bugzilla.redhat.com/show_bug.cgi?id=1648024

On Fri, Apr 26, 2019 at 9:31 AM Dridi Boukelmoune < dridi.boukelmoune@gmail.com> wrote:

On Thu, Apr 25, 2019 at 11:50 PM Jan Pokorný jpokorny@redhat.com wrote:

...

On 25/04/19 09:35 +0200, Dridi Boukelmoune wrote:

...

Also please note that fedora-cisco-openh264.repo ships with "skip_if_unavailable=true".

off-topic: which in fact doesn't matter much, since you'll, sooner or later and whether you want or not, receive non-free (in a sense) binaries over the native Firefox channel (guidelines yada yada yada) anyway: https://bugzilla.redhat.com/show_bug.cgi?id=1648024

Not entirely off topic, the change description states that Fedora repositories ship with skip_if_unavailable=false but fedora-cisco-openh264.repo doesn't.

Thanks for the bug report, that explains what I thought was pebcak when this was introduced and all I could do was disable the plugin. But I would argue that bug is off topic ;-)

I just hope the DNF team would implement a retry on failed downloads to not consider a repository unavailable right off the bat especially when we have a list of mirrors to pick from.

We are working on improvement.

Jaroslav DNF team developer

Dridi _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

On Sat, Apr 27, 2019 at 12:23 PM Dridi Boukelmoune < dridi.boukelmoune@gmail.com> wrote:

On Sat, Apr 27, 2019 at 10:13 AM Jaroslav Mracek jmracek@redhat.com wrote:

...

snip

...

...

I just hope the DNF team would implement a retry on failed downloads to not consider a repository unavailable right off the bat especially when we have a list of mirrors to pick from.

We are working on improvement.

Thanks, I'm really looking forward to that!

Is there a ticket I can subscribe to?

https://bugzilla.redhat.com/show_bug.cgi?id=1690894 https://bugzilla.redhat.com/show_bug.cgi?id=1643281 https://bugzilla.redhat.com/show_bug.cgi?id=1678588

Jaroslav

...

Jaroslav DNF team developer

...

Dridi _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:

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

...

---

devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

On Thu, Apr 25, 2019 at 6:39 AM Vít Ondruch vondruch@redhat.com wrote:

Dne 24. 04. 19 v 23:04 Ben Cotton napsal(a):

...

https://fedoraproject.org/wiki/Changes/Set_skip_if_unavailable_default_to_fa...

== Summary == Dnf team wants to change a default setting for the repo option `skip_if_unavailable` to `FALSE`.

== Owner ==

• Name: [[User:jmracek| Jaroslav Mracek]]
• Email: jmracek@redhat.com

== Detailed Description ==

Dnf team wants to change a default setting for the repo option `skip_if_unavailable` to `FALSE`. The option is responsible for behavior when metadata of a repository is unavailable. When it is set to false, it will stop on the first unavailable repository with raising an error.

I am not sure I undrestand. What stops with what value? What is the problem this tries to solve?

Since repositories such as "fedora" and "updates" can have overlapping RPM's, and being without either of those makes compilatoin potentially quite erratic, I don't see this as a safe idea. I realize it was written into /etc/yum.repos.d/fedora.repo as manually setting "skip_if_anavailable=False". And by the way, the case of such settings should be consistent for legibility. But I see it having been a really bad idea for repositories like "fedora" and "updates", since those have overlapping content and having one disabled could lead to serious problems with the other. If you have a messed up local network that does not allow access to the most basic of dnf repositories, it should require attention at the command line to exclude those repositories as desired, not a misplaced "let's just ignore that we don't have a hammer and use duct tape instead without checking first" approach to a critical installation failure.

...

The default behavior could be overwritten by a configuration of each repository or in dnf by configuration in /etc/dnf/dnf.conf.

Or overridden for specific repositories as needed in mock, koji, or the individual .repo files. I intensely dislike the exclussion in fedora.repo: the only reason I can see for it is to enable the Media repository with no other work and have things kind-of, sort-of work.

...

The behavior is not new, because it was used already by YUM, and the behavior is really essential because all Fedora ropos are already shipped with `skip_if_unavailable=FALSE`.

Which I think was a horrible, horrible idea, for reasons mentioned above.

...

The change will be applied in libdnf library, and the changed behavior will be visible for all direct and indirect users of the library: dnf, microdnf, PackageKit, ... .

== Benefit to Fedora ==

It should provide a better security because some Important updates from third-party repositories could be present in temporary unavailable repository, but user can easily overlook it during `dnf update` because the issue is reported as a warning.

Then those repos can have skip_if_unavailable set individually, rather than as default. Better yet, they should be disabled by default and enabled only as desired for out-of-band, repository specific updates rather than otentially merging and mis-merging with the primary repositories as part of standard updates.

I'm sorry if I seem a bit cross about this: I've had to deal with third-party repositories including RPM's that overlapped with standard repositories, and they do require caution to handle. Guaranteeing erratic behavior base don the state of the connection to the third party repository seems *exactly* backwards from a stable approach to updates or installations, and the warning in the cluttered output of dnf commands seem sinsufficient.

Nico Kadel-Garcia nkadel@gmail.com

...

== Scope ==

• Proposal owners:

** Backport the following upstream pull requests into the DNF stack on Fedora: https://github.com/rpm-software-management/libdnf/pull/701

• Other developers: N/A
• Release engineering: [https://pagure.io/releng/issue/8307 #8307]
• Policies and guidelines: N/A
• Trademark approval: not needed for this Change

== How To Test == Edit .repo file in /etc/yum.repos.d/* and set an url that is not accessible.

Case 1: No skip_if_unavailable in the repo file, in /etc/dnf/dnf.conf or overwritten from commandline using `--setopt`. Any command that requires available repositories like `dnf repoquery` will fail due to an error `Error: Failed to synchronize cache for repo '<repo_ID>'`

Case 2: Set skip_if_unavailable=true in the repo file. Any command that requires available repositories like `dnf repoquery` will not fail due to missing metadata of the `<repo_id>`

== User Experience ==

Broken repositories are recognized early, enabling the users to act upon them by double-checking their repository configuration or filing bugs, instead of assuming no upgrades are available.

== Dependencies == Depend packages - dnf, microdnf, PackageKit

There are no changes on which completion of this change depends.

== Contingency Plan ==

• Contingency mechanism: (What to do? Who will do it?)

The change requires a merge and a release of the pull-request https://github.com/rpm-software-management/libdnf/pull/701

• Contingency deadline: Should be delivered before 2019-07-24.
• Blocks release? No
• Blocks product? No

== Documentation == https://dnf.readthedocs.io/en/latest/conf_ref.html

Update for documentation: https://github.com/rpm-software-management/dnf/pull/1358

---

devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

On Thu, Apr 25, 2019 at 1:53 PM Samuel Sieb samuel@sieb.net wrote:

On 4/25/19 10:04 AM, Nico Kadel-Garcia wrote:

...

On Thu, Apr 25, 2019 at 6:39 AM Vít Ondruch vondruch@redhat.com wrote:

...

Dne 24. 04. 19 v 23:04 Ben Cotton napsal(a):

...

https://fedoraproject.org/wiki/Changes/Set_skip_if_unavailable_default_to_fa...

== Summary == Dnf team wants to change a default setting for the repo option `skip_if_unavailable` to `FALSE`.

...

...

...

The default behavior could be overwritten by a configuration of each repository or in dnf by configuration in /etc/dnf/dnf.conf.

Or overridden for specific repositories as needed in mock, koji, or the individual .repo files. I intensely dislike the exclussion in fedora.repo: the only reason I can see for it is to enable the Media repository with no other work and have things kind-of, sort-of work.

...

...

The behavior is not new, because it was used already by YUM, and the behavior is really essential because all Fedora ropos are already shipped with `skip_if_unavailable=FALSE`.

Which I think was a horrible, horrible idea, for reasons mentioned above.

It sounds to me like you are misunderstanding the setting. When it is set to false, you can't do updates when a repository is missing. It won't skip them. You can only do an update if all repositories are available and can be checked.

Gahhh. I read the logic backwards. I take back my objection, "False" is the much safer option, in general, and should be overruled on a case by case basis. The difficulty is that people used to the convention are going to wind up confused. Perhaps it should be explicitly listed in the [main] stanza ?