From Fedora Project Wiki


Switch Anaconda installer to DNF5

Summary

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

Owner

  • Name: Martin Kolman
  • Email: mkolman@redhat.com
  • Name: Pavla Kratochvílová
  • Email: pkratoch@redhat.com


Current status

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.

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


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.

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.
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy:

Upgrade/compatibility impact

There is no upgrade/compatibility impact.


Early Testing (Optional)

Do you require 'QA Blueprint' support? Y/N

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.



User Experience

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

Dependencies

None.


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


Documentation

N/A (not a System Wide Change)

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/Switch_Anaconda_installer_to_DNF5&oldid=743573"