On Thu, Nov 14, 2019 at 2:04 PM John M. Harris Jr <johnmh(a)splentity.com> wrote:
On Thursday, November 14, 2019 11:45:22 AM MST Stephen Gallagher wrote:
> You're assuming that parallel-install is a thing that everyone needs
> from every package on their system.
I'm not. However, if you're going to bring up 'the recommended solution for
doing "parallel-install" with modules', it makes sense to address this.
> Our research and surveys determined that this was not in fact the case for
> the overwhelming majority of real-world deployments. Most[1] deployments
> function with a "one app per VM/container" mentality.
This isn't surprising to me, as that's just an extension of what is done with
physical hosts as well, when serving important services. The physical host or
VM is often dedicated to said service, often at the recommendation of the
software itself, for example FreeIPA recommends this.
> In such cases, parallel-installability is at best unnecessary and (such as
> with SCLs) actively annoying to them.
Only if actually implemented as SCLs, in my opinion, but that is definitely an
opinion.
I phrased that wrong. It should have read: "_sometimes_ (such as with SCLs)".
> Modules offers the availability of multiple streams of software
like SCLs
> does, but it sacrifices the ability to install them in parallel for the
> ability to install them in the standard locations on disk so that other
> software doesn't need to adapt to alternate locations (the number-one
> complaint received about SCLs).
So, are modules are meant to replace SCLs? If so, surely the inability to
install multiple versions invalidates that?
They aren't incompatible technologies. If there is a case where
parallel-installability is valuable, an SCL can still be made. But for
the common case, we (Red Hat) determined that parallel-availability
was more valuable and common.
For example, one of the issues I'm trying to resolve at work is
providing both
Python 2.7 and Python 3.5 on RHEL 6.
Python 2 and 3 are effectively separate tools and (given that they are
built with parallel-installability in mind) should absolutely not be
streams of the same module.
Now, python3:3.7 vs. python3:3.8 might be a more interesting question...