From Fedora Project Wiki
m
m (fixing summary)
Line 28: Line 28:
 
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release.  
 
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release.  
 
Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?". -->
 
Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?". -->
All Fedora installations will have access to the modular repositories, previously available by default only to Server Edition.
+
All Fedora installations will have modular repositories enabled by default, previously available, by default, only to Server Edition.
  
 
== Owner ==
 
== Owner ==

Revision as of 13:18, 12 June 2018


Change Proposal Name

Modules for Everyone

Summary

All Fedora installations will have modular repositories enabled by default, previously available, by default, only to Server Edition.

Owner

Current status

  • Targeted release: Fedora 29
  • Last updated: 2018-06-12
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

In Fedora 28, the Server Edition debuted new modular functionality, allowing end-users access to alternative versions of popular software. Due to technical limitations with package-management software, it was not available for non-Server deployments of Fedora. Beginning with Fedora 29, all installations of Fedora will have modules available for installation and update. This will be done by merging the fedora-repos-modular sub-package back into the fedora-repos package.

Benefit to Fedora

Fedora users will have access to a wider range of software choices than they had previously. Fedora Packagers will be able to use modules and module defaults to build each stream once and have it available for any supported Fedora release they wish. They will no longer need to duplicate that work for both the modular and non-modular repositories.


Scope

  • Proposal owners:

The proposal owners need to coordinate the work of the DNF team and release-engineering to make sure that the repo subpackage merge only happens once the libdnf enhancements are stable. We will also need to prepare and run a Fedora Test Day with the QA team.

  • Other developers:

The DNF team is already committed to providing the necessary changes for libdnf in Fedora 29.

  • Release engineering: #7561 (a check of an impact with Release Engineering is needed)
  • Policies and guidelines: No alterations to packaging guidelines are required specifically for this change
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

The fedora-repos package will add Obsoletes: fedora-repos-modular and then provide its functionality. There will be no manual migration required.


How To Test

Users will be able to test all modular functionality for all releases. We are coordinating with Fedora QA to establish release-blocking criteria for this functionality.

It is important to note that Fedora's blocking criteria will apply *only* to packages in the traditional RPM repos or default streams of modules. We will not be expanding the test matrix to include non-default module streams at this time.

User Experience

The user experience may be as transparent to users as they wish. If users remain unaware or uncaring about modules, all of their existing commands and workflows will continue to work. If they wish to interact with modules, they can do so with any of the dnf module <foo> commands that were added in Fedora 28 for Server Edition.

Note: this Change Proposal does *not* imply changes to user experience in GNOME Software, Cockpit or any other graphical package manager. Those may come as part of separate Changes in the future. Their involvement in this Change is such that they must honor any changes to enabled modules that occur via direct DNF usage.

Dependencies

The primary dependency is the update of package managers that use libdnf to adapt to the new changes being merged there. We are in constant communication with the libdnf team and will keep FESCo in the loop on the progress there. If the libdnf/PackageKit/etc. changes do not land in time, we will invoke the Contingency Plan (below).

Contingency Plan

  • Contingency mechanism: The merging of the fedora-repos-modular package into fedora-repos will be aborted (or reversed, if necessary) and we will revert to the Fedora 28 behavior of shipping modules only for Server Edition
  • Contingency deadline: Two weeks prior to the Beta Freeze (Aug. 14th). This allows us time to adjust any packages that were modularized with the expectation of release in F29 beta prior to Freeze.
  • Blocks release? No
  • Blocks product? N/A

Documentation


Release Notes

All Fedora Installations now have access to the module repositories with alternative versions of some popular software packages.