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