I realized this morning that we never actually came to a resolution on
the plans for reducing the package set in Fedora 24 (it's too late
to make changes for Fedora 23).
The set of package groups that are installed by default for Fedora
* Hardware and virtualization guest support
* @server-product (individual packages we've decided we need, like
* @headless-management (cockpit, openssh, rolekit, tog-pegasus)
* @container-management (Docker)
* @domain-client (realmd, freeipa-client, winbind)
The complete selection of available packages on the Server DVD is
much larger and basically includes everything from the "Infrastructure
Server" environment group on the old DVD, most of which is probably
*not* useful on the install media, in my opinion.
I'd like to propose that we make one of the following changes for
Option A) Remove everything from the DVD that isn't part of the
default installation, then add back in individual options that have
Option B) Remove everything from the DVD that isn't part of the
default installation or one of the supported rolekit roles, then add
back in individual options that have demonstrable value.
From the discussion on the mailing list, the most common argument was
"But what about disconnected operation?", but the fact of the matter
seemed to be that even with our current large (and eclectic) package
set, there are still packages that some people want that aren't on the
image. Since this set varies wildly between deployments, I personally
don't feel that it makes sense to try to accommodate all of this on
the image. Instead, I think we should be more straight-up in defining
that the DVD ISO carries the Fedora Server Operating System and that
add-on capabilities require a network repository (local or internet).
If we go with either of these choices, I'm personally more highly in
favor of Option A) than Option B). The mechanism for rolekit involves
always grabbing the latest stable version of the roles from the
network anyway, so carrying them on the disk is of limited use outside
of the completely disconnected case. See also my original email on
the subject for how avoiding these on the images can also help us
avoid release slippage in some situations.
 This was in place to support OpenLMI, but we're not actually doing
this, so we should probably drop it.