Wiki - https://fedoraproject.org/wiki/Changes/Switch_Anaconda_installer_to_DNF5
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-switch-anaconda-installer-to-dnf5-self-contained/155253
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.
== Summary ==
Switch Anaconda installer to use DNF 5 instead of DNF 4 for RPM
package installation.
== Owner ==
* Name: [[User:m4rtink| Martin Kolman]]
* Email: mkolman@redhat.com
* Name: Pavla Kratochvílová
* Email: pkratoch@redhat.com
== 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.
* 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 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:
* many [https://github.com/rhinstaller/kickstart-tests kickstart-tests]
* quite a few [https://openqa.fedoraproject.org/ OpenQA tests]
maintained by FedoraQA
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
[https://matrix.to/#/#anaconda:fedora.im 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:
<pre>
# 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
</pre>
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
[https://weldr.io/lorax/mkksiso.html 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 ==
--
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-leave@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
No comments:
Post a Comment