F41 Change Proposal: Versioned Kubernetes Packages (Self-Cont
Wiki - https://fedoraproject.org/wiki/Changes/VersionedKubernetesPackages This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. = Multiple Versioned Kubernetes Packages = == Summary == Provide all maintained Kubernetes releases in Fedora as multiple, versioned packages. Current practice is a separate Kubernetes release matched with each Fedora release. == Owner == * Name: [[User:Buckaroogeek| Brad Smith]] * Email: bradley.g.sm...@gmail.com == Detailed Description == The Kubernetes project maintains 3 concurrent versions with a new release every 4 months. Each version has a defined life-cycle of approximately 1 year (https://https://kubernetes.io/releases/ for details and current versions). In this proposal a release is a major:minor version combination such as 1.28 or 1.27 and ignores any patch updates (e.g. 1.28.1 or 1.28.2 as these are part of the same 1.28 minor release). We currently match one version of Kubernetes with each Fedora release. See https://src.fedoraproject.org/rpms/kubernetes for the list of Kubernetes releases by Fedora release. Due to the differing release cadences between Fedora and Kubernetes this means that a new release of Fedora may not have the most current release of Kubernetes. And, given that the Kubernetes cluster upgrade process does not permit skipping major:minor releases, not providing a Kubernetes release in Fedora so that the most current Kubernetes release is available when a Fedora release goes into production becomes a barrier to using Fedora as a host OS for Kubernetes. We propose to create packages for all current Kubernetes releases for each Fedora release starting with Fedora 40. The package name would follow the Fedora naming convention standard for multiple package versions of "kubernetes[major].[minor]". Using the kubernetes-client rpm as an example, instead of kubernetes-client-1.29.2-1.fc41 Fedora would offer kubernetes1.29-client-1.29.2-1.fc41, kubernetes1.28-client-1.28.5-1.fc41, and kubernetes1.27-client-1.27.8-1.fc41. The exact list of Kubernetes versions available will depend on what is supported upstream. We also propose that there not be any default version of Kubernetes for a given Fedora release. Fedora would not provide a kubernetes-client-1.30.1-1.fc41 package available, assuming that Kubernetes 1.30 is the "default" for Fedora 41. Default versions coupled to a given Fedora release can result in unplanned version updates to the installed Kubernetes version (i.e. v1.28 to v1.29) which can adversely affect cluster functioning. It is also important to note that each Kubernetes release is built with a specific version of the Go language. The version of Go available in a Fedora release will potentially be a constraint on which version of Kubernetes can be provided for an older Fedora release. We also maintain a Kubernetes page on Fedora Quick Docs with information about the change and how to install Kubernetes using Fedora provided packages. == Feedback == To be provided. == Benefit to Fedora == Fedora becomes a first class platform for Kubernetes using packages from Fedora repositories. That is, all current, maintained releases of Kubernetes are available in the main Fedora repositories, subject to the Go language constraint. This allows Fedora, as a host OS for a Kubernetes cluster, to be maintained and upgraded independently of the Kubernetes release used by the cluster. This also allows the cluster to be upgraded independently of the Fedora release using Fedora provided packages. This also means that a Kubernetes cluster administrator using Fedora as their workstation can install and use or retain the appropriate Kubernetes command line client, kubectl, that matches the release of the cluster. Updating to a new Fedora release will not inadvertently install a command line client that is not compatible with the release version of the cluster(s) managed by the user. == Scope == * Proposal owners: With each new minor release of Kubernetes, package owners would request a new repository on src.fedoraproject.org from engineering similar to what the nodejs team now does for the parallel-installable versions of nodejs. Documentation would be refreshed to inform users of the new version and what specific Fedora releases the new version of Kubernetes would be available on. * Other developers: Releases of cri-o and cri-tools are version matched with Kubernetes release at the major:minor level. Cri-o uses modularity in Fedora 38 and older to provide multiple versions. The cri-o and cri-tools package maintainers will adopt a similar versioned approach to packaging and release in Fedora. * Release engineering: [https://pagure.io/releng/issues #Releng issue number] Release engineering would need to create the new dist-git repository for each new Kubernetes
F41 Change Proposal: Switch to DNF 5 (System-Wide)
Wiki - https://fedoraproject.org/wiki/Changes/SwitchToDnf5 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Change the default package manager from dnf to dnf5. == Owner == * Name: [[User:jkolarik| Jan Kolarik]] * Email: jkola...@redhat.com * Name: [[User:jmracek| Jaroslav Mracek]] * Email: jmra...@redhat.com == Detailed Description == This proposal will implement several topics, which are outlined below. === Provider of the dnf command === This change proposes to switch the current provider of the /usr/bin/dnf symlink from dnf to dnf5. Currently, the symlink target is /usr/bin/dnf-3, provided by the dnf sub-package, python3-dnf. Upon implementation of this change, the symlink will point to /usr/bin/dnf5, provided by the dnf5 package. === Prepare the upgrade path === The dnf5 package, serving as the new provider of the /usr/bin/dnf symlink, will obsolete the dnf package starting with Fedora 41. Upon the release of this dnf5 package, upgrading the system or installing dnf5 will replace the existing dnf package on the system. Additionally, the dnf5 package will provide a /usr/bin/yum symlink for backwards compatibility and the dnf-automatic command will be obsoleted. === Feature parity with dnf === We aim to cover the majority of use cases available in the existing dnf package. However, there are some features that may not be implemented in time. Nevertheless, we plan to deliver them at a later stage. Plugins The progress of implementing plugins to match the current set from the dnf-plugins-core package is tracked [https://github.com/rpm-software-management/dnf5/issues/389 upstream]. Among the missing plugins, we still plan to implement: * debuginfo-install plugin * reposync plugin Modularity As support for modularity was retired in Fedora 39, dnf5 currently only implements a basic feature set for listing and enabling/disabling modules. === Background service support === A new daemonized service, dnf5daemon, utilizing the D-Bus interface, is prepared for clients as a sub-package. This will serve as an alternative or replacement for the PackageKit layer. Integration of dnf5daemon support into the default Fedora user interface, GNOME Software, is currently in progress === Documentation of API changes === The public interface has undergone significant changes to enhance the user experience and remove unused and obsolete code components. To facilitate user migration to the new CLI and API interfaces, a [https://dnf5.readthedocs.io/en/latest/changes.html guide] was prepared covering all differences compared to the interface provided by the existing dnf package, along with examples of typical use cases. === Deployment tasks === During the deployment of the dnf5 package manager as the new default, several adjustments need to be made both to the infrastructure and the dnf5 package itself. Some of these adjustments are detailed [[#Release engineering|below]]. To ensure synchronization and address all necessary changes, we've established an upstream tracking [https://github.com/rpm-software-management/dnf5/issues/1057 issue]. == Feedback == As this is the second iteration of such a proposal, we've gathered a lot of feedback from various sources during the first attempt to accept this change. === FESCo inputs === A [https://pagure.io/fesco/issue/3039 ticket] discussing the reasons why the contingency mechanism was invoked for the first attempt of the proposal was opened by FESCo. It includes a list of items that are either incomplete or in progress. Below is a list of issues from the ticket that are still unresolved or require clarification on their current status. Other items not mentioned below are considered completed. Switch in ELN This should not block the proposal, as the current plan is to target RHEL 11. Integration can occur there after the proposal is implemented for Fedora 41. Aligning configuration with the current state in dnf All overrides to match the current state of dnf configuration will be provided to the Fedora release project, see [[#Apply downstream configuration overrides|below]]. System upgrade and offline transactions The implementation work has been completed and is already present upstream. We anticipate extensive testing during the summer, and we also plan to organize testing days for this purpose. Dropping the Snapper plugin In dnf5, we've adopted a new approach for implementing functionality that was previously handled by the Snapper plugin in dnf. We're introducing the Actions plugin, which offers more capabilities than the Snapper plugin, including support for running external applications before or after transactions and interacting with the dnf5 configuration.
F41 Change Proposal: RPM 4.20 (System-Wide)
Wiki - https://fedoraproject.org/wiki/Changes/RPM-4.20 == Summary == Update RPM to the up coming [https://rpm.org/wiki/Releases/4.20.0 4.20] release. == Owner == * Name: [[User:ffesti| Florian Festi]] * Email: ffe...@redhat.com == Detailed Description == RPM 4.20 contains various improvements over previous versions. * Hands-free packaging ** [https://github.com/rpm-software-management/rpm/issues/1087 Declarative build system] ** Dynamic spec generation extended ** [https://github.com/orgs/rpm-software-management/projects/16/views/1 File trigger scriptlet arguments] ** [https://github.com/rpm-software-management/rpm/issues/782 Support for spec local dependency generators] ** [https://github.com/rpm-software-management/rpm/issues/2816 Support for sysusers 'm' directive] ** [https://github.com/rpm-software-management/rpm/issues/2078 Guaranteed per-build directory] * [https://github.com/rpm-software-management/rpm/issues/1536 Public plugin API] * Increased install scriptlet isolation ([https://github.com/rpm-software-management/rpm/issues/2632 #2632], [https://github.com/rpm-software-management/rpm/issues/2665 #2665]) The 4.20 alpha release is expected in late March/early April and the final release is expected in time for the Fedora 41 release cycle as usual. == Feedback == == Benefit to Fedora == This release comes with many improvements. It opens the possibility for Fedora to adopt the new major features mentioned above. == Scope == * Proposal owners: ** Release RPM 4.20 alpha ** Rebase RPM in rawhide ** Assist with dealing with incompatibilities * Other developers: ** Test new release, report issues and bugs * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: None == Upgrade/compatibility impact == == How To Test == Rpm receives a thorough and constant testing via every single package build, system installs and updates. New features can be tested specifically as per their documentation. == User Experience == There are no major differences in the normal user experience. == Dependencies == == Contingency Plan == * Contingency mechanism: Revert back to RPM 4.19 * Contingency deadline: Beta freeze * Blocks release? No == Documentation == Release notes at https://rpm.org/wiki/Releases/4.20.0 (still tbd) and reference manual at https://rpm-software-management.github.io/rpm/manual/ == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
