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... for a detailed description of how defaults are merged.
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
On Fri, Aug 23, 2019 at 5:49 PM Kevin Fenzi kevin@scrye.com wrote:
On 8/23/19 10:56 AM, Stephen Gallagher wrote:
...
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.
So, after discussing things at today's Modularity WG meeting, we've decided to make a breaking change to libmodulemd's merging logic to solve this much more cleanly. Full details are in https://github.com/fedora-modularity/libmodulemd/issues/368
With that change in place, Option 2 becomes the obvious correct choice, since we won't have to worry about the monitoring of the `data.version` values.
On Tue, Sep 24, 2019 at 08:44:56PM -0400, Stephen Gallagher wrote:
On Fri, Aug 23, 2019 at 5:49 PM Kevin Fenzi kevin@scrye.com wrote:
On 8/23/19 10:56 AM, Stephen Gallagher wrote:
...
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.
So, after discussing things at today's Modularity WG meeting, we've decided to make a breaking change to libmodulemd's merging logic to solve this much more cleanly. Full details are in https://github.com/fedora-modularity/libmodulemd/issues/368
With that change in place, Option 2 becomes the obvious correct choice, since we won't have to worry about the monitoring of the `data.version` values.
That seems reasonable. Thank you.
-- Petr
On Fri, Aug 23, 2019 at 01:56:09PM -0400, Stephen Gallagher wrote:
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.
I don't like the Option 1. It makes adding modularized packages into a build root impossible. Efectivelly forcing everbody to modularize everything or nothing. That's exactly the deficiency the modularity has in Fedora and does not have in RHEL. The Option 1 makes the modularity in EPEL terrible as in Fedora.
Example: RHEL has two perl streams:
perl:5.24 perl:5.26 [d]
You can add a non-modular perl-Foo package into EPEL bacause EPEL magically adds perl:5.26 into the build root.
If you add a perl-Foo module into EPEL, you won't be able to set a default stream, hence you won't be able to have it in the build root and therefore you won't be able to add a non-modular perl-Bar package that requires a perl-Foo module component into EPEL.
The only solution would be either add perl-Bar as a module, or not add perl-Foo as a module. If you go the second path (i.e. no modules), it means you won't be able build none of the packages for the non-default streams (i.e. perl:5.24).
That effectively pushes modules into the role of leaf-only dependencies. That's quite awkward situation if you consider that RHEL delivers language runtimes as modules. The proposed EPEL policy would devalute the non-default runtimes.
-- Petr
On 8/26/19 3:33 AM, Petr Pisar wrote:
On Fri, Aug 23, 2019 at 01:56:09PM -0400, Stephen Gallagher wrote:
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.
I don't like the Option 1. It makes adding modularized packages into a build root impossible. Efectivelly forcing everbody to modularize everything or nothing. That's exactly the deficiency the modularity has in Fedora and does not have in RHEL. The Option 1 makes the modularity in EPEL terrible as in Fedora.
Example: RHEL has two perl streams:
perl:5.24 perl:5.26 [d]
You can add a non-modular perl-Foo package into EPEL bacause EPEL magically adds perl:5.26 into the build root.
If you add a perl-Foo module into EPEL, you won't be able to set a default stream, hence you won't be able to have it in the build root and therefore you won't be able to add a non-modular perl-Bar package that requires a perl-Foo module component into EPEL.
The only solution would be either add perl-Bar as a module, or not add perl-Foo as a module. If you go the second path (i.e. no modules), it means you won't be able build none of the packages for the non-default streams (i.e. perl:5.24).
That effectively pushes modules into the role of leaf-only dependencies. That's quite awkward situation if you consider that RHEL delivers language runtimes as modules. The proposed EPEL policy would devalute the non-default runtimes.
Following up on the perl side of things with an example. What, for example, would be the recommendation to get postgrey in EPEL8?
It requires perl, but nothing specific to 5.24 or 5.26. It does, however, have several required perl modules.
It gets a bit more messy if I've got a home grown perl app that interfaces with SpamAssassin.
If EPEL8 says "just the default stream" for perl, then I have to keep migrating my app. If every perl module becomes a Modularity Module, then 'dnf module list' is going to have a nearly endless list of perl packages, but if modules are only available for one stream, folks are going to find cpan a bit more friendly.....
Pat
On 8/26/19 2:33 AM, Petr Pisar wrote:
On Fri, Aug 23, 2019 at 01:56:09PM -0400, Stephen Gallagher wrote:
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.
I don't like the Option 1. It makes adding modularized packages into a build root impossible. Efectivelly forcing everbody to modularize everything or nothing. That's exactly the deficiency the modularity has in Fedora and does not have in RHEL. The Option 1 makes the modularity in EPEL terrible as in Fedora.
Example: RHEL has two perl streams:
perl:5.24 perl:5.26 [d]
You can add a non-modular perl-Foo package into EPEL bacause EPEL magically adds perl:5.26 into the build root.
If you add a perl-Foo module into EPEL, you won't be able to set a default stream, hence you won't be able to have it in the build root and therefore you won't be able to add a non-modular perl-Bar package that requires a perl-Foo module component into EPEL.
The only solution would be either add perl-Bar as a module, or not add perl-Foo as a module. If you go the second path (i.e. no modules), it means you won't be able build none of the packages for the non-default streams (i.e. perl:5.24).
That effectively pushes modules into the role of leaf-only dependencies. That's quite awkward situation if you consider that RHEL delivers language runtimes as modules. The proposed EPEL policy would devalute the non-default runtimes.
-- Petr
What if we could have "slave" modules? I.e. "epel-perl" that would acquire the state of the "perl" module and could contain the EPEL perl packages. This would require coordination among the EPEL perl packagers to maintain the epel-perl module but would also allow it to automatically track the state of the RHEL module - and allow it to have a default stream.
On Tue, Sep 24, 2019 at 05:02:42PM -0600, Orion Poplawski wrote:
On 8/26/19 2:33 AM, Petr Pisar wrote:
On Fri, Aug 23, 2019 at 01:56:09PM -0400, Stephen Gallagher wrote:
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.
I don't like the Option 1. It makes adding modularized packages into a build root impossible. Efectivelly forcing everbody to modularize everything or nothing. That's exactly the deficiency the modularity has in Fedora and does not have in RHEL. The Option 1 makes the modularity in EPEL terrible as in Fedora.
Example: RHEL has two perl streams:
perl:5.24 perl:5.26 [d]
You can add a non-modular perl-Foo package into EPEL bacause EPEL magically adds perl:5.26 into the build root.
If you add a perl-Foo module into EPEL, you won't be able to set a default stream, hence you won't be able to have it in the build root and therefore you won't be able to add a non-modular perl-Bar package that requires a perl-Foo module component into EPEL.
The only solution would be either add perl-Bar as a module, or not add perl-Foo as a module. If you go the second path (i.e. no modules), it means you won't be able build none of the packages for the non-default streams (i.e. perl:5.24).
That effectively pushes modules into the role of leaf-only dependencies. That's quite awkward situation if you consider that RHEL delivers language runtimes as modules. The proposed EPEL policy would devalute the non-default runtimes.
-- Petr
What if we could have "slave" modules? I.e. "epel-perl" that would acquire the state of the "perl" module and could contain the EPEL perl packages. This would require coordination among the EPEL perl packagers to maintain the epel-perl module but would also allow it to automatically track the state of the RHEL module - and allow it to have a default stream.
Just adding another intermediary module (epel-perl) won't help. It would suffer from the same issue because we would need a default stream for the intermediary module.
You would need some magic in DNF that would inherit defaults and state of enablement from "perl" to the "epel-perl", but that would require changes in DNF. I don't believe that anybody, especially DNF maintainers were happy of it.
-- Petr
On Mon, Aug 26, 2019 at 4:33 AM Petr Pisar ppisar@redhat.com wrote:
On Fri, Aug 23, 2019 at 01:56:09PM -0400, Stephen Gallagher wrote:
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.
I don't like the Option 1. It makes adding modularized packages into a build root impossible. Efectivelly forcing everbody to modularize everything or nothing. That's exactly the deficiency the modularity has in Fedora and does not have in RHEL. The Option 1 makes the modularity in EPEL terrible as in Fedora.
I assume you mean "adding modularized packages into a non-modular buildroot" here. You're right, the result here would be that you could only use RHEL BaseOS + RHEL Default streams in your buildroot or else make a module stream.
I disagree with "makes the modularity in EPEL terrible as in Fedora", however. Fedora's situation went awry because we *didn't* put the appropriate restrictions/safeguards into place around default streams. This is a policy mistake that we're still trying to fix (it's been difficult, but I think we're getting close).
Example: RHEL has two perl streams:
perl:5.24 perl:5.26 [d]
You can add a non-modular perl-Foo package into EPEL bacause EPEL magically adds perl:5.26 into the build root.
If you add a perl-Foo module into EPEL, you won't be able to set a default stream, hence you won't be able to have it in the build root and therefore you won't be able to add a non-modular perl-Bar package that requires a perl-Foo module component into EPEL.
The only solution would be either add perl-Bar as a module, or not add perl-Foo as a module. If you go the second path (i.e. no modules), it means you won't be able build none of the packages for the non-default streams (i.e. perl:5.24).
Well, another thing to be aware of is that we want to avoid the "every package has a separate module" situation, because that way lies madness and combinatorial explosion.
What would be best is if we look at this from top-down, rather than bottom-up. (Or, put another way: let's solve the problem the user cares about).
Users as a general rule do not care which libraries they have. They care that the application they want to run is available to them.
Let's take a made-up example of a package called MyApp that is capable of running atop either Perl 5.24 or Perl 5.26. As a user, my goal is to run this app to meet a business need. MyApp has two dependencies: MyLibrary and MyFramework. MyFramework and MyLibrary both also depend on MyPlatformLib. MyApp, MyLibrary, MyFramework and MyPlatformLib are all compatible with both Perl versions.
Looking at that dependency structure, I'd probably opt to create two modules:
1) A MyFramework module stream (we'll say "1.0") that builds both MyPlatformLib and MyFramework and lists the artifacts produced by *both* of those SRPM builds as API for the module. This module stream would have its module dependencies set for both perl:5.26 and perl:5.24. The result would be a MyFramework stream built in two contexts, one for each Perl version. 2) A MyApp module stream (We'll say "rolling") that builds both MyLibrary and MyApp and lists only the artifacts from MyApp as API for the module (implying but not *enforcing* that the MyLibrary carried in this stream should not be treated as public, stable API). This module stream would have its module dependencies set just for `MyFramework:1.0`.
In this case, `yum install MyApp:rolling/someprofile` would install the "someprofile" profile of the "rolling" stream of "MyApp", pulling in the MyFramework module for whichever Perl version is enabled (or default) on the system.
Furthermore, with this layout, when Perl 5.28 comes out, you will only need to rebuild MyFramework so that it creates a context that works with perl:5.28 and MyApp will not need to change.
(Of course, this specific example works as easily as it does because perl modules built for different 5.x releases don't have to be put in a versioned directory structure. If they did, MyApp would also need to list its interpreter dependencies directly and be rebuilt for new streams of the interpreter.)
The point of this is to note that we want to encourage that if you have packages that are tightly-coupled (or that are used together more often than not), they should go into a module stream together.
That effectively pushes modules into the role of leaf-only dependencies. That's quite awkward situation if you consider that RHEL delivers language runtimes as modules. The proposed EPEL policy would devalute the non-default runtimes.
Right now, I'm leaning towards suggesting that we should ship EPEL 8.1 without the option to set default streams for EPEL modules. We can work out as many bugs as possible with the module implementation and potentially come up with a strategy for enabling default streams in a later EPEL release, maybe 8.2.
On Tue, Sep 24, 2019 at 09:13:51PM -0400, Stephen Gallagher wrote:
Example: RHEL has two perl streams:
perl:5.24 perl:5.26 [d]
You can add a non-modular perl-Foo package into EPEL bacause EPEL magically adds perl:5.26 into the build root.
If you add a perl-Foo module into EPEL, you won't be able to set a default stream, hence you won't be able to have it in the build root and therefore you won't be able to add a non-modular perl-Bar package that requires a perl-Foo module component into EPEL.
The only solution would be either add perl-Bar as a module, or not add perl-Foo as a module. If you go the second path (i.e. no modules), it means you won't be able build none of the packages for the non-default streams (i.e. perl:5.24).
Well, another thing to be aware of is that we want to avoid the "every package has a separate module" situation, because that way lies madness and combinatorial explosion.
What would be best is if we look at this from top-down, rather than bottom-up. (Or, put another way: let's solve the problem the user cares about).
Users as a general rule do not care which libraries they have. They care that the application they want to run is available to them.
I cannot agree with most of the statements you made. Fedora users care about libraries because they are developers. Not about all of them but about many of them. About much larger number than is a number of applications Fedora provides. Hence limiting modules to applications is suboptimal.
Starting with few application-centric modules and splitting out modules with librarires on user's requests is troublesome because you would end up with multiple modules providing the same or similar or incompatible packages. And you cannot just replace the old big modules with new slimmer ones because you cannot retire the old modules, you need to support them to the end of their life.
Having few fat modules is also problematic because you will find out that they have common dependencies that would conflict each to other. (You know that modularity does not solve parallel installability.) Also there are technical issues in Fedora infrastructure that makes building large modules unreliable.
Therefore in my opinion many smaller modules is the right way. It supports sharing packagers work and allows delivering fixes faster.
But I agree that the current modularity implementation does not scale (performance- and tooling-wise) with a large amount of modules. A proper solution would be dissolve modules into RPM level so that it's native to RPM and DNF. But that's somewhat off-topic.
The point of this is to note that we want to encourage that if you have packages that are tightly-coupled (or that are used together more often than not), they should go into a module stream together.
Definitely. But my experience of maintaining hunderds of packages and mass rebuilding thousands of them says that a chance for coupling packages into modules is miniscule.
-- Petr
On Fri, Aug 23, 2019 at 1:56 PM Stephen Gallagher sgallagh@redhat.com 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@lists.fedoraproject.org
-
Kevin Fenzi -
Orion Poplawski -
Pat Riehecky -
Petr Pisar -
Stephen Gallagher