On Thu, Apr 25, 2019 at 6:39 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > > > Dne 24. 04. 19 v 23:04 Ben Cotton napsal(a): > > https://fedoraproject.org/wiki/Changes/Set_skip_if_unavailable_default_to_false > > > > == 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@xxxxxxxxxx > > > > == 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@xxxxxxxxx> > > == 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
