Modularity & Generational Core

by Petr abata and Adam amalk

The future of Fedora?

Distributionsare great!

Why are distros great?Ship packaged softwareDependencies includedIntegrated and testedPatched for security vulnerabilities

Distros have a life span

Everything is supported forthe same time!

but... which is fine,

Applications arereleased at their

own pace.

(independent of the distribution)

And applications cancome in multiple

versions.

(different variants or different generations)

But distributionsship just a single

version of anapplication for each

release.

(mostly because of conflicting dependencies)

So how to choosethe right version?

Fast updates

& latest versio

ns? Slowupdates

&stable

versions?

What is better?

That's right!

All of them!

But howto include multiple

versions?

(providing multiple versions of software in a distribution)

Option one:

Fast track + LTS

Option two:

SoftwareCollections

(providing multiple versions of software in a distribution)

Option three:

LinuxContainers

(providing multiple versions of software in a distribution)

Option four:

Modularity!

(providing multiple versions of software in a distribution)

Introducing tinysystem calledBase Runtime

Includes the kernel, glibc, and other basic tools and

libraries with proven long-term ABI stability.

Software runs onBase Runtimeas a Module.

Similar concept to Android or iPhone apps.

Modules are groupsof packages with

a purpose.

Like a database, Firefox, or a LAMP stack.

Anatomy of a Module

Modules are definedby a modulemd file.

Defining its components, an API, a build recipe,

and install profiles.

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

document: modulemdversion: 1data: # 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/

Modules are builtin the Factory 2.0

Modules aredelivered 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 thecurrent userworkflow!

Howthat works?

We focus on the package

Don't build distroversions...

Build module streams!

Modules come inmultiple streams.

Major versions or variants of an application.

You choosethe right streams

before installation.

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

DNF keeps yoursystem updatedwhile preserving

compatibility.

So "$ dnf update" works!

...so that will themodular distro!

https://fedoraproject.org/wiki/Modularity