une nouvelle branche stable de l'outil , qui fournit un système pour la création de paquets autonomes, indépendants des distributions Linux spécifiques et s'exécutant dans un conteneur spécial, isolant l'application du reste du système. La prise en charge de l'exécution des paquets Flatpak est assurée pour Arch Linux, , Debian, Fedora, Gentoo, Mageia, Linux Mint et Ubuntu. Les paquets Flatpak sont inclus dans le dépôt Fedora et pris en charge par le gestionnaire d'applications GNOME par défaut.
Améliorations clés dans la branche Flatpak 1.4 :
- L'organisation des paramètres des dépôts externes a été modifiée. Dans le répertoire /etc/flatpak/remotes.d, au lieu de fichiers *.conf de configuration, il s'agit désormais de fichiers classiques « .flatpakrepo », qui sont automatiquement importés lors de la première utilisation de flatpak. Ces fichiers peuvent être librement modifiés et supprimés, de la même manière que les dépôts ajoutés manuellement ;
- L'organisation des installations de paquets disponibles pour l'ensemble du système a été considérablement modifiée. Dans les précédentes versions, le paquet était d'abord installé dans un répertoire temporaire appartenant à l'utilisateur, puis le processus system-helper était appelé pour importer dans le système à partir de ce répertoire. Cette approche entraînait une consommation excessive de ressources disque, des entrées/sorties inutiles et des problèmes de sécurité potentiels. Dans la nouvelle version, une nouvelle filesystem FUSE est utilisée pour l'installation de paquets système, dans laquelle l'utilisateur peut écrire des données, mais l'accès aux fichiers écrits est ensuite bloqué pour l'utilisateur. Cette nouvelle approche implique la nécessité d'avoir un utilisateur distinct pour flatpak (par défaut « flatpak ») et de modifier les règles SELinux ;
- Ajout de la possibilité de définir des filtres pour les dépôts externes du côté du système client. Grâce à ces filtres, il est possible de restreindre les applications visibles dans le dépôt, en utilisant un modèle de listes blanches et noires ;
- Ajout d'une API de bibliothèque pour ajouter des dépôts externes à partir de fichiers flatpakref ;
- Ajout d'un profil seccomp pour Docker, permettant d'exécuter flatpak à l'intérieur de conteneurs ;
- Amélioration de la possibilité d'installation à partir de plusieurs sources P2P (via des clés USB ou un réseau local) ;
- Dans la commande « flatpak remote-ls », un filtrage automatique des applications dont le support est terminé a été assuré ;
- Dans « flatpak remote-ls » et « flatpak remote-info », une option « --cached » a été mise en œuvre pour fournir des informations basées sur des données locales mises en cache ;
- Ajout de la possibilité d'indiquer la version de fin de vie du paquet, après laquelle une proposition de passer à une nouvelle branche apparaîtra ;
- Ajout de l'option « --socket=pcsc » pour accéder aux cartes à puce ;
- Ajout de la prise en charge des systèmes avec plusieurs cartes graphiques NVIDIA ;
- Mise en œuvre du support du dconf placé dans un environnement sandbox ;
- Des options «—no-update-[summary,appstream]» et «—static-delta-ignore-ref=PATTERN» ont été ajoutées à l'équipe build-update-repo ;
- La vitesse de régénération des branches appstream pour les grands dépôts a été considérablement augmentée.
Rappelons que Flatpak donne aux développeurs d'applications la possibilité de simplifier la distribution de leurs programmes qui ne figurent pas dans les dépôts standard des distributions, grâce à un conteneur universel sans la nécessité de créer des builds séparés pour chaque distribution. Pour les utilisateurs soucieux de la sécurité, Flatpak permet d'exécuter une application douteuse dans un conteneur, offrant uniquement l'accès aux fonctionnalités réseau et aux fichiers utilisateur liés à l'application. Pour les utilisateurs intéressés par les nouveautés, Flatpak permet d'installer les versions bêta et stables les plus récentes d'applications, sans nécessité de modifier le système. Par exemple, actuellement, les paquets Flatpak sont déjà pour LibreOffice, Firefox, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, etc.
Pour réduire la taille du paquet, il inclut uniquement les dépendances spécifiques à l'application, tandis que les bibliothèques système et graphiques de base (Gtk+, Qt, bibliothèques GNOME et KDE, etc.) sont fournies sous forme de runtimes modulaire. La principale différence entre Flatpak et Snap est que Snap utilise les composants de l'environnement système principal et une isolation basée sur le filtrage des appels système, tandis que Flatpak crée un conteneur distinct du système et opère avec de grands ensembles de runtime, fournissant comme dépendances non des paquets, mais des environnements système typiques (par exemple, toutes les bibliothèques nécessaires au fonctionnement des programmes GNOME ou KDE).
En plus de l'environnement système typique (runtime), installé via un spécifique , des dépendances supplémentaires (bundle) requises pour faire fonctionner l'application sont fournies. En somme, le runtime et le bundle forment le contenu du conteneur, le runtime étant installé séparément et associé à plusieurs conteneurs à la fois, ce qui permet d'éviter la duplication des fichiers système communs aux conteneurs. Plusieurs runtimes différents (GNOME, KDE) ou plusieurs versions d'un même runtime (GNOME 3.26, GNOME 3.28) peuvent être installés sur un même système. Un conteneur avec une application en tant que dépendance n'utilise le lien qu'avec un runtime spécifique, sans prendre en compte les packages individuels constituant le runtime. Tous les éléments manquants sont emballés directement avec l'application. Lors de la formation du conteneur, le contenu du runtime est monté comme la partition /usr, et le bundle est monté dans le répertoire /app.
Le contenu des runtimes et des conteneurs d'applications est constitué à l'aide de la technologie , où l'image est mise à jour de manière atomique depuis un dépôt similaire à Git, permettant d'appliquer des méthodes de contrôle de version aux composants de la distribution (par exemple, il est possible de revenir rapidement à un état antérieur du système). Les paquets RPM sont traduits dans le dépôt OSTree à l'aide d'une couche spéciale . L'installation et la mise à jour séparées des paquets au sein de l'environnement de travail ne sont pas prises en charge, le système est mis à jour non pas au niveau des composants individuels, mais dans son intégralité, changeant atomiquement son état. Des outils sont fournis pour l'application incrémentale des mises à jour, éliminant le besoin de remplacer entièrement l'image à chaque mise à jour.
L'environnement isolé formé est complètement indépendant de la distribution utilisée, et avec une configuration adéquate des paquets, il n'a pas accès aux fichiers et processus de l'utilisateur ou du système principal, ne peut pas interagir directement avec le matériel, sauf pour le rendu via DRI, et le sous-système réseau. La sortie graphique et la gestion de l'entrée se font via le protocole Wayland ou le passage du socket X11. L'interaction avec l'environnement externe repose sur un système de messagerie DBus et une API spéciale Portals. Pour l'isolation une couche et des technologies de virtualisation de conteneurs traditionnelles pour Linux, basées sur l'utilisation des cgroups, des espaces de noms (namespaces), de Seccomp et de SELinux. Pour la sortie audio, PulseAudio est utilisé.
Source : opennet.ru
