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.
-- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion@xxxxxxxx Boulder, CO 80301 https://www.nwra.com/
Attachment:
smime.p7s
Description: S/MIME Cryptographic 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
