Matthew Miller wrote:
Without modularity, RPM doesn't offer a good way to choose
between
different versions of the same thing. One can squash version numbers into
the name, which covers some use cases, but also becomes unwieldy and loses
the _idea_ that these things are different branches of the same basic
software.
On the other hand, paired with a suitable file naming/placement scheme, the
versioned package name pattern brings parallel installability, so it is
actually the superior approach from a user standpoint. At least when we are
talking about libraries or programming language interpreters, or any other
non-leaf package. (Incidentally, those are also the ones triggering the main
defect of Modularity, the version conflict hell.)
Well, the idea is: if you need parallel install, don't mess with
it at the
RPM level. Separate at the container level.
Ewww, no thanks!
A container is essentially a distro within the distro, so a whole separate
installation to maintain and update. It is also a huge waste of disk space.
And integration with the rest of the system will always be restricted by
design due to the container technology (even though things such as Portals
try to improve on the situation to a limited extent). And the containers
have to be set up and maintained by hand, since the idea presented in the
early Modularity talks that DNF would automatically containerize modules in
the presence of version conflicts was never implemented, and I strongly
doubt it will ever be, because it is just not practical.
So containers are not a practical solution for parallel installation.
Kevin Kofler