Latest revision as of 19:51, 18 September 2019

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: Jaroslav Mracek
Email: jmracek@redhat.com
Release notes owner:

Current status

Targeted release: Fedora 31
Last updated: 2019-09-18
Tracker bug: #1706160
Release notes tracker: #336

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.

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.

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 (not a System Wide Change)

Release engineering: #8307 (a check of an impact with Release Engineering is needed)

- List of deliverables: N/A (not a System Wide Change)

Policies and guidelines: N/A
Trademark approval: not needed for this Change

Upgrade/compatibility impact

N/A (not a System Wide 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?) N/A (not a System Wide Change)

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

Contingency deadline: N/A (not a System Wide Change)

Should be delivered before 2019-07-24.

Blocks release? N/A (not a System Wide Change), Yes/No

No

Blocks product? product

No

Documentation

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

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

Release Notes

@@ Line 21: / Line 21: @@
 CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
 -->
-* Tracker bug: <will be assigned by the Wrangler>
+* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1706160 #1706160]
+* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/336 #336]
 == Detailed Description ==
@@ Line 42: / Line 43: @@
 <!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
-* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
+* Release engineering: [https://pagure.io/releng/issue/8307 #8307] (a check of an impact with Release Engineering is needed)
-<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.
-The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
 ** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 <!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->
@@ Line 73: / Line 73: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (not a System Wide Change)
+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 ==
@@ Line 94: / Line 102: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (not a System Wide Change)
+Depend packages - dnf, microdnf, PackageKit
+There are no changes on which completion of this change depends.
 == Contingency Plan ==
@@ Line 100: / Line 110: @@
 <!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
 * Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+The change requires a merge and a release of the pull-request https://github.com/rpm-software-management/libdnf/pull/701
 <!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
 * Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+Should be delivered before 2019-07-24.
 <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
 * Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+No
 * Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
+No
 == Documentation ==
@@ Line 110: / Line 124: @@
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-N/A (not a System Wide Change)
+https://dnf.readthedocs.io/en/latest/conf_ref.html
+Update for documentation: https://github.com/rpm-software-management/dnf/pull/1358
 == Release Notes ==
@@ Line 119: / Line 135: @@
 -->
-[[Category:ChangePageincomplete]]
+[[Category:ChangePageIncomplete]]
 <!-- When your change proposal page is completed and ready for review and announcement -->
 <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
@@ Line 126: / Line 142: @@
 <!-- Select proper category, default is Self Contained Change -->
-[[Category:SelfContainedChange]]
+[[Category:SystemWideChange]]
 <!-- [[Category:SystemWideChange]] -->

Search

Changes/Set skip if unavailable default to false: Difference between revisions