On Sat, Jun 20, 2020 at 6:51 PM John M. Harris Jr <johnmh(a)splentity.com> wrote:
On Saturday, June 20, 2020 2:40:48 PM MST Neal Gompa wrote:
> On Sat, Jun 20, 2020 at 5:25 PM John M. Harris Jr <johnmh(a)splentity.com>
> > 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.
As far as I'm aware, flatpacks can be created without any Modules. Containers
certainly can, we've been doing that for over a decade now without them.
Yes, they can, but it's a lot more painful to do so. The Modularity
tooling automates reusing the existing RPM packaging we have and
transforms them into building blocks used to produce a Flatpak
application bundle based on the Fedora runtime that people can use
easily on Fedora or any other distribution.
As for containers, the modularity tooling makes it possible to produce
base containers for various language stacks that look and feel like
native stacks provided by Fedora. You've probably never used any of
the RHEL UBI stuff, or any of the language stack containers built on
UBI. Those containers are *fantastic* to work with. My developer
friends find them a literal *joy* to use compared to the alternatives.
I want *that* in Fedora as well, so people can take advantage of the
fresher base and attract more developer-types to our community.
And Modularity makes that stuff possible in a reasonable way.
> > > * Path to provide alternative versions of stacks that
> > > 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. 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.
> But it makes it easier to make multiple complete, yet conflicting,
> collections of a language stack.
Where the underlying software already supports it, you don't need Modules to
do that, just regular old packages. See Python, for example. Modularity is not
a requirement for that.
It is easy without modules for the interpreter, but it's a royal pain
to do it for *everything* (interpreter, language package manager, and
all associated Python modules). Modules provide a straightforward way
to define what that would look like and build that in a repeatable
manner. A Python stack is roughly ~4K source packages, with all kinds
of "fun" ordering requirements. The Modularity tooling provides a way
to do this sort of thing properly. Without Modularity, we've got
*nothing* to do that in a way that's reasonably automated and easy to
真実はいつも一つ！/ Always, there's only one truth!