Fedora Ring 0 definition

[Brendan Conoboy]

On 09/02/2015 12:31 PM, 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. :)

Hah!

>>> 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.

Where do optional subpackages go in your original definition: IE, 
where does gcc-c++ land: Ring 0 or ring 1?

You could even go wild and say that ring 0 is the compose of the 
Requires satisfiable pieces, Ring 1 is the compose of the Requires 
non-satisfiable pieces from the same source rpms, then Ring 2 is what 
I called 1.  I like Langdon's ring0 ring0' (prime) notation better 
though, it clears up that a single source package is responsible for 
both pieces of each number.

>>> 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?

Yep.

>>> 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?

That sounds bad to me- we would need machinery to keep them in sync, 
and it would be more work for developers.

>>> 6. Ring 0 contains the minimal libraries that define the OS API/ABI,
>>> such as glibc.  This probably happens implicitly by #3, repoclosure.
>>>
>>> 7. Ring 0 contains the tools needed to update existing packages and
>>> install new packages.
>
> At the DNF level or at the Yum level?

Not sure I understand your question: I had dnf in mind, but the gist 
of it is that ring 0 includes a tool which handles automated 
dependency resolution.  It's arguable though, rpm+curl could be 
considered sufficient.

-- 
Brendan Conoboy / Red Hat, Inc. / blc at redhat.com