RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

[Richard W.M. Jones]

On Mon, Jul 22, 2013 at 09:38:54AM -0400, Matthew Miller wrote:
>   * E.g.: Everything in @standard, plus the toolchains to build it

How about, like RHEL, the "toolchains to build it" goes into an
RHEL-Optional-like separate place?  If it has to be in the core ring
then either the core ring has to be really big with compilers and
language runtimes and stuff; or we have big arguments about whether
{Perl,Ruby,other specialized language/tool} can be used to implement
core components.

>   Ring Zero: Fedora Minimal
>   ---
[...]
> This is pretty self-explanatory.  There is a lot of demand and many
> use cases for a "Just Enough Fedora" operating system. Ring 0 exists
> to provide that in a serious way which Fedora has never really
> covered before.

Perhaps self-explanatory for you, but not for me!  What are the actual
stated goals for this that are different from the small @standard
ring?

>   * Start from the current @core, and aim to shrink

Aim to shrink ... to what?  Nothing?

>   * Intentional focus on minimalism 

You don't *need* bash if you have a way to upload a binary, because
everything can be done by uploading a binary.  So maybe the minimal
thing is kernel + scp + a port of CP/M's CCP (I'm trying to perform a
reductio ad absurdum on this ...)

>   What's a Ring?
>   ---
>   * Rings give SIGs a way to replace the default expectations with their own
>   * Separate policies may apply to each ring
>   * But also, also, we need community, policies, and infrastructure to make
>     them _part of Fedora_

Is a ring also a yum repo?  If so, how do you express dependencies
between these new repos?  eg. My package needs OCaml and Perl 5 to
build, so I want those [repos?] as dependencies.

I'm having difficulty understanding the nuts and bolts of how this
will work, especially when you say "Not necessarily even RPM".

> Some approaches may even move beyond RPM packaging. This can mean focusing
> on "language native" package formats like Jars, Gems, and Eggs; or it can
> mean moving to a Git-based distribution model for some parts of the distro.

I suspect this would be better if we made it much easier to automate
"cpan2spec"-style mass importing of packages to RPM.  So that, for
example, you didn't need to separately review every single perl-*
package that comes from CPAN, or every single rubygem.  (The obvious
downside is that Fedora or Someone is going to be shipping an awful
lot of dodgy, insecure, illegally-licensed software because all the
checks we usually do to keep that out of the distro will be bypassed.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)