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#)