Il y a longtemps, une distribution Linux fournissait un système d'exploitation avec tous le logiciel disponible pour cela. Il n'y avait pas de concept de logiciel "tiers" car tout faisait partie de la distribution. Les applications n'étaient pas tant installées qu'elles étaient activées à partir d'un grand référentiel de logiciels que vous avez obtenu sur l'une des nombreuses disquettes ou, plus tard, sur des CD que vous avez achetés ou téléchargés.
Cela a évolué pour devenir quelque chose d'encore plus pratique à mesure qu'Internet est devenu omniprésent et que le concept de ce qui est maintenant le "magasin d'applications" est né. Bien sûr, les distributions Linux ont tendance à appeler cela un dépôt de logiciels ou simplement dépôt pour faire court, avec quelques variantes pour "l'image de marque", comme Centre logiciel Ubuntu ou, avec le minimalisme typique de GNOME, simplement Logiciel .
Ce modèle fonctionnait bien à l'époque où les logiciels open source étaient encore une nouveauté et où le nombre d'applications open source était un nombre plutôt qu'une théorique Numéro. Dans le monde actuel de GitLab, GitHub et Bitbucket (et bien d'autres encore), il est difficile de compter le nombre de projets open source, et encore moins de les regrouper dans un référentiel. Aucune distribution Linux aujourd'hui, même Debian et son formidable groupe de mainteneurs de paquets, ne peut prétendre ou espérer avoir un paquet pour chaque projet open source installable.
Bien sûr, un package Linux n'a pas besoin d'être dans un référentiel pour être installable. Tout programmeur peut regrouper son logiciel et le distribuer à partir de son propre site Web. Cependant, comme les référentiels sont considérés comme faisant partie intégrante d'une distribution, il n'existe pas de format d'empaquetage universel, ce qui signifie qu'un programmeur doit décider s'il souhaite publier un .deb ou .rpm , ou un script de construction AUR, ou un package Nix ou Guix, ou un script Homebrew, ou juste un .tgz principalement générique archive pour /opt . C'est écrasant pour un développeur qui vit et respire Linux tous les jours, encore moins pour un développeur qui essaie simplement de faire de son mieux pour prendre en charge une cible libre et open source.
Pourquoi Flatpak ?
Le projet Flatpak fournit un format d'emballage universel ainsi qu'un moyen de distribution décentralisé, plus la portabilité et le bac à sable.
- Universel Installez le système Flatpak et vous pourrez exécuter Flatpaks, quelle que soit votre distribution. Aucun démon ou systemd requis. Le même Flatpak fonctionne sur Fedora, Ubuntu, Mageia, Pop OS, Arch, Slackware, etc.
- Décentralisé Les développeurs peuvent créer et signer leurs propres packages et référentiels Flatpak. Il n'y a pas de référentiel à demander pour obtenir un package inclus.
- Portabilité Si vous avez un Flatpak sur votre système et que vous souhaitez le donner à un ami pour qu'il puisse exécuter la même application, vous pouvez exporter le Flatpak sur une clé USB.
- Sandbox Les flatpaks utilisent un modèle basé sur des conteneurs, permettant à plusieurs versions de bibliothèques et d'applications d'exister sur un seul système. Oui, vous pouvez facilement installer la dernière version d'une application à tester tout en conservant l'ancienne version sur laquelle vous comptez.
Construire un Flatpak
Pour créer un Flatpak, vous devez d'abord installer Flatpak (le sous-système qui vous permet d'utiliser les packages Flatpak) et l'application Flatpak-builder.
Sur Fedora, CentOS, RHEL et similaires :
$ sudo dnf install flatpak flatpak-builderSur Debian, Ubuntu et similaire :
$ sudo apt install flatpak flatpak-builderVous devez également installer les outils de développement requis pour créer l'application que vous empaquetez. De par la nature du développement de l'application que vous empaquetez maintenant, vous avez peut-être déjà installé un environnement de développement, vous ne remarquerez donc peut-être pas que ces composants sont nécessaires, mais si vous commencez à créer des Flatpaks avec Jenkins ou à l'intérieur de conteneurs, vous devez vous assurer que vos outils de construction font partie de votre chaîne d'outils.
Pour le premier exemple de construction, cet article suppose que votre application utilise GNU Autotools, mais Flatpak lui-même prend en charge d'autres systèmes de construction, tels que cmake , cmake-ninja , meson , ant , ainsi que des commandes personnalisées (un simple système de construction, dans la terminologie Flatpak, mais cela n'implique en aucun cas que la construction elle-même est réellement simple).
Répertoire du projet
Contrairement à l'infrastructure de construction RPM stricte, Flatpak n'impose pas de structure de répertoire de projet. Je préfère créer des répertoires de projets basés sur la dist packages de logiciels, mais il n'y a aucune raison technique pour laquelle vous ne pouvez pas intégrer votre processus de construction Flatpak à votre répertoire source. Il est techniquement plus facile de construire un Flatpak à partir de votre dist package, cependant, et c'est aussi une démo plus facile, c'est donc le modèle utilisé par cet article. Configurez un répertoire de projet pour GNU Hello, servant de premier Flatpak :
$ mkdir hello_flatpak
$ mkdir src
Téléchargez votre source distribuable. Pour cet exemple, le code source se trouve à 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
Manifeste
Le Terminal Linux
- Les 7 meilleurs émulateurs de terminaux pour Linux
- 10 outils de ligne de commande pour l'analyse de données sous Linux
- Télécharger maintenant :Aide-mémoire SSH
- Aide-mémoire des commandes Linux avancées
- Tutoriels de ligne de commande Linux
Un Flatpak est défini par un manifeste, qui décrit comment créer et installer l'application qu'il fournit. Un manifeste est atomique et reproductible. Un Flatpak existe cependant dans un conteneur "sandbox", donc le manifeste est basé sur un environnement principalement vide avec un appel de répertoire racine /app .
Les deux premiers attributs sont l'ID de l'application que vous empaquetez et la commande fournie par celle-ci. L'ID d'application doit être unique pour l'application que vous empaquetez. La manière canonique de formuler un identifiant unique consiste à utiliser une valeur de triplet composée de l'entité responsable du code suivie du nom de l'application, telle que org.gnu.Hello . La commande fournie par l'application est ce que vous tapez dans un terminal pour exécuter l'application. Cela n'implique pas que l'application est destinée à être exécutée à partir d'un terminal au lieu d'un .desktop fichier dans le menu Activités ou Applications.
Dans un fichier nommé org.gnu.Hello.yaml , saisissez ce texte :
id: org.gnu.Hello
command: hello
Un manifeste peut être écrit en YAML ou en JSON. Cet article utilise YAML.
Ensuite, vous devez définir chaque "module" fourni par ce package Flatpak. Vous pouvez considérer un module comme une dépendance ou un composant. Pour GNU Hello, il n'y a qu'un seul module :GNU Hello. Des applications plus complexes peuvent nécessiter une bibliothèque spécifique ou une autre application entièrement.
modules:
- name: hello
buildsystem: autotools
no-autogen: true
sources:
- type: archive
path: src/hello-2.10.tar.gz
Le buildsystem La valeur identifie comment Flatpak doit construire le module. Chaque module peut utiliser son propre système de construction, donc un Flatpak peut avoir plusieurs systèmes de construction définis.
Le no-autogen value indique à Flatpak de ne pas exécuter les commandes de configuration pour autotools , qui ne sont pas nécessaires car le code source de GNU Hello est le produit de make dist . Si le code que vous construisez n'est pas sous une forme facile à construire, vous devrez peut-être installer autogen et autoconf pour préparer la source pour autotools . Cette option ne s'applique pas du tout aux projets qui n'utilisent pas autotools .
Le type value indique à Flatpak que le code source se trouve dans une archive, ce qui déclenche les tâches de désarchivage requises avant la construction. Le path pointe vers le code source. Dans cet exemple, la source existe dans le src répertoire sur votre machine de construction locale, mais vous pouvez à la place définir la source comme un emplacement distant :
modules:
- name: hello
buildsystem: autotools
no-autogen: true
sources:
- type: archive
url: https://ftp.gnu.org/gnu/hello/hello-2.10.tar.gz
Enfin, vous devez définir la plate-forme requise pour l'exécution et la génération de l'application. Les responsables de Flatpak fournissent des runtimes et des SDK qui incluent des bibliothèques communes, y compris freedesktop , gnome , et kde . L'exigence de base est le freedesk runtime et SDK, bien que cela puisse être remplacé par GNOME ou KDE, selon ce dont votre code a besoin pour s'exécuter. Pour cet exemple GNU Hello, seules les bases sont requises.
runtime: org.freedesktop.Platform
runtime-version: '18.08'
sdk: org.freedesktop.Sdk
L'intégralité du manifeste flatpak GNU Hello :
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
Construire un Flatpak
Maintenant que le package est défini, vous pouvez le construire. Le processus de construction invite Flatpak-builder à analyser le manifeste et à résoudre chaque exigence :il garantit que la plate-forme et le SDK nécessaires sont disponibles (s'ils ne le sont pas, vous devrez les installer avec le flatpak commande), il désarchive le code source et exécute la commande buildsystem spécifié.
La commande pour démarrer :
$ flatpak-builder build-dir org.gnu.Hello.yaml
Le répertoire build-dir est créé s'il n'existe pas déjà. Le nom build-dir est arbitraire ; vous pourriez l'appeler build ou bld ou penguin , et vous pouvez avoir plusieurs destinations de génération dans le même répertoire de projet. Cependant, le terme build-dir est une valeur fréquemment utilisée dans la documentation, il peut donc être utile de l'utiliser comme valeur littérale.
Tester votre application
Vous pouvez tester votre application avant ou après sa construction en exécutant la commande build avec le --run et terminez la commande avec la commande fournie par le Flatpak :
$ flatpak-builder --run build-dir \
org.gnu.Hello.yaml hello
Hello, world!
Packaging des applications GUI avec Flatpak
Empaqueter un monde hello autonome et simple l'application est triviale, et heureusement, empaqueter une application graphique n'est pas beaucoup plus difficile. Les applications les plus difficiles à empaqueter sont celles qui ne reposent pas sur des bibliothèques et des frameworks communs (dans le contexte de l'empaquetage, "commun" signifie tout non déjà emballé par quelqu'un d'autre). La communauté Flatpak fournit des SDK et des extensions de SDK pour de nombreux composants que vous auriez peut-être dû empaqueter vous-même. Par exemple, lors de l'empaquetage de l'implémentation Java pure de pdftk , j'utilise l'extension OpenJDK SDK que j'ai trouvée dans le dépôt Flatpak Github :
runtime: org.freedesktop.Platform
runtime-version: '18.08'
sdk: org.freedesktop.Sdk
sdk-extensions:
- org.freedesktop.Sdk.Extension.openjdk11
La communauté Flatpak travaille beaucoup sur les fondations requises pour que les applications s'exécutent afin de faciliter le processus d'empaquetage pour les développeurs. Par exemple, le jeu Kblocks de la communauté KDE nécessite l'exécution de la plate-forme KDE, qui est déjà disponible auprès de Flatpak. Les libkdegames supplémentaires la bibliothèque n'est pas incluse, mais il est aussi facile de l'ajouter à votre liste de modules comme kblocks lui-même.
Voici un manifeste pour le jeu Kblocks :
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
Comme vous pouvez le voir, le manifeste est toujours simple et relativement intuitif. Le système de construction est différent, et le runtime et le SDK pointent vers KDE au lieu de Freedesktop, mais la structure et les exigences sont fondamentalement les mêmes.
Cependant, comme il s'agit d'une application graphique, de nouvelles options sont requises. Tout d'abord, il a besoin d'une icône pour que, lorsqu'elle est répertoriée dans le menu Activités ou Application, elle soit belle et reconnaissable. Kblocks inclut une icône dans ses sources, mais les noms des fichiers exportés par un Flatpak doivent être préfixés à l'aide de l'ID de l'application (comme org.kde.Kblocks.desktop ). Pour ce faire, le moyen le plus simple consiste à renommer le fichier directement dans la source de l'application, ce que Flatpak peut faire pour vous tant que vous incluez cette directive dans votre manifeste :
rename-icon: kblocksUn autre trait unique des applications GUI est qu'elles nécessitent souvent une intégration avec des services de bureau courants, comme le serveur graphique (X11 ou Wayland) lui-même, un serveur audio tel que Pulse Audio et le sous-système de communication inter-processus (IPC).
Dans le cas de Kblocks, les exigences sont :
finish-args:
- --share=ipc
- --socket=x11
- --socket=wayland
- --socket=pulseaudio
- --device=dri
- --filesystem=xdg-config/kdeglobals:ro
Voici le manifeste final et complet, utilisant des URL pour les sources afin que vous puissiez l'essayer facilement sur votre propre système :
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
Pour construire l'application, vous devez avoir installé la plate-forme KDE et les Flatpaks SDK (version 5.13 au moment de la rédaction de cet article). Une fois l'application construite, vous pouvez l'exécuter en utilisant le --run méthode, mais pour voir l'icône de l'application, vous devez l'installer.
Distribuer et installer un Flatpak que vous avez construit
La distribution de flatpaks se fait via des référentiels.
Vous pouvez répertorier vos applications sur Flathub.org, un site Web communautaire conçu comme un techniquement emplacement décentralisé (mais central dans l'esprit) pour Flatpaks. Pour soumettre votre Flatpak, placez votre manifeste dans un référentiel Git et soumettez une demande d'extraction sur Github.
Alternativement, vous pouvez créer votre propre référentiel en utilisant le flatpak build-export commande.
Vous pouvez également simplement installer localement :
$ flatpak-builder --force-clean --install build-dir org.kde.Kblocks.yamlUne fois installé, ouvrez votre menu Activités ou Applications et recherchez Kblocks.
En savoir plus
Le site de documentation Flatpak propose une bonne procédure pas à pas pour créer votre premier Flatpak. Cela vaut la peine de le lire même si vous avez suivi cet article. En outre, les documents fournissent des détails sur les plates-formes et les SDK disponibles.
Pour ceux qui aiment apprendre à partir d'exemples, il existe des manifestes pour chaque application disponible sur Flathub.
Les ressources pour créer et utiliser Flatpaks sont nombreuses, et Flatpak, ainsi que les conteneurs et les applications en bac à sable, sont sans doute l'avenir, alors familiarisez-vous avec eux, commencez à les intégrer à vos pipelines Jenkins et profitez d'un package d'applications Linux simple et universel.