Modularity

by Adam Šamalík

The future of Fedora?

Distributions

are great!

Why are distros great?

  • Ship packaged software
  • Dependencies included
  • Integrated and tested
  • Patched for security vulnerabilities

Distros have a life span

Everything is supported for the same time!

but

... which is fine,

Applications are released at their
own pace.

 

(independent of the distribution)

And applications can come in multiple versions.

 

(different variants or different generations)

But distributions ship just a single
version of an application for each release.

 

(mostly because of conflicting dependencies)

So how to choose the right version?

Fast updates

& latest versions?

Slow updates &

stable versions?

What is better?

That's right!

All of them!

But how

to include multiple versions?

(providing multiple versions of software in a distribution)

Option one:

Fast track + LTS

Option two:

Software Collections

(providing multiple versions of software in a distribution)

Option three:

Linux Containers

(providing multiple versions of software in a distribution)

Option four:

Modularity!

(providing multiple versions of software in a distribution)

Introducing tiny system called
Base Runtime

 

Includes the kernel, glibc, and other basic tools and libraries with proven long-term ABI stability.

Software runs on
Base Runtime
as a Module.

 

Similar concept to Android or iPhone apps.

Modules are groups of packages with
a purpose.

 

Like a database, Firefox, or a LAMP stack.

Anatomy of a Module

Modules are defined by a modulemd file.

 

Defining its components, an API, a build recipe,
and install profiles.

 

 

"Stop it! We want to see some code, Adam!"

document: modulemd
version: 1
data:
    # An ID of the module.
    name: foo
    stream: stream-name
    version: 20160927144203

    # What's the module about?
    summary: An example module
    description: >
        A module for the demonstration of the metadata format. Also,
        the obligatory lorem ipsum dolor sit amet goes right here.

    # How can I use it? How can I change it? Can I sell it?
    license:
        module:
            - MIT
        content:
            - Beerware
            - GPLv2+

    # Where does it live?
    references:
        community: http://www.example.com/
        documentation: http://www.example.com/
        tracker: http://www.example.com/

    # Some extra metadata can be here.
    xmd: ~

    # What do we need to build and run this module?
    dependencies:
        buildrequires:
            base-runtime: stream-name
            base-runtime-build: stream-name
        requires:
            base-runtime: stream-name

    # What sources we want to build? In which order?
    components:
        rpms:
            bar:
                rationale: We need this to demonstrate stuff.
                ref: f26
            baz:
                rationale: This one is here to demonstrate other stuff.
		ref: f24
            xyz:
                rationale: xyz is a bundled dependency of baz.
		ref: f24
                buildorder: 10

        modules:
            includedmodule:
                rationale: Included in the stack, just because.
                ref: stream-name
                buildorder: 100

    # Any binary packages we don't want to include?
    filter:
        rpms:
            - baz-nonfoo

    # Which packages are the reason this module exists?
    # (Other packages are just dependencies,
    #    treated like an implementation detail.)
    api:
        rpms:
            - bar
            - bar-extras
	    - baz

    # Ways to install this module.
    profiles:
        default:
            description: Normal instalation
            rpms:
                - bar
                - bar-extras
		- baz
        minimal:
            description: Minimal instalation.
            rpms:
                - bar

Modules are built
in the Factory 2.0

Modules are delivered as various artifacts.

 

Like an RPM repository, Linux Container, Flatpak, OSTree, ISO, etc.

Running modules

RPMs? Containers?
I don't care!

$ dnf install httpd
$ dnf install httpd
...

$ vim /etc/httpd/configuration.file
$ dnf install httpd
...

$ vim /etc/httpd/configuration.file
...

$ vim /var/www/index.html
$ dnf install httpd
...

$ vim /etc/httpd/configuration.file
...

$ vim /var/www/index.html
...

$ systemctl start httpd
$ dnf install httpd
...

$ vim /etc/httpd/configuration.file
...

$ vim /var/www/index.html
...

$ systemctl start httpd

#.... few days later ....

$ dnf update

No changes to the current user workflow!

How
that works?

We focus on the package

Don't build distro versions...

Build module streams!

Modules come in multiple streams.

 

Major versions or variants of an application.

You choose
the right streams before installation.

 

Or get an iso with pre-selected streams - similar to the current situation.

DNF keeps your system updated while preserving
compatibility.

 

So "$ dnf update" works!

...so that will the
modular distro

https://docs.pagure.org/Modularity