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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
