On Mon, Aug 26, 2019 at 4:33 AM Petr Pisar <ppisar@xxxxxxxxxx> 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. _______________________________________________ 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
