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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
