When installing Fedora Rawhide / Fedora 44 KDE Desktop Environment from the Everything (netinstall) image, no web browser is installed. Specifically, Firefox is missing from the installed system and does not appear in the KDE application launcher (Internet category). This happens despite the fact that: firefox is present in the image manifest kde-desktop-environment comps definition includes firefox as an optional group with default="true" KDE Live ISO images explicitly install Firefox and are unaffected The issue appears only when using Anaconda + Everything image, not the KDE Live image. Based on investigation, this is likely caused by DNF5 ignoring default optional groups in comps, which became user-visible once Anaconda switched to DNF5 for package resolution. Component plasma-desktop (possibly also anaconda or dnf5, but root cause not yet confirmed) Release Fedora Rawhide (20260204 nightly) Likely Fedora 44 (branching in progress) Severity Medium (Core desktop functionality missing, but workaround exists) Reproducible: Always Steps to Reproduce: 1. Boot Fedora Rawhide / Fedora 44 Everything installer (netinstall) 2. Choose KDE Plasma Desktop Environment 3. Complete installation with default selections 4. Boot into the installed system 5. Open the application launcher → Internet alternatively, install Fedora using the attached kickstart. Actual Results: No web browser is installed. Firefox is not present in the system or launcher. Expected Results: Firefox should be installed by default when KDE Desktop Environment is selected. Default optional comps groups (e.g. firefox) should be honored Additional Information: 1. kde-desktop-environment comps entry includes: <groupid default="true">firefox</groupid> 2. KDE Live images explicitly install Firefox as a workaround and are unaffected. The problem is reproducible by: Taking the KDE createhdds kickstart, removing the explicit @firefox group which results in image lacking a browser DNF5 probably ignores default optional groups in comps definitions, which is incorrect behavior and leads to broken desktop defaults when used by Anaconda.
Created attachment 2128272 [details] KDE kickstart file to reproduce the issue
Adding Anaconda folks to this BZ.
This handling of optional groups was recently discussed, probably on Fedora devel mailing list, and the conclusion was that DNF5 and Anaconda work as designed and that spins should stop using optional groups. The explanation was that optional is meant for opt-in groups and that Anaconda intentionally lost functionality of selecting optional groups. I.e. spins which wants something to be installed by default needs to make it a hard member of the group.
It was this thread <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/5VRAE67CISKUW2X3J2XIWBV4CG6KUMRR/#JW6ZGBG756NKASYRGFZ2GBORWQPT55RP>.
(In reply to Petr Pisar from comment #3) > This handling of optional groups was recently discussed, probably on Fedora > devel mailing list, and the conclusion was that DNF5 and Anaconda work as > designed and that spins should stop using optional groups. The explanation > was that optional is meant for opt-in groups and that Anaconda intentionally > lost functionality of selecting optional groups. I.e. spins which wants > something to be installed by default needs to make it a hard member of the > group. That is not the conclusion that was drawn. There was hardly a discussion about that. And also, this conclusion breaks core functionality about environment groups in the first place.
(In reply to Petr Pisar from comment #4) > It was this thread > <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ > thread/5VRAE67CISKUW2X3J2XIWBV4CG6KUMRR/#JW6ZGBG756NKASYRGFZ2GBORWQPT55RP>. This thread talks about optional _packages_ in groups, not optional _groups_ set in environment and category groups. Those are two different things. Furthermore, optional entries with default yes basically map to Recommends just like "default" does, with the difference that if you didn't install them, then system upgrade doesn't force it to be installed when upgrading.
DNF uses the `group_package_types` configuration option even for environments (but only the presence of the "optional" value has effect). The upstream default is "default, mandatory, conditional", so optional packages and optional groups are not installed by default. This could be fixed in Anaconda by setting the `group_package_types` individually for each environment spec when adding it to the goal. A better approach would be to introduce an option for environments to allow different setting than for groups and configure it in Anaconda for all environments (except when specified otherwise), however, if a fix should be delivered quickly and we really want to install optional groups by default, I suggest to add the workaround into Anaconda first, as it will be much easier to implement (call `settings.set_group_package_types` in `DNFManager.apply_specs` for all environment specs without defined types).
This regression was introduced during the conversion of the Anaconda payload codebase to the DNF5 API. Aside of the issue mentioned in the report, it also caused an incorrect set of pre-selected packages to be shown in the GTK UI. For example, Firefox appeared as pre-selected in Fedora 42, but it is not pre-selected in the current release.
Created attachment 2129691 [details] KDE Fedora 42 installer
Pavla: thanks for the suggestion. Setting group_package_types with optional per environment would install all optional groups from the optionlist. We need to install by default (and pre-select in UI) only the ones with default="true" in <optionlist> (e.g. firefox), not every optional group (e.g. kde-education). Does libdnf5 expose if an optional group is marked with default (optionlist’s default attribute)?
Thanks for the insight, Katerina, I didn't know about the "default" attribute in "<optionlist>". You are right, dnf ignores it and it's not even considered by libsolv which dnf5 uses to read the comps xml. Therefore, a patch in libsolv is needed to take the "default" attribute into account and probably store the default="true" solvable as "recommends" ("requires" is for groups in the grouplist, "suggests" would be for groups in the optionlist without default="true"). And then a patch in dnf5 is needed to distinguish between optional and default groups in environments and to allow installation of default groups by default. We could later introduce an option to configure which group types should be installed, but it's not necessary to fix this bug. I will prepare the patches in libsolv and dnf5 and then we should check whether also something on the interface between dnf5 and Anacoda is needed for this to work properly.
libsolv PR: https://github.com/openSUSE/libsolv/pull/607 dnf5 PR: https://github.com/rpm-software-management/dnf5/pull/2633 With the dnf5 patch, dnf installs also default groups from environments. I tried running Anaconda with and without the patch and installing kde-desktop-environment installs the firefox group only with the patch.
FEDORA-2026-7f8c20f800 (dnf5-5.4.1.0-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-7f8c20f800
Proposed as a Freeze Exception for 44-final by Fedora user pkratoch using the blocker tracking app because: Without the fix for this bug, the Anaconda won't install default groups from environments, which is a regression from previous behavior.
We really appreciate the fix for this and for https://bugzilla.redhat.com/show_bug.cgi?id=2457408 , but sending an update with a whole new version leaves us with a dilemma. There are a lot of commits upstream between 5.4.0.0 and 5.4.1.0 (96; skipping doc-only and translation commits, about 80). That's a lot of change to land in one of the most vital system components during a freeze. It *is* policy that updates to fix FE/blocker bugs should include *only* the FE/blocker fixes, as closely as possible. We have been somewhat lax in enforcing this lately but in a case like this it does seem important. Unfortunately since the rebase build and update have been done now, it's a bit more complicated to do a backport-only build. But if you don't mind me doing a git revert I think I'd like to try doing that.
+3 in https://pagure.io/fedora-qa/blocker-review/issue/2114 , marking accepted FE. On the whole I think it might be worth trying an RC with the version update today...if problems show up in early testing we still have time to back it out.
FEDORA-2026-7f8c20f800 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-7f8c20f800` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-7f8c20f800 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
This bug fix is quite invasive for a backport. It's unfortunate that new upstream release and approval for FE came at the same time. I'd rather not to revert the the rebase, backport this and that and rebase again.
FEDORA-2026-7f8c20f800 (dnf5-5.4.1.0-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.