Last summer at Flock Langdon White, Ralph Bean and couple folks around them announced work on new release tools and a project called Modularity. The goal was simple but aspirational - for couple years we've talked about rings proposal, splitting applications from the core of the OS, having alternatives available and easily installable for certain components and even though for all of these usecases you could always find a way how to achieve them they weren't really supported by the build infrastructure and software management tools. Once you would update your system or install something else it would usually break or do something unexpected. Modularity goal was to come up with a straightforward way how to deliver a bulk of content thru our build pipeline, offer multiple versions of components and different installation profiles. At the same time this new approach to delivering content would not break existing workflows and will be super easy for package maintainers.
Folks working on this concept has been reporting progress over the last year but finally today we have an image available that shows how modules behave on the OS and how DNF can deal with them. So let's give it a try and let me walk you thru what you can do Boltron - Fedora Modularity concept.
First, get the latest fedora compose $ docker pull fedora:26-modular
$ docker run -it --rm fedora:26-modular /bin/bash
As you can see in $ cat /etc/os-release
this is a special compose that points at a repository with modules. As a second step, you need DNF with module plugin and couple other enhancements. $ microdnf -y install dnf
(Please ignore the ugly output for microdnf - it's supposed to be used in dockerfiles only and this is a sort of a hack to get the right DNF installed)
One of the main goals was to preserve existing command line interface. Unlike with software collections or other tools DNF just works and there are only minor changes that expose the magic that is happening in the background. $ dnf list
..has a new section called modules. The UI of this is most probably going to change but right now it shows modules that are available (apx 25 modules) and whether they are installed on the OS or not. It also shows two other important information - the stream where you either have the default stream (f26) or alternative stream (in case of nodejs, stream 8). Once you installed any module you will also see the installed profile of that module under Installed column.
So let's try to install our first module $ dnf install httpd
Wait, there's no special command line option for module and it feels and looks like I'm just installing RPMs!? Right, that's the plan! Unless you want to use the functionality that modules bring - streams and profiles - you don't even know that you're playing with modules. In case of apache, module is a blob of RPMs that got build together in Factory 2.0 (the new Fedora release tools - updated koji, module build service, pungi and few others), they got tested all together as a bulk and now installed on your Fedora. $ dnf list
.. now shows that I have one module installed - httpd in it's default profile.
Ok, let's try something different. Nodejs has two versions/modules available. Nodejs v6 and v8. So first, what happens if I just run $ dnf install nodejs
In this case I get nodejs from the default stream - f26 and now I have nodejs v6 installed. $ node -v
What streams do is that they preserve the version of a component. In our case, nodejs v8 is available but running $ dnf update nodejs
won't update nodejs since there's no update available in the current stream. So how can I switch the stream? Easily, just run $ dnf install nodejs-8
$ node -v
Tada .. I have nodejs v8 on my system now and running dnf update at any time will keep nodejs on the current stream - v8. And what if I want to go back to the default nodejs version? I would simply run $ dnf install nodejs-f26
and I’m back on nodejs v6.
This is one cool feature of modules - streams. Another cool feature comes with profiles. But first let's see what information module actually carries and how DNF works with modules. First, DNF is really cool because of it's plugin-ability and all the module specific magic is included in a dnf plugin called module. Any special actions with modules, additional commands are thus hidden under $ dnf module
.. so what I can for example do is display all information about specific module.
$ dnf module info mariadb
One of the sections called "profiles" shows this
rpms: [mariadb, gettext, mariadb-server]
rpms: [mariadb-server, gettext]
There are 3 available profiles, a default profile that install both client and server packages, server profile that only installs mariadb server and client that installs client. So what I actually want on my system is server and I don’t care about the client package.
$ dnf install mariadb/server
And I’ve got a server! Now what happens when I run $ dnf update mariadb later? I won’t be getting anything else but what I want from the profile. DNF for each module creates a configuration file
$ cat /etc/dnf/modules.d/mariadb.module
name = mariadb
stream = f26
version = 20170707130409
profiles = server
enabled = 1
which keeps track of selected profile and stream. As I’ve already mentioned, DNF module plugin has couple additional commands. One of the allows you to list all installed modules
$ dnf module list --installed
Now you can see the versions, streams and profiles of what you have on your system.
Cool .. isn't it?
All additional information can be found on https://docs.pagure.org/modularity. The syntax of DNF, integration of module metada into other tools such as anaconda and gnome-software are currently at works and hopefully will land for F27.