On 09/07/2015 05:21 AM, Miloslav Trmac wrote:
2015-09-02 23:24 GMT+02:00 Brendan Conoboy <blc@xxxxxxxxxx
<mailto:blc@xxxxxxxxxx>>:
[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.
(Sorry, I have not been following the conversation over the months in
detail, have not seen the Flock presentations, and I may well be
missing something. But still, it seems worth asking for a sanity check.)
The whole conversation seems to me rather confusing, and more likely,
just confused.
How did we end up (or at least it seems that way) with a consensus
that we will have policy rings, i.e. organization into ideal subsets,
and a consensus that they will be based on SRPMs, and perhaps even a
tentative consensus that the rings should be transitively closed over
BuildRequires, /without any consensus on what the rings are?!/
We don't have a consensus yet, that's part of what the discussion is
about. What we have so far is a general idea that E&S roughly oversee
how the rings interact and distinct groups should have input into the
definition of each of the rings. Ring 0 looks roughly like the Base
WG's domain.
AFAICS somehow the goals and means have gotten confused, and we are
trying to find goals that would make sense in a specific
implementation method; that’s completely backwards.
Thinking about a few possible goals¹:
* They have /nothing/ to do with SRPMs—actually even the concept of
“source code” does not appear—and most of the policies are not
inherently tied to SRPMs; they could just as well be specified,
documented, tested or enforced in terms of a whole installed
system, or in terms of individual elements. We /might/ want to
ultimately /implement/ the policies in terms of SRPMs, but the
/goals/ are not in terms of SRPMs, so thinking about the policies
in terms of SRPMs is unnecessarily restrictive.
* There is no subset/superset relationship between SRPMs, or
individual files, implementing these goals; the goals are not even
in terms of files!
Let’s think about the/produced artifacts/, whatever that is, first:
decide what we want to achieve by the policies, and what the desired
and practical policies would be. /Then/ would be an appropriate time
to check for subset/superset relationships and other ways to
inherit/share effort; /not/ at the very start of the definition process!
You are right that we do need to think about overall goals to be
achieved, then the policies that achieve those goals. For my part I
am interested in distinguishing the OS from the applications that run
on top of it. This might be the difference between ring 0 and ring 1.
It's too early to tell, though. During today's base wg we talked a
little bit further about possible goals that a ring 0 might fulfill
(http://meetbot.fedoraproject.org/fedora-meeting-2/2015-09-14/fedora_base_design_working_group.2015-09-14-14.15.log.html).
A few hypothetical possibilities as examples:
1. Make a "Base" (or ring0) compose who has its own alpha/beta/ga
cycle that precedes the RC deadlines for the current editions and
spins, providing a stable set of NVRs to base upon.
2. New boundaries for primary/secondary arch blocker status, rules for
excludearch, threshold for inclusion in primary koji, etc.
3. Decouple the ring 0 release cycle and support terms from the
editions. Maybe base comes out every 4 months. Or 9 months. Maybe
it's supported for 24 months. Things like that- it's small. Editions
and spins can pick the base release to build on.
Also, it seems to me that it would be useful to, at least
conceptually/,/ to not think about Fedora as a self-hosting perpetual
motion^Wrecompilation machine, but as “just another huge application”
being built using compilers and other tools which come from
$some_other_magic_place. That’s not to say that self-hosting is not
valuable—it is a critical property of the subset of the Open Source
ecosystem which Fedora distributes—but it is more of a property of the
/ecosystem/ than the /produced artifacts./
In particular, I am fairly baffled by the idea that “ring 0 should be
self-hosting”: it automatically leads to a huge ring 0, and together
with the implied hierarchy of rings it implies that other smaller
functionality/policy subsets don't fit into the model and can’t be
considered (the SRPM granularity makes it much worse but it is bad
even without it). Instead of “/bin/bash and the compiler used for it
need to be frozen and stable in the same way”, which doesn’t even make
much sense (/bin/bash needs to have a stable UI, the one component of
a compiler which we want to be improving and do not need to be
stable), we could, for example, freeze all “compilers and build tools”
(yet another artifact group which defies hierarchy) at Alpha time²,
and take them completely out of the policy picture from then on.
Er, the idea was that ring 0 is *not* self hosting, rather that a
compose of ring 0 satisfies its own dependency requirements. The
further result of this thread is that the compose of ring 0 might
contain only some subpackages from the source material, to further
limit the size of the compose and dependencies pulled in.
/Then/ we could start thinking about /truly minimal/ concepts,
perhaps “container minimal” = “the minimal set needed to start and
run an executable dependent on Fedora ABI” (e.g. kernel version
requirement +glibc+locale data+Python 3 interpreter+…, useful for
building containers), “VM minimal” could be “the minimal contents of a
VM needed to start and run…” (e.g. kernel
implementation+init+container minimal, useful for single-app VM), “CLI
minimal”, …
Mirek
Right, so I don't think minimal is the end goal, I think the OS (not
the distribution) is the end goal- minimal is presumably a subset of
the OS.
¹ (I am /not/ seriously proposing these or willing to debate these;
just as an example of what we /might/ want.)
[great examples of things to dicuss]
Are you saying we might want to consider these but you personally
don't want to own the discussion? Not clear on why you've put them out
there but advised against debate.
*ABI:*
* *Goal:* There is a well-defined ABI of “The Fedora operating
system” available in any Fedora installation. The API has a
defined stability promise, lifecycle policy, and
deprecation/versioning/transition mechanism, so that any author of
an application (FOSS or binary-only) knows what interfaces are
appropriate to use so that the applications continue to work and
be useful to their users.
* *Possible Scope:* glibc’s strcpy(), D-Bus protocol 1.0 on the
system and session bus, libgcc.so ABI as of $version, the
org.freedesktop.PolicyKit1.Authority D-Bus service, kernel’s
/proc/self/attr/* files. Not glibc’s strfry(), D-Bus over IP,
format gcc’s standard output, contents of /sys/kernel/debug.
* *Implementation: *Document the stable ABI, have a policy of
requiring independent regression tests of the ABI and of not
breaking the ABI. Document best practices for
versioning/transition (perhaps e.g. file formats may not be in the
ABI because they can’t be effectively versioned.)
*Administration Interface:
*
* *Goal:* There is an efficient way to administer large numbers of
Fedora machines in an automated way.
* *Possible Scope:* A specific set of “blessed” ansible modules. A
$specific_way how to have an installed Fedora system listen on
port 22 and accept a specified private key to authenticate as
root. Not a commitment to keep /etc/ssh/sshd_config unchanged so
that (echo $foo >> /etc/ssh/sshd_config) can be relied upon.
* *Implementation: *Document the provided tools, and the scope of
what features are expected to be supported by them; have a policy
of not accepting features within the documented scope if they can
not be managed by these tools.
*User Interface:
*
* *Goal:* It is easy to use Fedora, and easy to learn it because its
user interface is consistent and well thought-out.
* *Possible Scope:* The default desktop and default applications
implementing a specific set of functionality, all CLI utilities
included in the Administration Interface above. Not “alternative
desktops”, ZX Spectrum emulators, GUI applications installed by
default but having their menu icons hidden.
* *Implementation:* Have a HIG for GUI and CLI, and a policy of only
accepting components within scope if they comply. Recommend UX
designer involvement for every application in scope.
² This is an obvious but extreme, and probably unwanted, example. We
probably want some kind of stability for build tools while allowing
them to be fixed during the release cycle; but it is not obvious at
all to me that the policies for build tools and built artefacts should
be the same; e.g. the Bodhi karma system seems to be a poor fit, a
“does not crash when run” smoketest is completely useless, and we seem
to have the tools and resources to just use the updated build tools
for a test mass rebuild to verify their functionality instead, which
would not apply to non-build-tool artefacts.
--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
