<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-09-02 23:24 GMT+02:00 Brendan Conoboy <span dir="ltr"><<a href="mailto:blc@redhat.com" target="_blank">blc@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[blc]<span class=""><br>
>> 5. Ring membership is at the source package level, not the binary<br>
>> package. If one source package's binary/noarch sub-package is in ring<br>
>> 0, all sub-packages are in ring 0.<br></span>
> [simo]<br>
> Can you elaborate more on this point (5) ?<br>
><br>
> I can totally see how a package may be critical and therefore deserve to<br>
> be in ring 0 and yet have optional features in terms of subpackages that<br>
> are not necessarily ring 0.<br>
> For example some library that offers optionally bindings for somewhat<br>
> rarely used languages (say ocaml). The subpackages for those bindings<br>
> shouldn't necessarily be ring 0.<br>
><br>
> Or did I misunderstand the point ?<br>
<br>
[blc]<br>
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.<br></blockquote><div><br></div><div>(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.)<br><br></div><div>The whole conversation seems to me rather confusing, and more likely, just confused.<br><br></div><div>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, <i>without any consensus on what the rings are?!</i> <br><br>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.<br><br></div><div>Thinking about a few possible goals¹:<br><ul><li>They have <i>nothing</i> 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 <i>might</i> want to ultimately <i>implement</i> the policies in terms of SRPMs, but the <i>goals</i> are not in terms of SRPMs, so thinking about the policies in terms of SRPMs is unnecessarily restrictive.</li><li>There is no subset/superset relationship between SRPMs, or individual files, implementing these goals; the goals are not even in terms of files!<br></li></ul></div><div>Let’s think about the<i> produced artifacts</i>, whatever that is, first: decide what we want to achieve by the policies, and what the desired and practical policies would be. <i>Then</i> would be an appropriate time to check for subset/superset relationships and other ways to inherit/share effort; <i>not</i> at the very start of the definition process!<br><br><br></div><div>Also, it seems to me that it would be useful to, at least conceptually<i>,</i> 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 <i>ecosystem</i> than the <i>produced artifacts.</i><br><br>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.<br><br><i>Then</i> we could start thinking about <i>truly minimal</i> 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”, …<br></div><div> Mirek<br></div><div><br><br>¹ (I am <i>not</i> seriously proposing these or willing to debate these; just as an example of what we <i>might</i> want.)<br></div><div><b>ABI:</b><br><ul><li><b>Goal:</b> 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.<br></li><li><b>Possible Scope:</b> 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.</li><li><b>Implementation: </b>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.)<br></li></ul></div><div><b>Administration Interface:<br></b><ul><li><b>Goal:</b> There is an efficient way to administer large numbers of Fedora machines in an automated way.</li><li><b>Possible Scope:</b> 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.</li><li><b>Implementation: </b>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.</li></ul></div><div><b>User Interface:<br></b><ul><li><b>Goal:</b> It is easy to use Fedora, and easy to learn it because its user interface is consistent and well thought-out.</li><li><b>Possible Scope:</b> 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.<br></li><li><b>Implementation:</b> 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.</li></ul><br></div><div>² 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.<br><br></div></div></div></div>