Dne 20. 06. 20 v 23:40 Neal Gompa napsal(a):
On Sat, Jun 20, 2020 at 5:25 PM John M. Harris Jr
> On Saturday, June 20, 2020 4:42:17 AM MST Neal Gompa wrote:
>> TL;DR benefits of modularity for Fedora:
>> * Automating build chains for producing artifacts
>> * Straightforward mechanism of producing non-rpm artifacts using our
>> existing tooling (modules -> flatpaks/containers/etc.)
> Both of these have nothing to do with Modularity, and can be done with
> existing RPMs.
They have everything to do with Modularity, because that layer is
where that stuff was implemented. Modularity was the result of the
efforts involved with Factory 2.0, which gave us a lot of improvements
in our build infrastructure tooling for the first time since 2007.
Most of that rolled out in 2017, a full ten years after the last
revamp of our infrastructure.
>> * Path to provide alternative versions of stacks that don't natively
>> multiversion (Nodejs, Perl, PHP, etc.)
> Modularity doesn't support installing multiple versions of the same software.
> It's one of the key issues with the tech.
Modules can be designed to be parallel installable if the underlying
software natively supports that.
I think you are freely interchange "modules" and "module streams".
modules can indeed parallel installable, the module streams cannot even
if the underlying software natively supports that and even if the RPMs
For example, Python works that way
now, and thus in RHEL there are parallel versions of Python shipped as
modules. It doesn't change the nature of the software.
Having python27 and python36 modules is fail, because these should be
2.7 and 3.6 streams of python module.
But it makes it easier to make multiple complete, yet conflicting,
collections of a language stack.