Fedora Ring 0 definition

[Simo Sorce]

On Wed, 2015-09-02 at 14:24 -0700, Brendan Conoboy wrote:
> On 09/02/2015 02:14 PM, Simo Sorce wrote:
> > 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 :-/)
> 
> Yeah, I found a big chunk of flock email in my spam folder as well 
> *after* the event. Sigh.
> 
> Here's a pointer to the message:
> 
> http://www.spinics.net/lists/fedora-devel/msg213539.html
> 
> A quick cut&pate from that reply:
> 
> [blc]
>  >> 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.
>  > [simo]
>  > Can you elaborate more on this point (5) ?
>  >
>  > I can totally see how a package may be critical and therefore 
> deserve to
>  > be in ring 0 and yet have optional features in terms of subpackages 
> that
>  > are not necessarily ring 0.
>  > For example some library that offers optionally bindings for somewhat
>  > rarely used languages (say ocaml). The subpackages for those bindings
>  > shouldn't necessarily be ring 0.
>  >
>  > Or did I misunderstand the point ?
> 
> [blc]
> Let's take gcc for example.  The gcc package produces numerous 
> subpackages including various compilers and libraries.  One of those 
> libraries, libgcc, is linked into nearly every dynamically linked ELF 
> executable on your system (Run ldd to confirm), including /sbin/init. 
>   Since we really want /sbin/init to function we need to include 
> libgcc in ring 0.  Since ring membership is at a source level rather 
> than a sub-package level, gcc is ring 0.  There are other good 
> arguments for the executable-generating tools living in ring 0, but 
> this one illustrates the point.
> 
> Ring policies might include things like how long the package is 
> supported, what build system can generate it, what release cycle it is 
> on, what the packaging guidelines are, what the updates rebase policy 
> is, and so forth.  These types of policies apply to source rpms as a 
> whole.  You can't apply one to gcc-c++ and another to libgcc.
> 
> I think the question you are posing might be, in the context of gcc, 
> might be: Does gcc-g++ need to appear in the same repository as 
> libgcc? IE, can we decouple what we build from what is presented to 
> users?  If the threshold for must-include is repoclosure then no, we 
> don't need to include gcc-c++, we only need to include libgcc and make 
> gcc-c++ available elsewhere.  In talking to Langdon about this, he had 
> the idea of "ring 0" and "ring 0 prime" where prime is ring 0 plus 
> something.  We weren't sure what the something might be, but perhaps 
> it could be the optional sub-packages.

Thanks I reached fore the archives when you mentioned you had replied.

It seem you do acknowledge there is a problem to be addressed with
optional sub-packages, that's enough for me.

Simo.

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