(Add link to releng issue) |
(Finalize for wrangler) |
||
| Line 1: | Line 1: | ||
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | <!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> | ||
= | = Build Fedora with DNF 5 <!-- The name of your change proposal --> = | ||
{{Change_Proposal_Banner}} | {{Change_Proposal_Banner}} | ||
| Line 26: | Line 26: | ||
== Current status == | == Current status == | ||
[[Category: | [[Category:ChangeReadyForWrangler]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
| Line 167: | Line 167: | ||
<!-- 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?) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Contingency mechanism: (What to do? Who will do it?) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Revert the F40 Mock configuration in Koji and Copr back to using `dnf`. | Revert the F40 Mock configuration in Koji and Copr back to using `dnf` (5-minute work). | ||
<!-- 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: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Contingency deadline: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
Revision as of 13:28, 23 October 2023
Build Fedora with DNF 5
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
We are proposing to change the Mock configuration in Mock (mock-core-configs), Koji, and Copr to use DNF 5 as Mock's package manager instead of DNF 4. DNF 5 would be used by Mock to install build dependencies into chroots for package builds. This change is related to the build infrastructure and is distinct from changing the default package manager in Fedora.
Owner
- Name: Evan Goode
- Email: egoode@redhat.com
- Name: Pavel Raiskup
- Email: praiskup@redhat.com
Current status
- Targeted release: Fedora Linux 40
- Last updated: 2023-10-23
- [<will be assigned by the Wrangler> devel thread]
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
DNF 5 is a new package manager intended to replace DNF: https://dnf5.readthedocs.io/en/latest/about.html. It offers significant performance improvements over DNF while achieving lower memory usage and disk footprint. The switch to DNF 5 was originally planned for Fedora 39, but it's been postponed to (likely) Fedora 41: https://pagure.io/fesco/issue/3039.
In the meantime, we would like to start building Fedora with DNF 5. The set of package management features that Mock needs for setting up buildroots is small compared to the full capabilities of DNF, so it's a good place to start deploying DNF 5. We will be able to test the stability of DNF 5 at a large scale and gather data about its performance.
The Mock developers have been working alongside the DNF 5 developers for a while to ensure Mock can use DNF 5, per this tracking issue: https://github.com/rpm-software-management/mock/issues/894. The two remaining items on that issue are "optional" items that are not blocking this proposed change.
Feedback
Benefit to Fedora
With the switch to DNF 5 as the default package manager on the horizon, the build infrastructure offers an opportunity to subject a crucial subset of DNF 5's features to heavy testing. This change will let us verify that every build dependency in the distribution is installable by DNF 5.
In addition, we expect a substantial performance improvement for package builds that spend a significant portion of their time installing build dependencies. Larger, compilation-heavy packages likely won't see much improvement; the difference will be most apparent when building many smaller packages. Switching the build system over to DNF 5 will let us measure the performance improvement over DNF across a wide variety of install transactions.
Scope
- Proposal owners:
The work to support DNF 5 in Mock is done already. This change should be as simple as setting the Mock option config_opts['package_manager'] = 'dnf5' in Mock, Koji, and Copr for F40+ builds (Koji config option exists from the yum -> dnf4 era). The dnf5 doesn't necessarily have to be installed on building hosts - in such a case, Mock will automatically use /bin/dnf-3 (DNF4) from the host to install DNF5 into the bootstrap chroot, to further use *that* DNF5 for build chroot installation.
- Other developers:
- Release engineering: https://pagure.io/releng/issue/11737
- Policies and guidelines: N/A (not needed for this Change)
- Trademark approval: N/A (not needed for this Change)
- Alignment with Community Initiatives:
Upgrade/compatibility impact
How To Test
There are no special steps needed to test the change after it happens (updated mock-core-configs package is installed on your host), just enjoy the installation speedup.
There's a way to test this on Fedora 37+ or EPEL8+ host (builder) in advance. Considering you want to build SRCRPM like mock -r fedora-40-x86_64 your.src.rpm, you can do this instead:
1. mock -r fedora-40-x86_64 --scrub=all (mandatory step to cleanup DNF4 from all caches)
2. mock -r fedora-40-x86_64 --config-opts=package_manager=dnf5 your.src.rpm (DNF5 is installed and cached in bootstrap)
3. mock -r fedora-40-x86_64 --scrub=all (to invalidate caches again)
User Experience
This change will mostly be invisible to users. The builds, namely the buildroot preparation, will be much faster.
Dependencies
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?)
Revert the F40 Mock configuration in Koji and Copr back to using dnf (5-minute work).
- Contingency deadline:
F40 Beta freeze
- Blocks release? Yes