F43 Change Proposal: Switch Anaconda installer to DNF5 (self-contained)

Project Discussion Change Proposals
,
1

Switch Anaconda installer to DNF5

This is a proposed Change for Fedora Linux.
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.

Wiki
Announced

:link: Summary

Switch Anaconda installer to use DNF 5 instead of DNF 4 for RPM package installation.

:link: Owner

:link: Detailed Description

When installing Fedora from RPM packages (which is the default for most current Fedora netinst and DVD images) Anaconda still uses DNF 4, while Fedora already switched to DNF 5 for general package management and image builds around Fedora 41. It’s time to switch also Anaconda to DNF 5 to keep the installation behavior consistent with the rest of Fedora and to avoid depending on the DNF 4 codebase that is effectively in maintenance mode now.

:link: Feedback

While we expect the change to be effectively invisible for users, if you have any questions or concerns or feedback, please reach out to the Anaconda team on our Fedora Matrix channel: https://matrix.to/#/#anaconda:fedora.im

:link: Benefit to Fedora

By switching Anaconda to DNF 5 we will be able to better support and debug package based applications due to DNF 5 being in active development & Anaconda will not block the future deprecation or removal of DNF 4.

:link: Scope

  • Proposal owners: Switch the Anaconda codebase to use DNF 5 instead of DNF 4.

  • Other developers: We don’t expect changes affecting other Fedora developers.

  • Release engineering: #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

:link: Upgrade/compatibility impact

There is no upgrade/compatibility impact.

:link: How To Test

We will of course only merge and release this change after the CI covering Anaconda passes, with quite a few tests covering the package installation related aspects:

If you want to help with testing or check if your use case is still working as expected, do a manual or kickstart based installation from a boot.iso and check if all goes well.

If possible try to use some of the more advanced features available via the %packages section in kickstart to really stress test the new code.

There will also be a “DNF 5 Anaconda” test day scheduled, where you can help us make sure various scenarios are still working as expected, with team members being available on our Fedora Matrix channel to answer questions and provide support.

We have prepared an example kickstart file you can use and customize for testing packaging and thus DNF 5 in Anaconda:

# what we are testing there: # - that we can exclude groups which are a part of an environment # - that we can exclude groups we have specified in ourselves # (this could be important for multiple ksincluded %packages sections) # - that the --optional flag for package groups is working # - that the --nodefaults flag for package groups is working # Default Fedora Rawhide repositories url --url http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/ # shutdown at the end shutdown # network network --bootproto=dhcp # storage & bootloader bootloader --timeout=1 zerombr clearpart --all autopart # l10n keyboard us lang en timezone America/New_York # user confguration rootpw testcase %packages # (1) Test that you can remove a group that's part of an environment. @^xfce-desktop-environment -@dial-up # (2) Test that you can add and then remove a group. @3d-printing -@3d-printing # (3) Test that --optional works. @container-management --optional # (4) Test that --nodefaults works. @rpm-development-tools --nodefaults %end %post # We don't have a way of determining if a group/env is installed or not. # These sentinel packages will have to do. # Testing #1 - lrzsz is only part of dial-up, and should not be installed. rpm -q lrzsz if [[ $? == 0 ]]; then echo '*** dial-up group should not have been installed' >> /root/RESULT fi # Testing #2 - meshlab is only part of 3d-printing, and should not # be installed. rpm -q meshlab if [[ $? == 0 ]]; then echo '*** 3d-printing group should not have been installed' >> /root/RESULT fi # Testing #3 - buildah, podman, origin-clients are optional part of container-management, # so should be installed when the --optional flag is passed for the group spec rpm -q buildah if [[ $? != 0 ]]; then echo '*** buildah was not installed for @container-management --optional' >> /root/RESULT fi rpm -q podman if [[ $? != 0 ]]; then echo '*** podman was not installed for @container-management --optional' >> /root/RESULT fi # Testing #4 - rpm-build is mandatory so it should be installed. rpmdevtools is # default so it should not. rpmlint is optional so it should not. rpm -q rpm-build if [[ $? != 0 ]]; then echo '*** Mandatory package from rpm-development-tools was not installed' >> /root/RESULT else rpm -q rpmdevtools if [[ $? == 0 ]]; then echo '*** Default package from rpm-development-tools should not have been installed' >> /root/RESULT else rpm -q rpmlint if [[ $? == 0 ]]; then echo '*** Optional package from rpm-development-tools should not have been installed' >> /root/RESULT fi fi fi # Report success if no errors have been reported to /root/RESULT if [ ! -f /root/RESULT ] then # no result file (no errors) -> success echo SUCCESS > /root/RESULT else # some errors happened exit 1 fi %end

There is even some simple validation built in, that should result in “SUCCESS” being written into the /root/RESULT on the installed system if all goes well - or an error message if something failed. You can login as “root” with the password of “testcase” to check the file.

To easily run a kickstart installation, consider using the mkksiso tool with the –ks flag. Then booting the modified boot.iso should be sufficient, without the need to manually edit the boot options to load the kickstart.

:link: User Experience

There shouldn’t be any user observable change for package based installation.

:link: Dependencies

None.

:link: Contingency Plan

  • Contingency mechanism: If we encounter blocking issues that can’t be fixed in time, Anaconda will keep using DNF 4 in Fedora 43.
  • Contingency deadline: 100% Code Completion deadline for Fedora 43 on Tue 2025-08-26
  • Blocks release? No

:link: Documentation

N/A (not a System Wide Change)

:link: Release Notes

Last edited by @amoloney 2025-06-07T13:15:39Z

Last edited by @amoloney 2025-06-07T13:15:39Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

This change proposal has now been submitted to FESCo with ticket #3427 for voting.

To find out more, please visit our Changes Policy documentation.