On Fri, Aug 23, 2019 at 9:43 AM 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?
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.
_______________________________________________ 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
