On Fri, Aug 23, 2019 at 1:56 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> 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". > ... > > 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. > Since sending this, I've had numerous conversations elsewhere (IRC, conference calls, https://pagure.io/Fedora-Council/tickets/issue/272, etc.) discussing this and we've come to the determination that my first recommendation (prefixing with "epel-") is probably not the right appproach. In particular, it has the following downsides: To quote from my comment in the aforementioned ticket: Right now, if EPEL is permitted to use the same stream names as Fedora (in other words, things like nodejs:12 as opposed to nodejs:epel-12), then it becomes very easy for packagers to build for EPEL. Specifically, the existing Module Stream Expansion functionality will just go ahead and start building for EPEL 8 once that platform appears in the PDC database. And, in most cases, it will build just fine. This also moves us from an opt-in to maintaining EPEL packages to an opt-out to maintain EPEL Modules. There are some downsides to this: we need to have tooling and policies in place to address what happens if RHEL releases a module stream of the same name. @psabata and I generally agree that we should treat this much the same way as with non-modular packages, which is to say that RHEL would take over ownership of the stream (dealing with the version number appropriately so that upgrades are trivial). Forcing EPEL packages to use a namespaced stream has other advantages and disadvantages. The obvious advantage is that it's very clear to the user when they have selected an EPEL stream (thus cutting down on support calls to Red Hat about EPEL content). However, this comes with considerable disadvantages: * Module Stream Expansion won't work because it creates all of its builds with the same stream name. Writing specialized code to detect builds for EPEL 8 and change this mid-flight would be complicated and error-prone. (Particularly in the straw-man case of a module that's build once, run anywhere because it's statically linked, like the rust packages.) * If the stream has dependencies on another module stream (e.g. meson depends on ninja), then all of those stream names need to be adapted to include the EPEL prefix as well. This is, again, probably doable, but it's a considerable amount of work with no guarantees that it will succeed. * If we want to do this anyway, without making changes to Module Stream Expansion, it means that the module becomes an entirely separate stream in dist-git that is maintained separately. That gets us back to opting-in to EPEL 8, rather than opting out. We'll end up with less content in that case. So, with this in mind (and with the agreement of the Fedora Council), I think we ought to proceed with EPEL packages following the same stream naming guidelines as Fedora and we (Red Hatters) will establish a procedure for "taking over" a stream name if and when that is appropriate. This will be similar to how it's handled when non-modular packages move from EPEL to RHEL. _______________________________________________ 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
