As we plan EPEL 8.1 with support for Modularity/Application Streams, we will undoubtedly encounter numerous tricky questions that warrant public input. The first of these is this: where do modules fit into EPEL 8 Playground?
I see three possibilities for how this can be done: 1) We create two "platform" modules: "platform:el8" and "platform:el8-playground" and use module stream expansion (MSE) or separate branches to build twice, once for each platform. The buildroot for each of these will be the latest set of tags composed for the stable repo + default module streams (for el8) and the playground repo + default module streams (for el8-playground), respectively, plus whatever module dependencies are needed. Builds against el8 will be tagged as candidates and must go through updates-testing. Builds against el8-playground will be tagged directly into the Modular Playground compose. Pros: This is closest to what we are doing for regular packages. Allows us to specialize the builds for dependencies available only in playground. Cons: Uses twice the build resources. Requires a compose for the Modular Playground. 2) We create only one platform module: "platform:el8" using the el8 stable tag plus the Modular stable tag's default streams. We build the module stream a single time. Builds tagged with epel8-modular-candidate will be automatically tagged to epel8-modular-playground. For them to get to epel-testing and later to epel8-modular-stable, they must be submitted to Bodhi. Pros: Builds use less resources. Composes for Modular Playground will be able to hardlink much of their content, so disk space will be reduced. Cons: Requires a separate compose for Modular Playground. Cannot provide specialized builds for deps available only in playground. 3) We create only one platform module: "platform:el8" using the el8 stable tag plus the Modular stable tag's default streams. We build the module stream a single time. All builds go through Bodhi. Users of epel8-playground are encouraged to enable the epel8-modular-updates-testing repo. Pros: Requires the fewest resources. Needs only the Modular compose. Cons: Documenting the usage might be confusing. Modular Playground doesn't get all builds like the epel8-playground does, only the ones submitted to Bodhi (might impact users who intend to have "build for playground" as part of their CI/nightly build system). I have thoughts on which way I am leaning, but I'd prefer to hear a few external opinions before sharing them. Your input is greatly desired. _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
