comps packagereq items default to "mandatory"

[Kevin Kofler]

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