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.
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.)
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.
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.
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.
-- Petr
The following answers are just my opinions and not policy.
On Fri, 23 Aug 2019 at 06:52, Petr Pisar ppisar@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.
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@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@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...
On Fri, Aug 23, 2019 at 08:26:32AM -0400, Stephen John Smoogen wrote:
On Fri, 23 Aug 2019 at 06:52, Petr Pisar ppisar@redhat.com wrote:
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.
Thank you for the prompt response. I have yet another peculiar corner case of this one, that I is actually very prominent for me:
We have plenty of Perl packages in RHEL. Most of them are not modularized, thus they are compatible only with Perl 5.26, a default perl:5.26 stream. I feel there will be a demand for providing their modularized variants in EPEL so that users can use them even with non-default perl.
All that can be implemented by adding a new module. This is not a problem. The problem is that the module will an second-class citizen compating to a module with net new package due to missing the default stream. The reasong for banning the default is that the EPEL modular package would mask the non-modular RHEL package.
Let's I have a theoretcal way how to build that module so thet a context for perl:5.26 will be an empty, no RPM package. Then making the stream default would not violate the no-replacement rule.
If a user used perl:5.26, yum would install the non-modular package from RHEL because there won't by any modular package masking it. If a user enabled a different perl stream, yum would install the modular package from EPEL.
Would you accept this solution?
-- Petr
On Fri, 23 Aug 2019 at 09:43, Petr Pisar ppisar@redhat.com wrote:
On Fri, Aug 23, 2019 at 08:26:32AM -0400, Stephen John Smoogen wrote:
On Fri, 23 Aug 2019 at 06:52, Petr Pisar ppisar@redhat.com wrote:
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.
Thank you for the prompt response. I have yet another peculiar corner case of this one, that I is actually very prominent for me:
We have plenty of Perl packages in RHEL. Most of them are not modularized, thus they are compatible only with Perl 5.26, a default perl:5.26 stream. I feel there will be a demand for providing their modularized variants in EPEL so that users can use them even with non-default perl.
All that can be implemented by adding a new module. This is not a problem. The problem is that the module will an second-class citizen compating to a module with net new package due to missing the default stream. The reasong for banning the default is that the EPEL modular package would mask the non-modular RHEL package.
Let's I have a theoretcal way how to build that module so thet a context for perl:5.26 will be an empty, no RPM package. Then making the stream default would not violate the no-replacement rule.
If a user used perl:5.26, yum would install the non-modular package from RHEL because there won't by any modular package masking it. If a user enabled a different perl stream, yum would install the modular package from EPEL.
Would you accept this solution?
Honestly I don't understand the solution (and probably the problem) enough to answer. My understanding of modules is about the same as a layman's knowledge of quantum mechanics. I know it exists, I know it does a lot of things, and I know it is full of conundrums which make no sense to what I normally want to do.
My general rule is going to be "Does this require too much thinking of a system administrator to fix or figure out at 2am when they have worked 4 12 hour days already?" If it does, I don't think it needs to be in EPEL and should have its own solution and community of people who understand it to run. If it doesn't, then it can probably work in EPEL but needs to be written in a way that 2am sysadmin can grok.
Once upon a time, Stephen John Smoogen smooge@gmail.com said:
Honestly I don't understand the solution (and probably the problem) enough to answer. My understanding of modules is about the same as a layman's knowledge of quantum mechanics. I know it exists, I know it does a lot of things, and I know it is full of conundrums which make no sense to what I normally want to do.
THIS!
I've been hearing about modules for a while in Fedora, and now in RHEL 8, but I don't really have the faintest idea what they are, how I'll have to deal with them (both as an admin and as a packager), etc.
Once CentOS 8 is out and I have some time, I'll work on getting my one useful EPEL package built for it, but hopefully that won't involve modules. I only have a couple of packages between Fedora and EPEL, and they so rarely need updates that every time I do anything, I have to go fumble through the steps required (trying to follow online documentation, which I usually screw up, like I think I checked my source tarball into git like a moron).
On Fri, Aug 23, 2019 at 9:43 AM Petr Pisar ppisar@redhat.com wrote:
On Fri, Aug 23, 2019 at 08:26:32AM -0400, Stephen John Smoogen wrote:
On Fri, 23 Aug 2019 at 06:52, Petr Pisar ppisar@redhat.com wrote:
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.
Thank you for the prompt response. I have yet another peculiar corner case of this one, that I is actually very prominent for me:
We have plenty of Perl packages in RHEL. Most of them are not modularized, thus they are compatible only with Perl 5.26, a default perl:5.26 stream. I feel there will be a demand for providing their modularized variants in EPEL so that users can use them even with non-default perl.
All that can be implemented by adding a new module. This is not a problem. The problem is that the module will an second-class citizen compating to a module with net new package due to missing the default stream. The reasong for banning the default is that the EPEL modular package would mask the non-modular RHEL package.
Let's I have a theoretcal way how to build that module so thet a context for perl:5.26 will be an empty, no RPM package. Then making the stream default would not violate the no-replacement rule.
If a user used perl:5.26, yum would install the non-modular package from RHEL because there won't by any modular package masking it. If a user enabled a different perl stream, yum would install the modular package from EPEL.
Would you accept this solution?
I just spent a few minutes trying to figure out if this is technically possible. I think it *might* be, but the more I think about it, the less I like it. I think we should approach EPEL with the principle of least surprise. I don't think any admin should ever get an EPEL package *by accident*. If they used `yum enable perl:5.24`, I don't think that should implicitly mean that they start getting EPEL packages. If they want to use EPEL content, they should have to enable an EPEL stream on purpose.
On Fri, Aug 23, 2019 at 5:27 AM Stephen John Smoogen smooge@gmail.com wrote:
The following answers are just my opinions and not policy.
On Fri, 23 Aug 2019 at 06:52, Petr Pisar ppisar@redhat.com wrote:
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.]
I'm not against making an EPEL module/ stream for a module already in RHEL8. I am *very* against making it a default. Even if the module in RHEL8 doesn't have a default. You will be changing the RHEL8 experience for *all* EPEL8 users, even if they have no interest in your module.
On Fri, Aug 23, 2019 at 6:52 AM Petr Pisar ppisar@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#L2... )
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@lists.fedoraproject.org
-
Chris Adams -
Petr Pisar -
Stephen Gallagher -
Stephen John Smoogen -
Troy Dawson