Fedora Ring 0 definition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Re-sending this with a better title so people might read it ;-)

On 08/31/2015 10:18 AM, Brendan Conoboy wrote:
On 08/31/2015 08:17 AM, Harald Hoyer wrote:
[snip]
Minutes:
<http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.html>

Minutes (text):
<http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.txt>

Log:
<http://meetbot.fedoraproject.org/fedora-meeting-2/2015-08-31/fedora_base_design_working_group.2015-08-31-14.15.log.html>


For today's meeting we didn't really use zodbot minute keeping
features, so in the interest of sparking some discussion I'd like to
recap.

At Flock 2015 there was a 2 hour session on the subject of rings which
are basically policy zones inhabited by packages.  Right now fedora
packaging has 1 policy, so the entire OS is in a single ring. Creating
more rings means creating more policies.  By doing this Fedora can
become adopt the flexible to appeal to diverse development communities
and thus grow.  The general consensus at Flock was that Environments
and Stacks should take the lead in helping to define new rings, and
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?).  A week or so ago, a small Environments and Stacks meeting
took place where it was generally agreed that the Base working group
was the right place to define Ring 0.  That brings us to this
morning's BaseWG meeting.  I talked a lot so here is a rough recap
integrating a few of the questions and comments people had (Do read
the log if you have time!)

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.

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.

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

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.

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.

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.

That's the starting point, but it is by no means comprehensive.  The
OS probably provides specific services beyond the ability to login,
for instance.  Which styles of boot are supported?  Where does
installation infrastructure like anaconda land?  This is equal parts
philosophy and practicality.  Also, policies for ring 0 may differ
from what Base has previously adopted: Do we create a ring 0 minimal
compose since we already need to check repoclosure?  This might be a
great way to refactor primary/secondary such that we can gracefully
transition i686 down and secondary arches up.  Lots of opportunities,
much to consider.



--
Brendan Conoboy / Red Hat, Inc. / blc@xxxxxxxxxx
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux