On Fri, 2014-10-03 at 14:29 -0400, Paul W. Frields wrote:

On Mon, Sep 29, 2014 at 06:25:46PM -0700, Adam Williamson wrote:

...

Hi, folks. I'm checking the release criteria again for Fedora.next compatibility, and there's an Alpha criterion with obvious issues:

"Package sets

When doing a graphical install using the dedicated installer images, the installer must be able to install each of the release blocking desktops, as well as the minimal package set. "

This was obviously written to the world where we had generic installer images - the DVD, and intentionally-generic netinsts. We do not have those things any more.

Do we want to dump this criterion entirely, or is there any of it we would like to keep? For instance, would we consider it 'release blocking' functionality for you to be able to do some/any of the above from the Server and/or Workstation network install images *after configuring the repos manually*? Particularly, the minimal installation? I'm not sure F21 as currently conceived would offer an avenue for doing an interactive minimal installation.

Basically, it comes down to: do we want to have a blessed method for doing a network install of KDE and/or minimal? If so, do we want to block releases on it?

Correct me if I'm wrong, but doesn't the WS-specific netinst.iso allow you to install the standard Workstation product, among other things? I think I booted it the other day while redoing an installation, and saw multiple products available. I don't recall seeing Minimal but I didn't look specifically for it.

Sorry for the belated reply, but it's a good opportunity to try and re-start this question.

At the time you wrote the mail, and indeed currently, the WS and Server netinsts in fact act as 'universal' network install images - but this is not per design, it's a bug.

Insofar as there was a design, it was to 'Product'-ize the network install images - have them offer only the environment group that matches the Product, and its option groups, by default. No-one really did the work ahead of time to find out if that was actually feasible, though, and what we found out at Alpha time is that it is rather difficult to achieve with our current image generation process and anaconda behaviour.

The bug tracking this is https://bugzilla.redhat.com/show_bug.cgi?id=1134524 .

As things stand, if no-one does anything, the Product network install images for 21 Beta will also be 'universal'. No-one, AFAICT, has even taken a swing at solving the issues that prevent them being Product-ized yet.

Funnily enough, so long as the network install images continue to act as 'universal' images, we can continue to use the existing release criterion, I guess. Not sure whether it's appropriate, but it is at least valid.

Before anyone asks, it is also not trivial to just ship a single 'universal' network install image. Traditional install media are built out of product trees. Pre-F21, the netinst.iso image was built in the 'Fedora' tree - https://dl.fedoraproject.org/pub/fedora/linux/releases/20/Fedora/ , for e.g. . That tree was populated with all the bits necessary to build the 'Fedora DVD' - the bits specified in fedora-install-fedora.ks . The packages in that tree are all the packages on the DVD. The netinst.iso was simply the DVD ISO without all the packages.

In a Product-y world, we don't have a Fedora/ tree any more. We don't have anywhere logical to build a single 'officially universal' network install image. We have these trees:

https://dl.fedoraproject.org/pub/fedora/linux/releases/test/21-Alpha/

with installer images built in Server/ and Workstation/ . It gets messy if we try and yank the network install image out of one of those trees after creation and stick it somewhere else. (And of course the Product-y network install images are *branded* with their Product name, even though there's really nothing very Product-y about them at all).

One option if we just wanted to go with a single 'universal' netinst image is to build it out of Everything/ , but then (AIUI - dgilmore may correct me) the downside would be it'd make the compose process even longer.