Re: RHEL 9 and modularity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 20 Jun 2020 at 17:42, Neal Gompa <ngompa13@xxxxxxxxx> 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.
>

I think that John and others aren't aware of how a module is built
enough to understand what you meant by
* Automating build chains for producing artifacts
compared to how it is done normally.

In normal times, a packager goes through a list of packages, updates
spec files with new tags and rebuilds them one by one as needed..
sometimes multiple times because of bootstrapping or finding out that
the order you tried was wrong. A made up example from my days of doing
this for a different place (this isn't what is needed anymore but long
ago I had something similar):
bison
flex
gcc [options 1]
bison
flex
gcc [options 2]
glibc
bison
flex
gcc

do them in one order and the apps came out working... do them in the
wrong order and it might not. Rust, Java and other language stacks
have similar loops. A packager may have to coordinate with multiple
people to do this several times.

In a module, you write that all down in the manifest with the order
that you want packages built in and if you need to loop through them
with different options. Then MBS does the builds in an automated
fashion and it is repeatable. To me this is the biggest win here as
for various groups of mass-rebuilds it cuts down errors when order
matters and you have to do multiple ones to get from package set A to
package set A+1.

Making it easier to make flatpacks and stuff also is built into the
tools which came with modularity. The tools which were doing it for
the Fedora buildsystem before this  were 'fragile'.

Yes a packager or system administrator can build these things without
the modularity build system but trying to do it in scale in Fedora
ended up needing the tools which came with MBS.


-- 
Stephen J Smoogen.
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux