From Fedora Project Wiki
(Send proposal back to owner to address self-contained versus system-wide question (sent via email))
(Updated Contingency Plan)
Line 100: Line 100:
 
<!-- 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.  -->
 
<!-- 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 -->
 
* 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. -->
 
<!-- 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 -->
 
* 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? -->
 
<!-- 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 -->
 
* 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 -->
 
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
 +
No
  
 
== Documentation ==
 
== Documentation ==

Revision as of 08:01, 23 April 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

Current status

  • Targeted release: Fedora 31
  • Last updated: 2019-04-23
  • Tracker bug: <will be assigned by the Wrangler>

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

  • Other developers: 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

N/A (not a System Wide Change)

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

N/A (not a System Wide Change)

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

N/A (not a System Wide Change)

Release Notes