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. 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. Comments and feedback are highly desirable. [1] See https://fedora-modularity.github.io/libmodulemd/latest/modulemd-2.0-Modulemd.ModuleIndexMerger.html for a detailed description of how defaults are merged. _______________________________________________ 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
