On 8/23/19 10:56 AM, Stephen Gallagher wrote: > As you know, we delayed support of Modularity in EPEL (called > Application Streams in RHEL) until 8.1 while we worked out some > remaining issues. Some of those issues were technical, but we have a > few others that will come down to policy. In particular, EPEL has to > deal with something Fedora does not: the possibility that it could > come into conflict with streams from the official Red Hat Application > Streams. > > I'm going to try to enumerate in this email some of the cases I can > think of that might need attention, as well as providing my > recommendations for what policy we should set in EPEL. > > Case 1: EPEL ships a module "foo" with stream "baz" (aka "foo:baz"). > This is an alternative stream to RHEL AppStream, which ships > "foo:bar". In a new minor release, RHEL AppStream starts also shipping > "foo:baz". > > Case 2: EPEL ships a module "foo:baz". RHEL AppStream does not ship > the module"foo" at all. In a new minor release, RHEL AppStream starts > also shipping "foo:baz". > > Case 3: EPEL ships a module "foo:baz". RHEL AppStream does not ship > the module "foo" at all. In a new minor release, RHEL AppStream starts > also shipping "foo:bar". > > Case 4: EPEL ships a module "foo:baz". AppStream ships the module > "foo" and has "foo:bar" declared as the default stream. > > Case 5: EPEL ships a module "foo:baz". AppStream ships the module > "foo" and has no default stream specified for the "foo" module. > > Case 6: EPEL ships a module "foo:baz" that wants to set the default > profile of the "baz" stream to "client". AppStream does not ship the > module "foo". > > Case 7: EPEL ships a module "foo:baz" that wants to set the default > profile of the "baz" stream to "client". AppStream ships the module > "foo" and has a default profile set for the "bar" stream. > > > > So lets's break these down. The first three cases are all very > similar. They address the situation where we have both RHEL and EPEL > attempting to own the same name within a namespace (module). My > recommendation here is that we require EPEL module streams to be > prefixed with "epel-". Then, even if RHEL AppStream starts shipping a > stream of the same name, there will be no namespace collision. There > is another benefit as well: it will be easy to tell at a glance > whether a particular stream is from RHEL AppStream (and therefore > supported by Red Hat) or if it comes from EPEL, with only volunteer > community support. > > The cases involving default module streams are a bit more complicated. > Making a module stream a "default stream" effectively means that its > contents are treated like the non-modular EPEL 8 contents, except that > installing one of them means that the stream becomes enabled. We need > to figure out, however, whether we should allow EPEL to set default > streams at all. The major issue is that if RHEL later starts shipping > this module and wants to set a default stream, we now have a conflict > to resolve. From a technological standpoint, it can be done: Red Hat > will need to ship the defaults object metadata with a `data.version` > value higher than the one shipped in EPEL. Yum will then prefer that > version over the one in EPEL. A slight risk occurs here if EPEL ships > an update to the defaults data that bumps the version higher again, > but that's really no different than today when someone pushes a > package build to EPEL that ends up in RHEL with a lower version at a > point release. > > Things get dicier when we add in the concept of the default profiles, > though. The design of the module defaults metadata did not entirely > take the split repo ownership into account (my fault). So we > essentially have a single YAML document in the metadata that > identifies the default stream and the default profiles for each stream > in the module. Now, there's some leeway here: I did consider the > updates[-testing] use-case, so in the event that two repos both > contain defaults for a module, they can be merged[1] in many cases. If > they have the same `data.version` value, so long as the provided > profiles do not conflict, they will just be merged together. If they > have differing `data.version` values, the higher one will win. > > > So, I see the following options for how to handle default streams in RHEL 8 > > Option 1: We disallow assigning default streams at all within EPEL 8. > This will protect us against a future change where RHEL wants to set a > default. Additionally, it means that all EPEL modules are explicitly > opt-in and so we don't ever surprise anyone. > > Option 2: We allow making EPEL streams the default stream if RHEL does > not currently provide a default stream. We set strict policy regarding > what a default stream may contain (such as "must not replace any > package provided by RHEL 8"). If RHEL later decides to set a default > for this stream, the RHEL release engineering must ensure that the > `data.version` value is higher than what EPEL 8 carries. > > I'm somewhat more in favor of Option 1 here, mostly because it > minimizes the chance of conflicts and ensures the opt-in nature of > EPEL. But I'm willing to hear counter-arguments. Yeah, me too. Option 1 please. > For default profiles, we have some options as well: > > Option 1: We disallow setting default profiles for EPEL streams. Pros: > no risk of conflict with RHEL, should they now or in the future > provide defaults for some streams of this module. Cons: `yum module > install foo[:bar]` would not work (they would need to do `yum module > install foo[:bar]/profilename`) and would likely irritate users. > > Option 2: We allow setting default profiles for EPEL streams. We take > advantage of the defaults merging logic and ensure that if we need to > supplement RHEL AppStream's defaults content, we must ship a > modulemd-defaults document of the same `data.version`. This will allow > them to be merged cleanly. Pros: Optimum user experience (they get the > default profiles installed when they use the simplified install > command). Cons: We need to constantly monitor each RHEL AppStream > release and ensure that we aren't ever overriding (or being overridden > by) RHEL. > > > I think Option 2 is the better choice here (fewer angry users is a > good thing), but I worry a bit about the maintenance burden of keeping > track of the `data.version` values and ensuring they stay in sync. I > think we can probably automate a good deal of this, though. Yeah, I would like to do 2 also if we can manage to make it mostly automated. kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
