Sommaire
Flatpak est un "système de construction et de déploiement d'applications de bureau sur Linux". C'est un outil assez similaire à Snap et à AppImage, les fameux "gestionnaires de paquets universels". Ces gestionnaires de paquets sont censés apporter deux avantages principaux :
permettre à un utilisateur normal d'installer des logiciels, qui ne sont pas forcément fournis par la logithèque de sa distribution;
permettre à un développeur de packager un logiciel facilement pour tout un ensemble de distributions Linux.
Il existe également une autre approche de la gestion de paquets, proposée par Nix et GNU Guix et basée sur la composition d'environnements logiciels sans effet de bord. Cette approche apporte également les fonctionnalités recherchées par les gestionnaires de paquets universels.
Ce journal présente les deux approches (à travers Flatpak et Nix) d'un point de vue pratique, à la fois côté utilisateur (installer un logiciel) et côté développeur (packager un logiciel). Il ne s'agit cependant pas d'une comparaison exhaustive ni fiable (voir également la vidéo youtube).
Avertissement : j'ai essayé d'être le plus objectif possible mais mon propos est biaisé par le fait que je connaisse assez bien Nix alors que mon expérience avec Flatpak est très réduite.
Installer Flatpak et Nix
Avec une distribution Linux "classique"
Flatpak est souvent fourni directement par la logithèque système.
sudo apt install flatpakPour installer Nix, il faut généralement utiliser le script fourni par Nix.
curl https://nixos.org/nix/install | sh
echo ". $HOME/.nix-profile/etc/profile.d/nix.sh" >> ~/.bashrc
source ~/.bashrcAvec NixOS
NixOS est une distribution Linux basée sur Nix mais qui supporte également Flatpak, via un service qu'il suffit d'activer.
- éditer la configuration système (le fichier
/etc/nixos/configuration.nix) :
services.flatpak.enable = true;
xdg.portal = {
enable = true;
extraPortals = [ pkgs.xdg-desktop-portal-gtk ];
};- mettre à jour la configuration système :
sudo nixos-rebuild switchInstaller et utiliser un paquet
Premier cas d'utilisation : un utilisateur normal (non administrateur) veut installer et lancer un logiciel fourni par Flatpak ou par Nix.
Avec Flatpak
La procédure est décrite dans la documentation de Flatpak.
- ajouter un dépôt Flatpak :
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak update- chercher et exécuter un logiciel :
flatpak search geany
...
flatpak run org.geany.GeanyAvec Nix
La procédure est décrite dans la documentation de Nix.
- ajouter un canal de paquets :
nix-channel --add https://nixos.org/channels/nixos-19.09 nixpkgs
nix-channel --update- chercher et exécuter un logiciel :
nix search geany
...
nix run nixpkgs.geany -c geanyComparaison
Flatpak ou Nix, la procédure pour récupérer et lancer un logiciel est très similaire.
Concernant la documentation, celle de Flatpak est meilleure : la procédure est décrite pas-à-pas dans une section dédiée. La documentation de Nix est plus difficile : les informations sont assez dispersées dans les différentes sections du manuel.
Concernant le nombre de paquets, la logithèque de Nix est beaucoup plus fournie que celle de Flatpak. Cependant, Flatpak n'a pas (encore) pour objectif de concurrencer les logithèques classiques mais plutôt de fournir des logiciels qui n'y sont habituellement pas (parce que trop récent, trop confidentiel, non-libre, etc).
Enfin, d'un point de vue technique, les deux outils téléchargent des paquets binaires et les réutilisent si déjà téléchargés. La logithèque standard de Nix est centralisée et semble donc plus propice à la réutilisation des paquets. Flatpak utilise des sources plus variées (org.gnome, org.kde, org.freedesktop…) ce qui multiplie le risque de dépendances non-mutualisées.
Créer un paquet
Second cas d'utilisation : un développeur veut packager une application.
Projet d'exemple
Il s'agit d'un helloworld en C++, utilisant la bibliothèque gtkmm et compilé via cmake et pkg-config.
-
hello.cpp:
#include <gtkmm.h>
int main(int argc, char ** argv) {
Gtk::Main kit(argc, argv);
Gtk::Window window;
Gtk::Label label(" Hello ! ");
window.add(label);
window.set_default_size(200, 100);
window.show_all();
kit.run(window);
return 0;
}-
CMakeLists.txt:
cmake_minimum_required( VERSION 3.0 )
project( hello )
find_package( PkgConfig REQUIRED )
pkg_check_modules( PKG_GTKMM REQUIRED gtkmm-3.0 )
include_directories( ${PKG_GTKMM_INCLUDE_DIRS} )
add_executable( hello hello.cpp )
target_link_libraries( hello ${PKG_GTKMM_LIBRARIES} )
install( TARGETS hello DESTINATION bin )Créer un paquet avec Flatpak
La procédure est documentée ici et le code source du projet est disponible ici.
installer
flatpak-builderinstaller un runtime/SDK Flatpak :
flatpak install flathub org.gnome.Platform//3.32 org.gnome.Sdk//3.32- écrire un fichier de packaging (
org.flatpak.hello.json) :
{
"app-id": "org.flatpak.hello",
"runtime": "org.gnome.Platform",
"runtime-version": "3.32",
"sdk": "org.gnome.Sdk",
"command": "hello",
"finish-args": [
"--socket=x11"
],
"modules": [
{
"name": "mm-common",
"cleanup": [ "/" ],
"sources": [
{
"type": "archive",
"url": "https://download.gnome.org/sources/mm-common/0.9/mm-common-0.9.12.tar.xz",
"sha256": "ceffdcce1e5b52742884c233ec604bf6fded12eea9da077ce7a62c02c87e7c0b"
}
]
},
...
{
"name": "hello",
"buildsystem": "cmake",
"builddir": true,
"sources": [
{
"type": "dir",
"path": "."
}
]
}
]
}- construire et tester le paquet :
flatpak-builder build-dir org.flatpak.hello.json
flatpak-builder --run build-dir org.flatpak.hello.json hello
Créer un paquet avec Nix
- écrire un fichier de packaging (
default.nix) :
with import <nixpkgs> {};
stdenv.mkDerivation {
name = "hellonix";
src = ./.;
buildInputs = [
cmake
gtkmm3
pkgconfig
];
}- compiler et tester :
nix-build
./result/bin/helloComparaison
Dans les grandes lignes, la construction d'un paquet suit toujours à peu près les mêmes étapes : récupérer un environnement logiciel, écrire un fichier de packaging, réaliser le packaging en utilisant le fichier et l'environnement précédents.
Avec Nix, le packaging ne pose ici pas de problème particulier. Comme la logithèque standard est bien fournie, il suffit d'indiquer l'outils de compilation et les dépendances. Nix permet, si besoin, d'ajouter ou de modifier des dépendances, ou de personnaliser les différentes étapes du packaging. Les principales difficultés avec Nix sont la documentation peu pédagogique et son langage très particulier.
Le packaging avec Flatpak est plus compliqué. La documentation est pédagogique mais l'exemple présenté est trop simple (pas de dépendance ni d'étape de compilation). De plus, il faut spécifier un runtime Flatpak (et sa version) mais la documentation n'est pas très détaillée à ce sujet. Enfin, la gestion des dépendances est assez pénible : apparemment, il faut les spécifier soi-même sous forme de modules dans le fichier de packaging. Pour simplifier le travail, on peut utiliser un logiciel comme gnome-builder mais le fichier résultant est complexe et semble difficile à maintenir efficacement.
D'un point de vue plus technique, on peut regarder comment les ressources et les produits sont isolés et réutilisés. Avec Nix, tout est stocké dans le /nix/store (dépendances, paquets construits…). Les paquets sont donc réutilisés au niveau du système complet : si un paquet est utilisé par différents utilisateurs ou par différents projets, ce sont les fichiers du /nix/store qui sont effectivement utilisés. De plus, le /nix/store est en lecture seule et ne peut être manipulé que via les outils Nix, ce qui assure l'isolation. Avec Flatpak, il semble effectivement y avoir réutilisation et isolation pour les paquets installés par l'utilisateur ainsi que pour les runtimes utilisés par le développeur. En revanche, la construction d'un paquet crée un dossier .flatpak-builder, notamment pour gérer les modules de dépendances. Ce dossier est créé pour chaque projet, donc sans réutilisation. De plus, il s'agit d'un simple dossier caché sans restriction de droit particulière, donc relativement peu isolé.
Conclusion
D'un point de vue factuel
Ce journal a comparé un gestionnaire de paquets "universels" (Flatpak) avec un gestionnaire de paquets "composables sans effet de bord" (Nix). Les deux objectifs principaux étaient (1) de permettre à un utilisateur normal d'installer un logiciel sans avoir à passer par la logithèque système ni à compiler manuellement, (2) de permettre à un développeur de packager et de distribuer un logiciel sans avoir à construire différents types de paquets pour les différents types de distributions.
Globalement, Flatpak et Nix atteignent ces objectifs. Flatpak est bien intégré dans une bonne partie des distributions Linux, possède une documentation très (trop ?) pédagogique et propose un hub de paquets communautaires. Nix est beaucoup moins présent dans les logithèques des distributions Linux et doit généralement être installé manuellement. Sa documentation est bien fournie mais assez difficile d'accès. Nix propose plusieurs solutions pour distribuer des paquets : logithèque officielle, logithèque communautaire, service de cache…
Sur l'exemple traité ici, le packaging semble plus facile avec Nix. De plus, de par sa conception (composition de paquets sans effet de bord), Nix semble implémenter plus efficacement l'isolation et la réutilisation des paquets, notamment pour le développeur. À travers son écosystème (NixOS, Nixpkgs, Nixops…), Nix propose également beaucoup d'autres fonctionnalités : gérer les services systèmes, construire des images Docker, gérer des environnements logiciels multi-langages, définir et déployer des micro-services ou des systèmes complets, etc. De son côté, Flatpak prévoit d'implémenter un système de sandboxing de services utilisateurs (accès au système de fichiers, à la caméra, etc) qui n'a pas d'équivalent dans Nix.
D'un point de vue personnel
Tout d'abord, je rappelle que mon opinion sur le sujet est forcément biaisée car j'utilise, promeus et contribue à l'écosystème Nix depuis plusieurs années. Avec Nix, je connais à peu près les outils, les pièges à éviter et comment fouiller dans la doc, ce qui n'est pas le cas avec Flatpak. Cependant, j'ai vraiment essayé d'aborder Flatpak objectivement, avec même l'espoir de l'utiliser pour certains de mes projets.
Par rapport à une logithèque Linux classique, Flatpak (et les gestionnaires de paquets universels en général) permet à un utilisateur normal d'installer des logiciels et à un développeur de packager un peu plus efficacement pour Linux. Ce sont effectivement des avantages significatifs qui peuvent valoriser Linux sur le secteur du desktop. D'un point de vue purement technique, il me semble qu'on aurait également pu implémenter un mode "utilisateur" dans, par exemple, APT et ainsi continuer à utiliser la chaine APT + DEB + PPA. Mais d'un point de vue humain, je peux comprendre qu'il faille repartir sur un système "indépendant", même si Flatpak semble quand même pas mal poussé par IBM Fedora. Oups, un troll s'est glissé dans la phrase précédente, sauras-tu le trouver ?
Enfin, par rapport à Nix, Flatpak a l'avantage d'apporter une doc plus pédagogique, un site web plus joli, et… c'est tout. Non seulement, Nix permet également à un utilisateur installer des logiciels et à un développeur de packager un logiciel mais en plus Nix repose sur des concepts éprouvés, a une logithèque énorme et apporte plein d'autres fonctionnalités (cf la section précédente). Alors ok, c'est mon opinion personnelle biaisée et tout, mais je ne vois rien dans Flatpak qui n'existe pas déjà dans Nix ou qui ne pourrait pas y être implémenté sans trop de problème. Et comble de la cerise sur le gateau qui fait déborder le vase, Nix est apparu environ 10 ans avant Flatpak; ça aurait peut-être été bien que les différentes communautés collaborent un peu plus ensemble… Bref, pour finir sur une note positive : Flatpak c'est bien, mais si vous avez l'occasion de tester Nix (voire NixOS), foncez.
# Grand public
Posté par Okki (site web personnel, Mastodon) . Évalué à 7.
Je n'ai jamais utilisé Nix, mais par rapport à tes exemples qui utilisent tous la ligne de commande, Flatpak s'intègre bien avec les logithèques graphiques des différents environnements de bureau (c'est le cas pour GNOME, KDE, Cinnamon, Pantheon…). On peut donc facilement ajouter un dépôt comme Flathub en deux clics de souris et ensuite rechercher et installer une application tout aussi facilement.
Pour des applications réellement isolées, d'avoir une gestion des permissions au sein de l'environnement de bureau permettant à l'utilisateur d'avoir un retour graphique et de pouvoir facilement faire son choix (l'application que vous venez d'installer souhaite pouvoir accéder à la webcam, souhaitez-vous l'autoriser…) est très important. L'utilisateur doit pouvoir facilement accorder ou révoquer des droits à tout moment.
Le développement de Flatpak est actif. La version 1.6.0 est sortie la semaine dernière et apporte, entre autre, la prise en charge des contenus protégés, ce qui devrait permettre, à terme, de pouvoir acheter des contenus (applications commerciales). Tous les utilisateurs ne sont pas forcément des libristes convaincus et certains voudront pouvoir acheter le dernier jeu à la mode ou une application propriétaire qui répondrait mieux à leurs besoins que son équivalent libre.
À mon avis, si Flatpak risque de remporter le match, c'est qu'il est massivement adopté (projet Freedesktop, donc plus ou moins un standard dans le Libre) et qu'il s'intègre bien dans les écosystèmes (bonne documentation, intégration dans les environnements de bureau, que ce soit pour l'installation/désinstallation des paquets ou la gestion des droits, la prise en compte des besoins des différentes parties, développeurs / éditeurs et utilisateurs finaux…)
Nix était peut être là dix ans plus tôt, mais est-ce qu'ils ont cherché à s'intégrer aux environnements de bureau, à prendre en compte les besoins des différentes distributions, des éditeurs commerciaux… ou est-ce qu'ils n'ont pas cherché à voir plus loin que leur propre communauté ?
[^] # Re: Grand public
Posté par nokomprendo (site web personnel) . Évalué à 4.
Oui. J'en parle un peu plus dans la vidéo mais effectivement Flatpak est plus convivial pour l'utilisateur final. Je pense que les développeurs de Nix pourraient facilement faire la même chose mais effectivement, ils ne le font pas.
Pour le sandboxing de Flatpak, oui à terme ça semble prometteur. Mais actuellement ce n'est pas fonctionnel et déjà l'isolation et la réutilisation des paquets peuvent être améliorés. De plus, j'ai des doutes sur l'utilité réelle du système final : ça risque de faire comme les extensions des navigateurs où l'utilisateur va accepter n'importe quoi car il n'a pas vraiment le choix s'il veut tester.
Complètement d'accord : la communauté Nix n'essaie pas suffisamment de rendre son système facile d'accès et de l'intégrer dans les distributions. Cependant, c'est une communauté relativement petite. De plus, l'outil Nix est (je crois) en cours de soumission dans Debian et Nix n'était pas forcément bien vu des contributeurs de logithèques car ils le voyaient comme un concurrent ou un doublon. Enfin, est-ce-que Flatpak/Snap/AppImage/whatever ont cherché à voir plus loin que leur propre communauté ?
[^] # Re: Grand public
Posté par lewo . Évalué à 1.
Juste pour confirmer que Nix est bien dans Debian unstable, bien qu'il ne soit pas respecte pas le FHS (Filesystem Hierarchy Standard) (cf la dicussion https://lists.debian.org/debian-devel/2019/01/msg00013.html).
[^] # Re: Grand public
Posté par nokomprendo (site web personnel) . Évalué à 4.
Merci pour les liens.
Du coup, ça m'a permis de retrouver la discussion initiale… de 2008 : https://lists.debian.org/debian-devel/2008/12/msg01007.html
En gros, les gens de Debian reprochaient à Nix de ne pas respecter le FHS, de compliquer le travail de sécurisation et de refaire ce que faisait déjà APT. C'est dommage car je pense que Nix aurait pu être intégré plus facilement s'il avait été présenté comme un gestionnaire "local et utilisateur", un peu à la pip/npm/cargo (désolé pour l'anachronisme) et qu'il pouvait géré son store via un dossier utilisateur et non système.
Petit extrait de la discussion :
https://lists.debian.org/debian-devel/2008/12/msg01010.html
[^] # Re: Grand public
Posté par Renault (site web personnel) . Évalué à 6.
C'est un élément de sécurité en plus qui est bienvenue.
Si par exemple une application veut faire une capture d'écran globale alors que ce n'était pas souhaité ou nécessaire, l'utilisateur sera au courant et pourra refuser l'action. Et il saura que cette application essaye de faire des choses non souhaitables et n'est par conséquent pas de confiance.
Il est évident que certains utilisateurs vont cliquer abusivement sur les autorisations pour accepter tout et n'importe quoi. Et alors ? Pour l'utilisateur que je suis j'en vois un intérêt évident pour mon usage.
C'est je trouve l'intérêt majeur de Flatpak en fait. Tu te concentres sur l'aspect application universelle qui n'est finalement qu'un but parmi d'autres de Flatpak et qui ne le différencie pas forcément des autres systèmes. Or ce point là fait justement tout l'intérêt de Flatpak par rapport à d'autres concepts.
[^] # Re: Grand public
Posté par nokomprendo (site web personnel) . Évalué à 1.
Je me suis appuyé sur les docs et les pages de Flatpak. Tout ce que j'ai trouvé sur le sandboxing de services se résume à définir les ressources dont à besoin le paquet (https://docs.flatpak.org/en/latest/basic-concepts.html#sandboxes, https://docs.flatpak.org/en/latest/sandbox-permissions-reference.html), ce qui est bien et je le dis dans la vidéo. Mais sans le système de restriction côté utilisateur, ça ne sert à peu près à rien niveau sécurité (et ça je ne le dis pas dans la vidéo). Alors ok, ça va arriver mais actuellement ce n'est pas le cas.
Et sur la page principale (https://flatpak.org), donc a priori ce qu'un utilisateur final va regarder en premier, je ne vois aucune mention du sandboxing de services.
Bref, Flatpak fait plein de pub et est même intégré dans plein de distros mais sa killer feature ne serait pas encore implémentée ? Désolé, j'essaie vraiment d'être ouvert à tout mais je ne trouve pas ça très sérieux.
[^] # Re: Grand public
Posté par Renault (site web personnel) . Évalué à 4.
Mais c'est parti des éléments basiques qui sont sur la documentation du bousin. Du je n'en conclurais pas grand chose, tout dépend de la maintenance de cette page et du public cible (et perso je ne crois pas qu'une telle page web soit réellement utile, l'utilisateur s'en fiche, le développeur regardera plutôt la doc).
Car cette fonctionnalité est très complexe à mettre en œuvre proprement. La partie application universelle c'est facile, d'autres systèmes ont déjà fait ça par le passé, et empaqueter de manière universelle n'a rien de sorcier pour fonctionner avec n'importe qu'elle application.
Là on parle de définir un système qui capte des demandes nécessitant des autorisations à la volée (et donc lister ce qui doit être autorisé par l'utilisateur ou pas), qui a une interface utilisateur adaptée et s'assurer que les applications fonctionnent proprement avant. Le fait que FreeDesktop.org chapeaute cela permet aussi de s'assurer que le mécanisme aura un comportement constant entre els différents bureaux. Or un tel système n'existe pas encore et n'a jamais été vraiment tenté sous Linux hors Android (et encore, le mécanisme reste différent). Donc oui c'est long à développer.
Donc oui une partie importante de l'intérêt de Flatpak n'existe pas encore mais cela ne me choque pas vraiment étant donné le travail nécessaire. De même que Wayland a été annoncé pour remplacer X.org des années avant qu'il ne soit finalement capable de le remplacer nativement. Cela permet au moins à des gens de jouer avec, de se familiariser, de donner des retours et de l'intégrer.
[^] # Re: Grand public
Posté par nokomprendo (site web personnel) . Évalué à 2.
Oui d'accord mais là je fais un test en pratique donc je ne peux pas tester les fonctionnalités futures qui n'existent pas encore…
Pour en revenir au journal, j'ai indiqué quelques points que je trouve peu satisfaisants concernant la création de paquets avec Flatpak (gestion des dépendances, isolation, mutualisation). Encore une fois je ne suis pas un expert en Flatpak, sais-tu s'il y a de meilleures solutions ?
Enfin, je vois de plus en plus d'articles sur Fedora Silverblue et le concept m'intéresse vraiment. Cependant, j'ai du mal à voir en quoi les fonctionnalités d'immutabilité, système reproductible, conteneurisation et rollback sont des innovations par rapport à ce que fait déjà NixOS. Pourrais-tu faire un article ou un journal à ce sujet ? Je précise que ce n'est pas du troll, je suis vraiment intéressé par le sujet. Et même si tu veux qu'on fasse une dépêche collaborative pour présenter les concepts et leurs implémentations actuelles ou futures dans Silverblue et NixOS, je suis partant.
[^] # Re: Grand public
Posté par Renault (site web personnel) . Évalué à 3.
Je ne critique pas ton test qui est intéressant. Cependant après dans les commentaires tu insistes sur le fait qu'il n'y a pas de différences en occultant en fait ce que Flatpak souhaite fournir. C'est sûr que si tu ne regardes que l'aspect paquet universel qui n'est qu'une facette du projet, tu risques de mal conclure.
Je ne suis pas expert en la question non plus, je ne pourrais pas t'aider.
J'ai dans les carton un article sur Silverblue pour une future dépêche, j'espère la publier bientôt. J'espère avant mars. Elle ne vise pas à être trop technique, plutôt montrer l'historique et la vision. Mais après je veux bien travailler sur un article qui présente plus techniquement comment cela fonctionne. Après tu pourras éventuellement pondre un commentaire ou une dépêche en réponse pour lister les différences (ou non). :)
[^] # Re: Grand public
Posté par nokomprendo (site web personnel) . Évalué à 2. Dernière modification le 27 décembre 2019 à 15:07.
Ok je comprends que tu as une vision a plus long terme mais j'ai quand même parlé de ça dans la conclusion : "De son côté, Flatpak prévoit d'implémenter un système de sandboxing de services utilisateurs (accès au système de fichiers, à la caméra, etc) qui n'a pas d'équivalent dans Nix."
Ok. Perso, j'aurais préféré quelque chose de plus collaboratif plutôt qu'une bataille de technos mais comme tu veux.
# flatpak c'est nul
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
J'ai essayé et au premier abord c'est nul: https://linuxfr.org/nodes/118350/comments/1786904
Au deuxième abord, c'est bof, mais je suis arrivé à construire mon paquet après des heures de bidouille.
Au troisième abord, c'est vraiment nul: https://linuxfr.org/nodes/118350/comments/1788497
Bref j'ai fait une appimage.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: flatpak c'est nul
Posté par Okki (site web personnel, Mastodon) . Évalué à 8.
Pour la doc, ils sont conscients du problème. Après, comme d'hab avec le libre, il faut trouver des bénévoles motivés pour s'en occuper.
En attendant, si t'as des questions, tu dois pouvoir contacter Mat Booth (le mainteneur des extensions OpenJDKs pour Flatpak).
Non, parce que le libre c'est quand même l'entraide, la contribution, l'écriture de billets de blog explicatifs quand on a résolu un problème pour aider ceux qui pourraient le rencontrer à l'avenir… Ce qui est tout de même plus productif que de juste dire (encore et encore) à quel point on trouve ça nul :)
[^] # Re: flatpak c'est nul
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
J'ai ouvert un ticket https://github.com/flatpak/flatpak/issues/3205 qui a été fermé avec une explication qui ne m'a pas convaincu.
Même démarche avec appimage https://github.com/AppImage/AppImageKit/issues/1001 où là on m'a donné une bonne solution.
Le libre c'est aussi le choix d'aller vers un projet qui marche bien.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: flatpak c'est nul
Posté par Okki (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 26 décembre 2019 à 19:14.
Que ce soit flatpak ou apt / dnf, ce ne sont que des outils pour installer des paquets. Et comme ça t'a été répondu, il fallait soit indiquer à tes utilisateurs la commande pour installer le runtime manuellement, soit leur proposer d'activer le dépôt Flathub pour que la commande flatpak puisse trouver les dépendances nécessaires au bon fonctionnement de ton jeu (sur Fedora, ça se fait d'un simple clic de souris).
Tout comme ça n'aurait pas été plus mal de proposer ton jeu sur Flathub, ce qui lui aurait fourni une meilleure exposition (que ce soit sur ce site vitrine ou dans les logithèques de certaines distributions) qu'uniquement ton site officiel, qui implique de déjà en avoir entendu parler.
[^] # Re: flatpak c'est nul
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Si l'utilisateur doit installer un runtime flatpak manuellement, ça n'apporte rien par rapport à lui faire installer un runtime java.
Pour aller sur Flathub, il faut un build offline, ce qui est impossible sans une gestion intégrée de maven.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: flatpak c'est nul
Posté par Jérôme Flesch (site web personnel) . Évalué à 3. Dernière modification le 03 janvier 2020 à 14:29.
Je crois que le problème de base, c'est que les bundles Flatpak ne correspondent pas à l'utilisation courante prévue de Flatpak. Ils me donnent l'impression d'être plutôt un rajout, juste là pour dépanner.
À coté de ça, ce n'est pas complètement illogique que les bundles ne contiennent pas les runtimes. Ça évite aux utilisateurs d'avoir à retélécharger les runtimes plusieurs fois. Mais oui, c'est moins pratique.
Il me semble que Flatpak est plutôt prévu pour que les applications soit téléchargées et mises à jour via un dépôt (soit hébergé toi-même, soit sur FlatHub). Dans ce cas, tu mets à disposition de tes utilisateurs un fichier .flatpakref qui indique les dépôts à utiliser pour l'application et le runtime (exemple 1, exemple 2). L'avantage est que ça règle aussi le problème des mises à jour. L'inconvénient est que c'est dépendant d'une connexion Internet.
Là mon impression, c'est comme si tu tentais de distribuer un .deb en te plaignant que APT/dpkg c'est pourri parce-que le .deb que tu fais ne contient pas toutes les dépendances.
[^] # Re: flatpak c'est nul
Posté par nokomprendo (site web personnel) . Évalué à 3.
Tout à fait d'accord. Mais du coup, je me demande pourquoi les développeurs de Flatpak n'ont pas juste contribuer à Nix plutôt que de faire leur propre système en partant de zéro, en moins puissant, moins performant et avec une logithèque bien plus petite.
# Autre point important
Posté par gnumdk (site web personnel) . Évalué à 6.
Cela permet d'installer des applications dans son homedir sans les droits root et de partager ses applications entre ses différentes distributions. Et lors d'une réinstallation, installer flatpak suffit à retrouver toute sa logithèque.
[^] # Re: Autre point important
Posté par nokomprendo (site web personnel) . Évalué à 7.
Cool. Un peu comme Nix donc. Et avec Nix + home-manager, tu peux même gérer la configuration complète de ton environnement utilisateur : https://linuxfr.org/users/nokomprendo-3/journaux/gerer-son-environnement-utilisateur-nixos-avec-home-manager
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.