Fedora Ring 0 definition

[Simo Sorce]

On Wed, 2015-09-02 at 13:57 -0700, Brendan Conoboy wrote:
> On 09/02/2015 12:47 PM, Simo Sorce wrote:
> > On Wed, 2015-09-02 at 15:31 -0400, Matthew Miller wrote:
> >> On Wed, Sep 02, 2015 at 11:59:55AM -0700, Brendan Conoboy wrote:
> >>> Re-sending this with a better title so people might read it ;-)
> >>
> >> Yes, thanks -- I admit to having skimmed over it in my mail-catchup
> >> attempt.
> >>
> >>>> especially how the rings interact.  As a side note, everyone agreed
> >>>> the word "rings" breaks down the further you get away from the center,
> >>>> but nobody has come up with something better yet (Venns? Blobs?
> >>>> Zones?).
> >>
> >> If people aren't gonna want to rename Rawhide to Bikeshed, then maybe
> >> *this* could be called that. :)
> >>
> >>>> Right now the Fedora distribution is 1 ring, let's call it ring 1. The
> >>>> distribution contains an operating system and numerous applications
> >>>> that run on that operating system.  When we talk about defining ring 0
> >>>> we're really talking about distinguishing between the operating system
> >>>> and the applications that run on top of it.
> >>
> >> Speaking of bikesheds... we've traditionally defined the Fedora
> >> operating system as *the whole thing*, so now calling a subset of that
> >> the OS gives plenty of room for quibbling. I'm hoping to forestall that
> >> by saying that regardless of that, we all know what you mean here. That
> >> may be optimistic.
> >>
> >>
> >>>> We want to go from this:
> >>>> Ring 1: The Fedora Distribution
> >>>> To this:
> >>>>
> >>>> The Fedora Distribution:
> >>>> Ring 0: The Linux Operating System
> >>>> Ring 1: The Applications and Stacks
> >>>>
> >>>> It seems quite modest, but working through the details on what this
> >>>> means is hard.  What is an operating system in the Linux context? Ring
> >>>> 0 will likely have the strictest set of policies of all the rings, so
> >>>> we want to keep it as small as possible, but it is more than a minimal
> >>>> install.  These are the traits of rings in general and ring 0 in
> >>>> particular as I see it:
> >>>>
> >>>> 1. Ring 0 is a repository of rpm packages built in koji.
> >>>>
> >>>> 2. Ring 0 contains, but is not limited to, the minimal install of
> >>>> packages to go from Power On to a login prompt.
> >>
> >> In my conception, the "is limited to" set was Ring 0, and the thing you
> >> are calling Ring 0 was Ring 1, and then Envs and Stacks was Ring 2. I
> >> can live with ajusting things; just noting. For the rest of this
> >> message I will use your levels.
> >>
> >>>> 3. Ring 0 passes repoclosure on its own (Packages listed as hard
> >>>> "Requires" in a ring 0 spec file are themselves are implicitly ring 0).
> >>
> >> *nod*
> >>
> >>>> 4. Ring 0 is not self hosting.  Packages listed in "BuildRequires" do
> >>>> not need to be members of Ring 1.  This isn't ideal, but it's a
> >>>> practical consideration.
> >>
> >> When you say Ring 1 here, you mean Ring 0, right?
> >>
> >>
> >>>> 5. Ring membership is at the source package level, not the binary
> >>>> package.  If one source package's binary/noarch sub-package is in ring
> >>>> 0, all sub-packages are in ring 0.
> >>
> >> Hmmmm. Are we sure about that? That means that one can't, for example,
> >> subpackage an optional feature with huge dependencies (or cascading
> >> explosion of dependencies) to keep them from being pulled into Ring 0.
> >>
> >> If this is the case, are we open to having *separate* Ring 1 packages
> >> built from the same source but with different options?
> >
> > This is what I replied to the original mail too, nobody answered ...
> 
> I answered- did you miss it?

Apparently never got it, I've had some annoying SPAM false positives
recently that involved fedora lists posts (I also missed a chunk of
flock mailing :-/)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York