une nouvelle branche stable de l'outil , qui fournit un système pour la construction de paquets autonomes, non liés à des distributions Linux spécifiques et exécutés 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.8 :
- La mise en œuvre de l'installation en mode P2P a été simplifiée (permet d'organiser le téléchargement d'applications et de ensembles de runtime via des nœuds intermédiaires ou des supports pour les systèmes sans connexion réseau). La prise en charge de l'installation via des hôtes intermédiaires sur le réseau local a été interrompue. Le téléchargement automatique des dépôts (sideload) situés sur des clés USB locales est désactivé par défaut. Pour activer les dépôts locaux intermédiaires, il faut configurer le dépôt en créant un lien symbolique depuis /var/lib/flatpak/sideload-repos ou
/run/flatpak/sideload-repos. Изменение позволило упростить внутреннюю реализацию режима P2P и повысить его эффективность. - Ajouté une unité optionnelle de systemd pour la détection automatique de dépôts supplémentaires sur des clés USB externes connectées.
- Pour les applications ayant accès au système de fichiers, le passage du répertoire /lib de l'environnement hôte vers /run/host/lib a été assuré.
- De nouveaux pouvoirs d'accès au FS — «host-etc» et «host-os», permettant d'accéder aux répertoires système /etc et /usr, ont été ajoutés.
- Pour générer un code plus efficace pour l'analyse des fichiers GVariant d'ostree, a été utilisé .
- Dans le script de configuration de construction, il est désormais possible de compresser sans
libsystemd; - Le montage des sockets de Journal est assuré en mode lecture seule.
- Dans document-export, la prise en charge de l'exportation de répertoires a été ajoutée.
- L'accès direct aux dispositifs audio ALSA pour les applications ayant accès à Pulseaudio a été autorisé.
- Dans l'API ajouté le signal «install-authenticator», qui peut être utilisé par les clients pour installer les authentificateurs nécessaires à l'exécution de la transaction.
- L'utilisation des données de fuseau horaire basées sur /etc/localtime du système hôte a été assurée, ce qui a résolu des problèmes liés aux fuseaux horaires dans certaines applications.
- L'installation du fichier env.d depuis gdm a été interrompue, car les générateurs systemd gèrent mieux cette tâche.
- Dans l'outil create-usb, l'exportation des commits partiels est activée par défaut.
- La livraison du fichier sysusers.d pour la création via systemd des utilisateurs nécessaires a été assurée.
- Les commandes «flatpak remote-add» et «flatpak modify» ont été dotées de l'option «—[no-]follow-redirect» pour interdire/autoriser la redirection vers un autre dépôt.
- Dans le système
a été ajouté l'API Spawn pour obtenir l'identifiant de processus réel (PID) de l'application lancée. - Tous les dépôts OCI (Open Container Initiative) ont été convertis pour utiliser l'authentificateur flatpak-oci-authenticator.
- Les commandes «flatpak remote-info» et «flatpak update» ont été dotées de l'option «—commit=» pour spécifier une version précise des dépôts OCI.
- Un support initial des mises à jour delta pour les dépôts OCI a été ajouté.
- La commande «flatpak upgrade» a été ajoutée, qui est un alias de la commande «flatpak update».
- Des scénarios d'autocomplétion ont été implémentés pour le shell fish.
Rappelons que Flatpak permet aux développeurs d'applications de faciliter la diffusion de leurs programmes, qui ne figurent pas dans les dépôts standards des distributions, grâce à d'un conteneur universel sans avoir à créer des builds séparés pour chaque distribution. Pour les utilisateurs soucieux de sécurité, Flatpak permet d'exécuter une application douteuse dans un conteneur, en offrant un accès uniquement aux fonctionnalités réseaux et fichiers utilisateur liés à l'application. Pour les utilisateurs intéressés par les nouveautés, Flatpak permet d'installer les dernières versions test et stables des applications sans avoir besoin de modifier le système. Par exemple, à l'heure actuelle, les paquets Flatpak sont déjà des solutions pour LibreOffice, Midori, 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 présentées sous forme d'environnements d'exécution réutilisables. La principale différence entre Flatpak et Snap réside dans le fait que Snap utilise des 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 d'exécution, fournissant comme dépendances non des paquets, mais des environnements système standard (par exemple, toutes les bibliothèques nécessaires pour faire fonctionner 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é ainsi formé est entièrement indépendant de la distribution utilisée et, avec des configurations de paquet appropriées, n'a pas accès aux fichiers et processus de l'utilisateur ou du système principal, ne peut pas directement accéder au matériel, sauf pour la sortie via DRI, et à la sous-système réseau. La sortie graphique et l'organisation 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
