2015-09-02 23:24 GMT+02:00 Brendan Conoboy <b...@redhat.com>:
> [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?!*
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!
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.
*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
¹ (I am *not* seriously proposing these or willing to debate these; just as
an example of what we *might* want.)
*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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
