On Mon, Aug 26, 2019 at 4:33 AM Petr Pisar <ppisar(a)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
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:
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.
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
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
In this case, `yum install MyApp:rolling/someprofile` would install
the "someprofile" profile of the "rolling" stream of
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
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.