On Fri, 23 Aug 2019 at 09:43, Petr Pisar <ppisar@xxxxxxxxxx> 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@xxxxxxxxxx> 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. -- 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
