The following answers are just my opinions and not policy. On Fri, 23 Aug 2019 at 06:52, Petr Pisar <ppisar@xxxxxxxxxx> wrote: > > If I read the EPEL 8 annoucement correctly, it's still not possible to build > modules in EPEL. Nevertheless I'd like to know how the rules about "not > replacing RHEL content" will apply to modules. Here are my question: > > Case: RHEL delivers an M module with a default S1 stream. There is no S2 > stream. Can I add a new S2 stream into EPEL? I guess this will be allowed. If > later RHEL introduces S2 stream, I guess EPEL will remove the S2 module. > Personally I think all EPEL streams should say they are they from EPEL so S2-EPEL. Consider it a Stream tag :). > Case: RHEL delivers an M module with no default stream, there is no S stream. > Can I add a new S stream into EPEL and make it default? I'm not sure this will > be allowed. There is a risk of creating conflicts between streams transitively > required by another default streams. (Remember the libgit2 module conflict > <https://bugzilla.redhat.com/show_bug.cgi?id=1717117>.) > I would be against that. However I am not sure how we would police that.. [because there is no one to do that kind of work.] > Case: RHEL delivers a non-modular P package. There is no S stream of > a M module. Can I add a new M module with a new S stream that will contain > a modular P package? I guess it will be allowed. Can I make the stream > default? I guess that won't be allowed. > I would agree with your assessment. > Case: RHEL delivers a P package. Can I build a modular P package when building > a new module stream in EPEL only for the purpose of building the module > and then filter out the P package from the module (i.e. a build-only module > component) so that the P package does not get into EPEL repository? I guess > this will be allowed. > It will have to be allowed because it is going to be the only way we can build a lot of packages which may never show up in Code Ready Builder. > Could EPEL product owner (or whoever makes and assert the rules) clarify? There is no product. There is no product owner. The EPEL Steering Committee helps craft rules but in the end they will come from the community. > I need to know that to choose the easiest and yet conforming strategy for > adding new modules into EPEL, especially when dealing with RHEL packages > unavailable for some module contexts. > > -- Petr > _______________________________________________ > 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 -- Stephen J Smoogen. _______________________________________________ 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
