On Fri, 23 Aug 2019 at 09:43, Petr Pisar <ppisar(a)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(a)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.
--
Stephen J Smoogen.