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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
