Wie man ein Flatpak baut

Vor langer Zeit lieferte eine Linux-Distribution ein Betriebssystem zusammen mit allem aus die dafür verfügbare Software. Es gab kein Konzept für Software von „Drittanbietern“, da alles Teil der Distribution war. Anwendungen wurden nicht so sehr installiert, sondern aus einem großen Software-Repository aktiviert, das Sie auf einer der vielen Disketten oder später CDs, die Sie gekauft oder heruntergeladen haben, erhalten haben.

Dies entwickelte sich zu etwas noch Praktischerem, als das Internet allgegenwärtig wurde und das Konzept des heutigen „App Store“ geboren wurde. Linux-Distributionen nennen dies natürlich Software-Repository oder einfach nur repo kurz gesagt, mit einigen Variationen für „Branding“, wie z. B. Ubuntu Software Center oder, mit typischem GNOME-Minimalismus, einfach Software .

Dieses Modell funktionierte gut, als Open-Source-Software noch ein Novum war und die Anzahl der Open-Source-Anwendungen eher eine Zahl als eine theoretische war Anzahl. In der heutigen Welt von GitLab und GitHub und Bitbucket (und vielen, vielen mehr) ist es kaum möglich, die Anzahl der Open-Source-Projekte zu zählen, geschweige denn, sie in ein Repository zu packen. Keine heutige Linux-Distribution, nicht einmal Debian und seine beeindruckende Gruppe von Paketbetreuern, kann behaupten oder hoffen, ein Paket für jedes installierbare Open-Source-Projekt zu haben.

Natürlich muss sich ein Linux-Paket nicht in einem Repository befinden, um installierbar zu sein. Jeder Programmierer kann seine Software paketieren und über seine eigene Website verteilen. Da Repositories jedoch als integraler Bestandteil einer Distribution angesehen werden, gibt es kein universelles Paketierungsformat, was bedeutet, dass ein Programmierer entscheiden muss, ob er eine .deb veröffentlicht oder .rpm , oder ein AUR-Build-Skript, oder ein Nix- oder Guix-Paket, oder ein Homebrew-Skript, oder einfach eine meist generische .tgz Archiv für /opt . Es ist überwältigend für einen Entwickler, der Linux jeden Tag lebt und atmet, geschweige denn für einen Entwickler, der nur versucht, nach besten Kräften zu versuchen, ein kostenloses und Open-Source-Ziel zu unterstützen.

Warum Flatpak?

Das Flatpak-Projekt bietet ein universelles Verpackungsformat zusammen mit einer dezentralisierten Verteilungsmethode sowie Portabilität und Sandboxing.

Universell Installieren Sie das Flatpak-System, und Sie können Flatpaks unabhängig von Ihrer Distribution ausführen. Kein Daemon oder Systemd erforderlich. Das gleiche Flatpak läuft auf Fedora, Ubuntu, Mageia, Pop OS, Arch, Slackware und mehr.
Dezentral Entwickler können ihre eigenen Flatpak-Pakete und Repositories erstellen und signieren. Es gibt kein Repository, bei dem eine Petition eingereicht werden muss, um ein Paket aufzunehmen.
Portabilität Wenn Sie ein Flatpak auf Ihrem System haben und es an einen Freund weitergeben möchten, damit dieser dieselbe Anwendung ausführen kann, können Sie das Flatpak auf einen USB-Stick exportieren.
Sandbox Flatpaks verwenden ein containerbasiertes Modell, sodass mehrere Versionen von Bibliotheken und Anwendungen auf einem System vorhanden sein können. Ja, Sie können ganz einfach die neueste Version einer App zum Testen installieren und gleichzeitig die alte Version, auf die Sie sich verlassen, beibehalten.

Erstellen eines Flatpaks

Um ein Flatpak zu erstellen, müssen Sie zunächst Flatpak (das Subsystem, das Ihnen die Verwendung von Flatpak-Paketen ermöglicht) und die Flatpak-Builder-Anwendung installieren.

Unter Fedora, CentOS, RHEL und ähnlichen:

$ sudo dnf install flatpak flatpak-builder

Unter Debian, Ubuntu und ähnlichen:

$ sudo apt install flatpak flatpak-builder

Sie müssen auch die Entwicklungstools installieren, die zum Erstellen der Anwendung, die Sie packen, erforderlich sind. Aufgrund der Art der Entwicklung der Anwendung, die Sie jetzt packen, haben Sie möglicherweise bereits eine Entwicklungsumgebung installiert, sodass Sie möglicherweise nicht bemerken, dass diese Komponenten erforderlich sind. Sollten Sie jedoch mit dem Erstellen von Flatpaks mit Jenkins oder aus Containern beginnen, müssen Sie dies sicherstellen Ihre Build-Tools sind Teil Ihrer Toolchain.

Für den ersten Beispiel-Build geht dieser Artikel davon aus, dass Ihre Anwendung GNU Autotools verwendet, aber Flatpak selbst unterstützt andere Build-Systeme wie cmake , cmake-ninja , Meson , ameise , sowie benutzerdefinierte Befehle (eine einfache Build-System, in der Flatpak-Terminologie, aber das bedeutet keineswegs, dass der Build selbst wirklich einfach ist).

Projektverzeichnis

Anders als die strikte RPM-Build-Infrastruktur erzwingt Flatpak keine Projektverzeichnisstruktur. Ich ziehe es vor, Projektverzeichnisse basierend auf dist zu erstellen Softwarepakete, aber es gibt keinen technischen Grund, warum Sie Ihren Flatpak-Build-Prozess nicht stattdessen in Ihr Quellverzeichnis integrieren können. Es ist technisch einfacher, ein Flatpak aus Ihrem dist zu erstellen Paket, und es ist auch eine einfachere Demo, also ist das das Modell, das dieser Artikel verwendet. Richten Sie ein Projektverzeichnis für GNU Hello ein, das als Ihr erstes Flatpak dient:

$ mkdir hello_flatpak

$ mkdir src

Laden Sie Ihre verteilbare Quelle herunter. Für dieses Beispiel befindet sich der Quellcode unter https://ftp.gnu.org/gnu/hello/hello-2.10.tar.gz .

$ cd hello_flatpak

$ wget https://ftp.gnu.org/gnu/hello/hello-2.10.tar.gz

Manifest

Das Linux-Terminal

Die 7 besten Terminalemulatoren für Linux
10 Befehlszeilentools für die Datenanalyse unter Linux
Jetzt herunterladen:SSH-Spickzettel
Spickzettel für fortgeschrittene Linux-Befehle
Linux-Befehlszeilen-Tutorials

Ein Flatpak wird durch ein Manifest definiert, das beschreibt, wie die bereitgestellte Anwendung erstellt und installiert wird. Ein Manifest ist atomar und reproduzierbar. Ein Flatpak existiert jedoch in einem „Sandbox“-Container, sodass das Manifest auf einer größtenteils leeren Umgebung mit einem Root-Verzeichnisaufruf /app basiert .

Die ersten beiden Attribute sind die ID der Anwendung, die Sie packen, und der von ihr bereitgestellte Befehl. Die Anwendungs-ID muss für die Anwendung, die Sie packen, eindeutig sein. Die kanonische Art, eine eindeutige ID zu formulieren, besteht darin, einen Triplettwert zu verwenden, der aus der Entität besteht, die für den Code verantwortlich ist, gefolgt vom Namen der Anwendung, z. B. org.gnu.Hello . Der von der Anwendung bereitgestellte Befehl ist das, was Sie in ein Terminal eingeben, um die Anwendung auszuführen. Dies bedeutet nicht, dass die Anwendung von einem Terminal statt von einem .desktop ausgeführt werden soll Datei im Menü "Aktivitäten" oder "Anwendungen".

In einer Datei namens org.gnu.Hello.yaml , geben Sie diesen Text ein:

id: org.gnu.Hello

command: hello

Ein Manifest kann in YAML oder in JSON geschrieben werden. Dieser Artikel verwendet YAML.

Als nächstes müssen Sie jedes „Modul“ definieren, das von diesem Flatpak-Paket geliefert wird. Sie können sich ein Modul als eine Abhängigkeit oder eine Komponente vorstellen. Für GNU Hello gibt es nur ein Modul:GNU Hello. Komplexere Anwendungen erfordern möglicherweise eine bestimmte Bibliothek oder eine ganz andere Anwendung.

modules:

  - name: hello

    buildsystem: autotools

    no-autogen: true

    sources:

      - type: archive

        path: src/hello-2.10.tar.gz

Das Buildsystem value gibt an, wie Flatpak das Modul erstellen muss. Jedes Modul kann sein eigenes Build-System verwenden, sodass für ein Flatpak mehrere Build-Systeme definiert sein können.

Das no-autogen value weist Flatpak an, die Setup-Befehle für autotools nicht auszuführen , die nicht erforderlich sind, da der Quellcode von GNU Hello das Produkt von make dist ist . Wenn der von Ihnen erstellte Code nicht in einer einfach zu erstellenden Form vorliegt, müssen Sie möglicherweise autogen installieren und autoconf um den Quellcode für autotools vorzubereiten . Diese Option gilt überhaupt nicht für Projekte, die autotools nicht verwenden .

Der Typ Der Wert teilt Flatpak mit, dass sich der Quellcode in einem Archiv befindet, wodurch die erforderlichen Dearchivierungsaufgaben vor dem Erstellen ausgelöst werden. Der Pfad verweist auf den Quellcode. In diesem Beispiel existiert die Quelle in src Verzeichnis auf Ihrem lokalen Build-Rechner, aber Sie könnten stattdessen die Quelle als Remote-Speicherort definieren:

modules:

  - name: hello

    buildsystem: autotools

    no-autogen: true

    sources:

      - type: archive

        url: https://ftp.gnu.org/gnu/hello/hello-2.10.tar.gz

Schließlich müssen Sie die Plattform definieren, die für die Ausführung und Erstellung der Anwendung erforderlich ist. Die Flatpak-Betreuer stellen Laufzeiten und SDKs bereit, die allgemeine Bibliotheken enthalten, einschließlich freedesktop , gnome , und kde . Grundvoraussetzung ist das freedesk Runtime und SDK, obwohl dies möglicherweise durch GNOME oder KDE ersetzt wird, je nachdem, was Ihr Code zum Ausführen benötigt. Für dieses GNU-Hello-Beispiel sind nur die Grundlagen erforderlich.

runtime: org.freedesktop.Platform

runtime-version: '18.08'

sdk: org.freedesktop.Sdk

Das gesamte GNU Hello Flatpak-Manifest:

id: org.gnu.Hello

runtime: org.freedesktop.Platform

runtime-version: '18.08'

sdk: org.freedesktop.Sdk

command: hello

modules:

  - name: hello

    buildsystem: autotools

    no-autogen: true

    sources:

      - type: archive

        path: src/hello-2.10.tar.gz

Erstellen eines Flatpaks

Nachdem das Paket definiert ist, können Sie es erstellen. Der Build-Prozess fordert den Flatpak-Builder auf, das Manifest zu parsen und jede Anforderung zu lösen:Er stellt sicher, dass die erforderliche Plattform und das SDK verfügbar sind (wenn dies nicht der Fall ist, müssen Sie sie mit dem flatpak Befehl), es dearchiviert den Quellcode und führt das buildsystem aus angegeben.

 
 Der Befehl zum Starten:
 $ flatpak-builder build-dir org.gnu.Hello.yaml
 
 Das Verzeichnis build-dir erstellt, falls noch nicht vorhanden. Der Name build-dir ist willkürlich; man könnte es build nennen oder bld oder Pinguin , und Sie können mehr als ein Buildziel im selben Projektverzeichnis haben. Der Begriff build-dir ist ein häufig verwendeter Wert in der Dokumentation, daher kann es hilfreich sein, ihn als wörtlichen Wert zu verwenden.
 Testen Ihrer Anwendung
 
 Sie können Ihre Anwendung testen, bevor oder nachdem sie erstellt wurde, indem Sie den build-Befehl zusammen mit --run ausführen Option und beenden Sie den Befehl mit dem vom Flatpak bereitgestellten Befehl:
 $ flatpak-builder --run build-dir \

org.gnu.Hello.yaml hello

Hello, world!
 Verpacken von GUI-Apps mit Flatpak
 
 Verpacken Sie ein einfaches, in sich geschlossenes Hallo Welt Anwendung ist trivial, und glücklicherweise ist das Packen einer GUI-Anwendung nicht viel schwieriger. Die am schwierigsten zu paketierenden Anwendungen sind diejenigen, die nicht auf gemeinsame Bibliotheken und Frameworks angewiesen sind (im Kontext des Paketierens bedeutet „allgemein“ alles, was nicht ist bereits von jemand anderem verpackt). Die Flatpak-Community bietet SDKs und SDK-Erweiterungen für viele Komponenten, die Sie andernfalls möglicherweise selbst paketieren müssten. Zum Beispiel beim Packen der reinen Java-Implementierung von pdftk , verwende ich die OpenJDK SDK-Erweiterung, die ich im Flatpak Github-Repository gefunden habe:
 runtime: org.freedesktop.Platform

runtime-version: '18.08'

sdk: org.freedesktop.Sdk

sdk-extensions:

  - org.freedesktop.Sdk.Extension.openjdk11
 
 Die Flatpak-Community arbeitet viel an den Grundlagen, die für die Ausführung von Anwendungen erforderlich sind, um den Paketierungsprozess für Entwickler zu vereinfachen. Zum Beispiel erfordert das Kblocks-Spiel aus der KDE-Community die Ausführung der KDE-Plattform, und die ist bereits bei Flatpak erhältlich. Die zusätzlichen libkdegames Bibliothek ist nicht enthalten, aber es ist genauso einfach, sie zu Ihrer Liste von Modulen hinzuzufügen als kblocks selbst.
 
 Hier ist ein Manifest für das Kblocks-Spiel:
 id: org.kde.kblocks

command: kblocks

modules:

- buildsystem: cmake-ninja

  name: libkdegames

  sources:

    type: archive

    path: src/libkdegames-19.08.2.tar.xz

- buildsystem: cmake-ninja

  name: kblocks

  sources:

    type: archive

    path: src/kblocks-19.08.2.tar.xz

runtime: org.kde.Platform

runtime-version: '5.13'

sdk: org.kde.Sdk
 
 Wie Sie sehen können, ist das Manifest immer noch unkompliziert und relativ intuitiv. Das Build-System ist anders, und die Laufzeit und das SDK verweisen auf KDE statt auf Freedesktop, aber die Struktur und die Anforderungen sind im Grunde gleich.
 
 Da es sich jedoch um eine GUI-Anwendung handelt, sind einige neue Optionen erforderlich. Erstens braucht es ein Symbol, damit es schön und erkennbar aussieht, wenn es im Aktivitäten- oder Anwendungsmenü aufgeführt wird. Kblocks enthält ein Symbol in seinen Quellen, aber den Namen von Dateien, die von einem Flatpak exportiert werden, muss die Anwendungs-ID vorangestellt werden (z. B. org.kde.Kblocks.desktop ). Der einfachste Weg, dies zu tun, besteht darin, die Datei direkt in der Anwendungsquelle umzubenennen, was Flatpak für Sie tun kann, solange Sie diese Direktive in Ihr Manifest aufnehmen:
 rename-icon: kblocks
 
 Ein weiteres einzigartiges Merkmal von GUI-Anwendungen ist, dass sie häufig eine Integration mit gängigen Desktop-Diensten erfordern, wie dem Grafikserver (X11 oder Wayland) selbst, einem Soundserver wie Pulse Audio und dem Subsystem Inter-Process Communication (IPC).
 
 Im Fall von Kblocks lauten die Anforderungen:
 finish-args:

- --share=ipc

- --socket=x11

- --socket=wayland

- --socket=pulseaudio

- --device=dri

- --filesystem=xdg-config/kdeglobals:ro
 
 Hier ist das endgültige, vollständige Manifest mit URLs für die Quellen, damit Sie dies problemlos auf Ihrem eigenen System ausprobieren können:
 command: kblocks

finish-args:

- --share=ipc

- --socket=x11

- --socket=wayland

- --socket=pulseaudio

- --device=dri

- --filesystem=xdg-config/kdeglobals:ro

id: org.kde.kblocks

modules:

- buildsystem: cmake-ninja

  name: libkdegames

  sources:

  - sha256: 83456cec44502a1f79c0be00c983090e32fd8aea5fec1461fbfbd37b5f8866ac

    type: archive

    url: https://download.kde.org/stable/applications/19.08.2/src/libkdegames-19.08.2.tar.xz

- buildsystem: cmake-ninja

  name: kblocks

  sources:

  - sha256: 8b52c949e2d446a4ccf81b09818fc90234f2f55d8722c385491ee67e1f2abf93

    type: archive

    url: https://download.kde.org/stable/applications/19.08.2/src/kblocks-19.08.2.tar.xz

rename-icon: kblocks

runtime: org.kde.Platform

runtime-version: '5.13'

sdk: org.kde.Sdk
 
 Um die Anwendung zu erstellen, müssen Sie die KDE-Plattform und SDK Flatpaks (Version 5.13 zum Zeitpunkt dieses Schreibens) installiert haben. Nachdem die Anwendung erstellt wurde, können Sie sie mit --run ausführen Methode, aber um das Anwendungssymbol zu sehen, müssen Sie es installieren.
 Verteilen und Installieren eines von Ihnen erstellten Flatpaks
 
 Die Verteilung von Flatpaks erfolgt über Repositories.
 
 Sie können Ihre Apps auf Flathub.org auflisten, einer Community-Website, die technisch gemeint ist dezentraler (aber zentraler) Standort für Flatpaks. Um Ihr Flatpak einzureichen, platzieren Sie Ihr Manifest in einem Git-Repository und senden Sie eine Pull-Anfrage auf Github.
 
 Alternativ können Sie Ihr eigenes Repository mit flatpak build-export erstellen Befehl.
 
 Sie können auch einfach lokal installieren:
 $ flatpak-builder --force-clean --install build-dir org.kde.Kblocks.yaml
 
 Öffnen Sie nach der Installation Ihr Aktivitäten- oder Anwendungsmenü und suchen Sie nach Kblocks.
 
  
 Mehr lernen
 
 Die Flatpak-Dokumentationsseite bietet eine gute Anleitung zum Erstellen Ihres ersten Flatpak. Es lohnt sich zu lesen, auch wenn Sie diesen Artikel gelesen haben. Außerdem enthalten die Dokumente Details zu den verfügbaren Plattformen und SDKs.
 
 Für diejenigen, die gerne von Beispielen lernen, gibt es Manifeste für jede Anwendung verfügbar auf Flathub.
 
 Die Ressourcen zum Erstellen und Verwenden von Flatpaks sind reichlich vorhanden, und Flatpak ist zusammen mit Containern und Sandbox-Apps wohl die Zukunft. Machen Sie sich also mit ihnen vertraut, integrieren Sie sie in Ihre Jenkins-Pipelines und genießen Sie die einfache und universelle Paketierung von Linux-Apps.