Fedora 22 is out, Fedora 23 is coming :)

[Josh Boyer]

On Thu, Jun 11, 2015 at 1:12 PM, Matthew Miller
<mattdm at fedoraproject.org> wrote:
> On Thu, Jun 11, 2015 at 12:53:42PM -0400, Josh Boyer wrote:
>> You can get around this with on-the-fly image generation as I
>> previously mentioned, or by creating a small (and I mean small in
>> number not size) set of images that are flexible enough to hit the
>> major categories while not being strictly tied 1:1 to a particular
>> technology.  E.g. you have a "Cloud Container image" that can be used
>> for Docker, rkt, or systemd-nspawn.  Yes, that makes it potentially
>> larger in size but it also means you have less to QA, market, and
>> carry.
>
> The bitnami link I sent before was probably a bit broad; our previous
> dicussions were more around something like this:
> <https://bitnami.com/stacks/infrastructure> -- which I think matches
> what you are saying. And I *do* think it'd be nice to have an
> "app store" built on top of that. First, though, the Cloud Base image,
> which is intended to underly all of that (and also be, as we have said,
> a generic platform to build up anything).
>
> Size _does_ matter, though, because it translates directly into network
> transfer and deploy time. Python is in the crosshairs because it's
> relatively large. In fact, with your kernel-core stuff and the glibc
> documentation split, it's the biggest thing (coming in just above
> systemd).

I didn't say size doesn't matter.  I'm saying I don't believe cutting
python just because it is big is the right choice.  We're probably
going to have to disagree on this point.

> Well, and linux-firmware, which isn't needed at runtime but is pulled
> in for kernel upgrades, and which to my knowledge is not needed in any
> cloud environments. You might be the right person to talk to about
> figuring out if we can do anything about this.

A post install scriptlet that removes the files in the cloud
kickstarts is about as far as I'm going to go.  I'm not dropping the
Requires from the kernel-core package and leave everyone else in the
lurch.  Another option would be a dummy package that Provides
linux-firmware, but that also runs the risk of non-cloud instances
getting it installed since we don't have separate repos.

(The third "option" is a separate cloud kernel package but that would
make the rework we did in f22 pointless and wasted and we've already
had that discussion.)

josh