On Fri, Aug 23, 2019 at 6:52 AM Petr Pisar <ppi...@redhat.com> 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. > > As Smooge says downstream, I think EPEL will need to namespace its streams so it's always clear if you are running an EPEL or RHEL version of a stream. I also don't think we necessarily need to drop the EPEL version; since two streams of the same module cannot be enabled at the same time, there shouldn't be any harm in retaining the EPEL one if there is cause to do so. (For example, maybe the EPEL version includes experimental features where the RHEL one has them disabled). > 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 think the only safe approach for EPEL is to disallow the setting of default streams. This will avoid the possibility of conflicts. > 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. > As I said above, I think we probably don't want EPEL to ever ship a default stream. They should always be supplemental. As for shipping a non-default stream that carries P: yes, that will work. And it's one of the major advantages that EPEL gains in RHEL 8: it's finally possible for us to ship updated versions of RHEL software where required, as long as it is a conscious user decision. (We need to make it clear that if they enable this stream, they're not going to be supported for it by Red Hat if it breaks something else on their system). > > 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. > > Yes, absolutely. If a package is only needed at build-time, this is an ideal way to deal with it. We're also going to be improving MBS to make this simpler: see https://pagure.io/fm-orchestrator/issue/1307 (implementation of https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L282 ) > Could EPEL product owner (or whoever makes and assert the rules) clarify? > 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. > I hope this helps.
_______________________________________________ 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
