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.
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?
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.
--
John M. Harris, Jr.
Splentity