I'm not sure that this is common knowledge as it is not specifically mentioned in either:
https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_gro...
or
https://fedorahosted.org/comps/
that the default type for packagereq is "mandatory". As a result I believe that there are a *large* number of packages listed in comps that are inadvertently being marked as "mandatory", e.g.:
<group> <id>standard</id> <_name>Standard</_name> <_description>Common set of utilities that extend the minimal installation.</_description> <default>false</default> <uservisible>false</uservisible> <packagelist> <packagereq>abrt-cli</packagereq> <packagereq>acl</packagereq> <packagereq>at</packagereq> <packagereq>attr</packagereq> <packagereq>bash-completion</packagereq> ....
<group> <id>kde-desktop</id> <_name>KDE</_name> <_description>The KDE Plasma Workspaces, a highly-configurable graphical user interface which includes a panel, desktop, system icons and desktop widgets, and many powerful KDE applications.</_description> <default>false</default> <uservisible>false</uservisible> <packagelist> <packagereq>abrt-desktop</packagereq> <packagereq>adwaita-gtk2-theme</packagereq> <packagereq>akonadi</packagereq> <packagereq>akonadi-mysql</packagereq> <packagereq>akregator</packagereq> <packagereq>apper</packagereq> ...
Almost none of those appear to be "Mandatory".
We think this is becoming an issue now because it appears that dnf perhaps now prevents kickstart installs from removing mandatory packages from the install set. See https://bugzilla.redhat.com/show_bug.cgi?id=1199868 and the good detective work done by Adam Williamson for more background.
So, it seems we can either (perhaps) go back to the previous behavior, and/or fix comps. We may want to fix comps anyways as I expect this has UI effects as well (perhaps cannot deselect packages after selecting a group?).
Orion Poplawski (orion@cora.nwra.com) said:
Almost none of those appear to be "Mandatory".
We think this is becoming an issue now because it appears that dnf perhaps now prevents kickstart installs from removing mandatory packages from the install set. See https://bugzilla.redhat.com/show_bug.cgi?id=1199868 and the good detective work done by Adam Williamson for more background.
So, it seems we can either (perhaps) go back to the previous behavior, and/or fix comps. We may want to fix comps anyways as I expect this has UI effects as well (perhaps cannot deselect packages after selecting a group?).
Unless something has changed (possible, haven't been playing close attention), there's no individual package selection for groups, so there are no UI effects.
Historical info:
This was generally intentional - the group is intended to define a specific set of packages that would be ensured to be there if that group was installed. Optional selections are for groups which only have optional packages, or optional groups that would be selected for particular environments.
That can always be revisited, but the initial premise was that groups of that form that are specified as they are in comps now weren't supposed to be modifyable in that way. (Even if yum-based anaconda let you do it in kickstart.)
Bill
Bill Nottingham wrote:
Unless something has changed (possible, haven't been playing close attention), there's no individual package selection for groups, so there are no UI effects.
There are post-install UI effects, especially since the "groups as objects" misfeature. Yum (and I suppose dnf) keeps track of what groups are installed. If you remove any of the "mandatory" packages, you also have to "remove the group", i.e. remove the flag that says the group is installed.
Historical info:
This was generally intentional - the group is intended to define a specific set of packages that would be ensured to be there if that group was installed. Optional selections are for groups which only have optional packages, or optional groups that would be selected for particular environments.
You made those changes unilaterally without even talking to the people who carefully defined the mandatory, default and optional packages for their groups (also based on the false premise that the tags had no effect anymore (after the package selector was removed from Anaconda), which is simply not true, see above). You simply trashed all our work, and now it has to be carefully resurrected and updated. (In fact, for several groups, people have done exactly that, but a lot of groups are still broken.)
A package in a group should almost NEVER be mandatory. Only if it really is integral to the group (say, plasma-desktop to @kde-desktop), then it makes sense to be defined as mandatory. But in almost ALL cases, the packages should be at most "default", NOT mandatory. For example, it makes no sense whatsoever to not be able to remove an image viewer such as gwenview without removing all of @kde-desktop. (I've been wanting to clean this up at least for @kde-desktop for a while (as soon as I had noticed the regression), but somehow forgot about it.) Or even some NON-KDE applications that are listed in @kde-desktop (as mandatory!) for some stupid reason (such as firewall- config). (IMHO, the non-KDE config tools don't belong under @kde-desktop AT ALL, but in the spin kickstart. They have nothing to do with KDE. Rex Dieter added those to @kde-desktop despite my objections. But at the very least, they should not be mandatory.)
That can always be revisited, but the initial premise was that groups of that form that are specified as they are in comps now weren't supposed to be modifyable in that way. (Even if yum-based anaconda let you do it in kickstart.)
That is not a workable premise. There is a lot of "mandatory" stuff throughout all groups that has no business being mandatory. For example, the KDE spin kickstart needs to be able to opt out of the admin tools for which there is a KDE replacement.
Kevin Kofler