A Distribution Approach to Building Flatpaks Owen Taylor Red Hat Devconf.Cz 2018 Flatpak Review

A distribution approach to building Flatpaks Owen Taylor Red Hat DevConf.cz 2018 Flatpak Review

App App OS GIMP Libraries tuxkart Libraries Init Display Kernel System Server Runtime Libraries Libraries

App App

Scribus Libraries Chrome Libraries

Runtime Libraries Flatpak Review

App /app GIMP Libraries

Runtime Libraries /usr “Upstream” approach to Runtimes and Flatpaks

● Runtime is built from source (yocto-based, perhaps) ● Build also produces SDK ● Flatpaks are built using flatpak-builder “Distribution” approach to Runtimes and Flatpaks

● Runtime (/usr) is composed from packages ● Applications (/app) are composed from rebuilt packages Why?

● Security process ● Stability and support guarantees ● “Back catalog” of build instructions for thousands of packages Flatpaks in Fedora

● Modularity ● Build Flatpaks as OCI images ● Build like containers, release like containers ● Distribute like containers (registry.fedoraproject.org) Modularity

● Break apart the global package space ● Allow rebuilding the same sources with prefix=/app ● Allow package to specify some other version of a library than the global F27 version Flatpak and OCI

● Original format for Flatpak distribution is ostree ○ “git for binaries” ● But can also distribute as OCI container images ● Evolution of the Docker format ○ https://www.opencontainers.org/ ● Advantages: ○ Treat it just like a server container ○ Avoid lots of small files OSTree OSTree Docker/OCI Repository Repository Registry

Flatpak

GNOME Software Step 0 - creating the module files

Packager creates, in dist-git/modules/eog

● eog.yaml ○ “ModuleMD” file - lists rpms and versions in the module ● container.yaml ○ Describes how to build module into a container ● flatpak.json ○ Contains flatpaks-specific metadata ○ merge into container.yaml???

Initial pass done using ‘fedmod rpm2module’ document: modulemd version: 1 eog.yaml data: summary: Eye of GNOME Application Module description: The Eye of GNOME image viewer (eog) is the official image viewer for the GNOME desktop [...] license: module: [ MIT ] dependencies: buildrequires: flatpak-runtime: f28 requires: flatpak-runtime: f28 profiles: default: rpms: - eog components: rpms: eog.yaml eog: rationale: Core application ref: f28 buildorder: 3 exempi: rationale: Dependency ref: f28 buildorder: 2 libexif: rationale: Dependency ref: f28 buildorder: 2 glade: rationale: Build dependency for libpeas ref: f28 buildorder: 1 libpeas: rationale: Dependency ref: f28 buildorder: 2 { "id": "org.gnome.eog", flatpak.json "runtime": "org.fedoraproject.Platform", "runtime-version": "26", "command": "eog", "tags": ["Viewer"], "finish-args": ["--filesystem=host", "--share=ipc", "--socket=x11", "--socket=wayland", "--socket=session-bus", "--filesystem=~/.config/dconf:ro", "--filesystem=xdg-run/dconf", "--talk-name=ca.desrt.dconf", "--env=DCONF_USER_CONFIG_DIR=.config/dconf"] }

man flatpak-build-finish modules: - eog:f28 container.yaml Step 1 - building the packages

● Fedora packager runs ‘fedpkg module-build’ ● Module Build Service (MBS) reads /modules/inkscape/inkscape.yaml ● MBS creates a tag within koji, builds all the rpms ● Stores metadata about the result in the Product Definition Center Step 2 - building the Flatpak

● Fedora packager runs ‘fedpkg flatpak-build’ ● This starts an image build within the Fedora Layered Image Build Service (also known as OSBS) ● Resulting OCI images are stored in candidate.registry.fedoraproject.org ● Can be installed and tested Step 3 - pushing to stable

● Bodhi update is created for the Flatpak ● automated , manual testing happens ● Bodhi pushes image from from candidate.registry.fedoraproject.org to registry.fedoraproject.org Runtimes

Single flatpak-runtime module with four profiles

● runtime-base ● sdk-base ● runtime ● sdk

Built in the same way into Flatpak OCI Images. Flagstate - Registry Metadata Service

● GNOME Software needs complete metadata about available flatpaks to: ○ Display browsing interface ○ Check for updates ● Flagstate sits beside registry ○ Harvests metadata ○ Stores in database ○ Responds to queries The build pipeline Flagstate Flagstate (registry (registry index) index) PDC metadata image Candidate Registry metadata metadata ODCS Registry

packages koji Bodhi image Layered Modular Image Build Build GNOME Service Service Software spec files (MBS) (OSBS)

modulemd container.yaml, flatpak.json

dist-git Automation

● Desirable to not have to do this manually when component RPMs change ● Freshmaker watches commits and automatically rebuilds packages and modules

Still in planning... Status

Live: Not yet written ● OCI support in Flatpak ● rpm2module for flatpaks Done, not yet deployed: (soon!) ● Automated rebuilds ● Flatpak support in OSBS ● Signing ● OCI support for registry.fedoraproject.org ● fedpkg integration ● Registry index (flagstate) ● Registry index support in Flatpak Questions? https://fedoraproject.org/wiki/Workstation/Flatpaks