 Hi and welcome to my presentation about the magical world of modularity so yeah so I see new faces all faces and new faces and you know like always present this technology as something magical and red but you know like most of us who already experienced it or worked with it you know it's like something like this yeah so basically yeah who am I I'm Martin to lay as I've already said I'm a senior software engineer on the redhead and also product owner of software management at Redhead which includes also modularity and other projects so yeah so yeah we talked like maybe you heard about modularity maybe not so it's yeah what it is exactly so modularity was a project which was conceived through the notion that we wanted to include basically multiple different flavors of software in a RPM repository or basically it's an auxiliary packaging method which you can use for for doing exactly this for example let's let's take pearl normally when you have a standard stable distribution let's say like Fedora you have only one major version of package so and it's supported for for the whole lifetime of this distribution but what we wanted to do is basically let's say I want to include more pearls not only one but also I want to call the package pearl so we have like three packages of pearl and you know like when you do it this the standard way it's a conflict and bad things happen so yeah so basically you can also imagine what what modularity enables is basically that it puts repository inside your repository so yeah so the problem with modularity is that in the already existing packaging ecosystem it introduced a lot of nomenclature which people didn't know and I will try to explain at least basics like like people always talk in modularity about modules but what exactly is a module so don't forget that in modularity I use a lot of fancy words but we still talk about packages about RPM packages and such so what is module basically like the definition is like module is one or more sets of software packages which can be described in one name or something like that so each of those each of each set of those software packages is called a module stream which is another word so we have a module and then a module stream which are two different things but basically module defines all the module streams inside it so yeah so what is a module stream module stream yeah so module stream represents RPM packages which which are built and bundled together yeah so each module stream consists of RPM binary files and metadata YAML file this is important because if you have only the binary files like RPM files you cannot install them without the metadata like DNF or YAML or whatever they'll not allow you to do that because all the RPMs which are built let's say in Fedora or other distributions have a failsafe inside it which you know doesn't allow you to do that this is by design because the metadata the YAML file describes other configuration options for this set of packages and of course this metadata as I wrote is not a part of the RPM files headers like it was in like like it's standard when you are just working with packages yeah so the second thing is the that you know when you you know I again I used a lot of fancy words like you maybe you cannot imagine how this looks like in your directory when you're just working with RPM files but basically you can have a module you can also think about the module like a meta package so basically you can just put a bunch of RPMs in a directory and just create a YAML file which will describe this this bunch of RPM files they can be any RPM file don't they don't have to be part of a module or they can just be a non-modular standard content which you can find in any RPM base distribution of course the way how those packages are built or what are the dependencies and that's your problem you know you have to know how they interact together so you can basically do that yeah one thing what I need to mention is that there is so much about modularity that I will not be able to cover all of it so I just giving you the like the main like highlights like what you need to know to start and then you can look at our documentation which was updated recently so try it yeah as I already talked about the failsafe basically also like the failsafe is just a string inside the RPM binary RPM header which says that I'm from a module so I cannot be installed by myself yeah so as I said earlier modularity brought a lot of new nomenclature into everything and modules or module streams are named differently they don't use the never convention of course the RPM files inside the module stream still use the never convention so it's fine but the whole bunch or the group of those RPM files uses a different naming convention which is called NSVC which is named stream and a version context so for for like quickly go through this you know the module is defined by its name so as I said a module contains multiple sets of RPM files which which are bundled and built together each of those sets is called a stream so then you have like name stream so you have an additional thing like like I explained there like you use Perl 524 and Perl 526 of course when you have something like that in Fedora and you want to use you can use only one of those yeah you cannot use 524 and also 526 because how your system will know like which one to use so basically you will choose like okay so I want to enable this module Perl 524 and what will happen inside your system it will it will basically mask all the it will it will it will mask all the non-modular content which is which has something to do with Perl and we'll just use the RPMs from this stream yeah I know it's complicated next is module version basically module version tells us which of the module streams is the latest one it mostly it depends of course if you are building it locally or you are building in a distribution in Fedora we use the timestamp of the git commit that you are building from so module version is basically that you know DNF can look at the modules and say okay so you know order them by by version I know which is the newest one and I can update your packages yeah context this is the I would say biggest like thing that people will understand how this works as I said previously module streams is a set of packages which are built and bundles and installed together so context in this metadata file that I mentioned earlier define how actually you are setting up your you are setting up your your build route how you what do you need what dependencies you do you need actually to be installed together with those and so on so context is like a configuration for this specific set of packages so for example you can have you know context can be different configurations for different distros for different set of modular dependencies which I will not go into here because it's too much to go through so yeah next is yeah breakage in conflict the one thing that you need to imagine that normally people are used to Linux distribution that it stable so people when we're working on a distribution they do all the things they they you know update their packages and so on and they agree like okay so for this distribution we will have only this version of software and you know we will support it until until end of the distribution fine everyone is fine with this and you know the packages are trying to do that they will not break other people packages so so that basically the distribution is stable with modules you can actually break your distribution because you you still have the stable distribution but you can enable like let's say with pearl let's say you have in the standard distribution you have 524 which is like non-modular not in a module just a normal package but let's say you will say okay I need for my I don't know something for my application 526 so I will enable the the I will enable the stream 526 the 524 non-modular will be replaced by 2026 which is fine but it is if the if the packageer didn't you know check all the possibilities he can like change your how how other people other packages are interacting with this pearl which is a different version and there can be a breakage so this is this is something to keep in mind that if you are using modules like it's like alternative software so if you are using those please keep in mind that breakage and conflicts can can appear also when you have like there are multiple things we have some mentioned on the documentation on in Fedora like the conflicts and breakage and so on so you can look at those there yeah so one additional I already spoke about that you can have all enabled only one stream at the time so when you have module like pearl and you have 524 pearl and 526 when you enable 524 you you are not you cannot use packages for from 526 because it will not not you know then I will say like no the idea have this enabled and I will not do other packages yeah and I already talked about packages yeah it's a little bit harder because you know we have more software to get stable which with the distribution but yeah yeah building module so as I already said you you can just take any RPMs you have put them into directory put a YAML file run create a repo see and you have like a module building locally module build we have a tool called module build it's still like like fresh it's like I the first version was released in January or February so but we are we are improving it we added like building from source RPMs and so on and then we have like building Fedora there is a link to the to the official documentation in Fedora if you yeah if you look at the Fedora documentation and you so see something that is that you don't know or you need to add to this documentation please write to us on Fedora level to me to modularity team there is our contacts on the documentation so please please please we want like input from people outside of you know that and like mostly community yes and then we have additional tool which is also you can install it in Fedora it's called module MD tools if you want just like quick like tooling which will enable you to work with modules yeah this is again links and yeah we have also modular metadata YAML specs so if you want to like build your own YAML without the distribution you can just check about this this document there is everything is commented and then described yes and that's all thanks so questions no it's not yeah so the question was like if if someone will bring will create let's say module and this module will when you enable it and you know run it it will let's say break your system that some of your system applications will not work like who is responsible for this yeah so so as I said previously how it works right now in Fedora or other distributions that that packages are collaborating together with normal content not modular content only normal content which they basically agree like okay so I did this change to your software and I see okay we changed the API and it broke something else so we need to work on it so the release will be stable so this is the same for modules like modules modules are not something modules are not something like different from RPN there are still RPNs the package of this particular software which I put to the distribution is responsible for the fact that it works in this environment and that's where I test it yes right and then there is another movement in the same distribution at the same time right where people are building some modules with some software libraries of different versions something something something right and I'm as a package I don't want to know about these modules yeah of course so so you are responsible that your module will work with the stable non-modular packages you are not responsible that you have to be you know because because the metrics when you think about it the metrics is like freedom and dimensional and it's crazy so no no no you are responsible only for your module to work with the base distribution if it works then that's fine if someone will open like use other modules and then will you use your module and everything will be broken then you know it's on the person who basically set up it in this way so I mean maybe I'm not asking about like who to blame right but I mean how to bring this to a usable state where I as a user can see oh there are modules available to these distributions and I can enable them and nothing bad will happen because something you cannot do that you like there is no automatic process where you can like create modules and say like they will never break anything yeah like like you know you have you have modules which are more stable let's say Postgres like we have like like free free streams in Fedora which basically when you you know install one then if you own install it and install another one from another stream they don't really break you know anything they are just like databases so this is fine but yes as if you had a little pearl yeah it can happen yeah yeah that's why it's as I the start that was like me means you know like always like it's fine so yeah just a short question so why would I want this what's the use case or it depends because you know like I you know I know when I did examples with pearl let's say I only let's say that the streams are a major versions but you don't have to have major versions you can have like different you know configurations not only built build time but also runtime for your for your package so if you need this that you have you can have like multiple let's say different flavors of your application let's say for I don't know for development for for something else so you can you can use modules for that so basically this was built for real sorry this was this was primarily built for real because you know this is something where we have a use case actually actually I forgot that thank you you remind me is that this technology is really used in a sandbox environment all the all dependencies which are going to a flatback are modules like flatback uses modules containers use use modules because it's easy to build a system that you want like a you know ready-made sandbox that you will just like reproduce without problems I would and you are not you are not actually dependent on the stable stuff in the distribution because if you want to play you can so yeah so the question is how many modules are in Fedora so right now I think like 20 maybe or 10 between 10 and 20 I just just do dnf module list like normally it depends on the the version like a release of the distribution for federal let's say we don't have like the pearl we don't have like 524 my 26 and 540 and also we have 542 but we don't have all of them for all so we have like for the newest 46 Fedora we have like only two like the last last two for 30 and 42 how does relate to software collections yeah so yeah this was this was basically this is a replacement the only like downside of this like with with software collections you had parallel instability with this you don't but actually when we when we run the numbers in our with our customers then you know like only like five percent people use this and also people were angry because they were to use that packages are ending up in the directories that they expect to and when you have software collections they are installed somewhere else and you know when they had like automation this was the problem okay there are no more questions thank you Martin for the presentation thank you