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#)
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
