On Sat, Jun 20, 2020 at 6:51 PM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> > > wrote: > > > > > > > > > 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 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. 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 maintain. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
