Fresh est un petit éditeur de texte terminal écrit en Rust. Son auteur voulait simplement que les gens puissent l’installer.

Il a fini avec npm, Cargo, Homebrew, winget, Nix, Flatpak, AppImage, AUR, des paquets .deb et .rpm, des tarballs précompilés, puis l’idée d’un binaire musl qui sait se mettre à jour lui-même.1

Le billet qu’il a publié cette semaine n’est pas une démonstration que « Linux est impossible ». C’est plus intéressant que ça : il montre comment la distribution d’un petit outil peut devenir un deuxième produit à maintenir.

Chaque solution universelle est universelle pour quelqu’un

Fresh a commencé par npm. C’était simple pour publier, mais étrange pour un utilisateur qui n’a aucune raison d’installer Node uniquement pour obtenir un binaire Rust. L’installeur allait en plus chercher l’artefact adapté sur GitHub.1

Le projet a donc accumulé les canaux : Cargo, Nix, Flatpak, AppImage, AUR, paquets natifs et archives.

Chaque solution résout une partie différente du problème.

Flatpak fournit un runtime indépendant de la distribution et exécute chaque application dans un sandbox. Par défaut, l’accès aux fichiers du système, au réseau, aux périphériques ou aux autres processus est limité et doit être accordé explicitement.2

C’est très cohérent pour une application desktop qui doit être isolée. C’est nettement moins naturel pour un TUI dont le travail consiste justement à lire des fichiers un peu partout, lancer des outils et interagir avec la machine. L’auteur de Fresh explique devoir relâcher fortement le sandbox pour que son usage fonctionne.1

Ce n’est pas un défaut général de Flatpak. C’est un mauvais emboîtement entre un modèle de sécurité et un type d’application.

AppImage déplace le problème ailleurs

AppImage embarque un système de fichiers SquashFS et son runtime le monte normalement via FUSE avant d’exécuter l’application.3

Fresh en publie un, mais son auteur estime le démarrage trop lent pour l’expérience qu’il veut. Son installeur extrait donc le contenu pour éviter ce coût au lancement.1

La documentation AppImage prévoit d’ailleurs l’extraction comme solution de secours lorsque FUSE n’est pas disponible.3

Encore une fois, aucune technologie n’est « cassée ». Les priorités se télescopent : paquet autonome, compatibilité, dépendances système, vitesse de lancement, mises à jour et sécurité ne pointent pas toutes vers le même format.

Les paquets natifs ajoutent du travail humain

Le .deb ou le .rpm semble être la réponse évidente : utiliser le gestionnaire de paquets de la distribution.

Mais être réellement intégré aux dépôts officiels n’est pas la même chose que déposer un fichier .deb sur une page de release. L’auteur de Fresh explique ne pas avoir eu le temps de faire entrer toutes ses dépendances Rust dans les processus nécessaires pour Debian/Ubuntu et Fedora.1

Sans dépôt configuré, un utilisateur qui installe un paquet téléchargé directement ne profite pas automatiquement du même chemin de mise à jour que les logiciels installés depuis les sources du système.

Fresh décrit aussi un autre problème banal : un binaire construit contre une libc récente ne fonctionne pas forcément sur une distribution ancienne.1

Construire sur une vieille base améliore la compatibilité descendante, mais impose alors de réfléchir à l’âge des bibliothèques de build. L’alternative est la liaison statique, qui déplace encore les compromis.

Le projet revient vers un binaire qui sait se mettre à jour

Après avoir essayé de satisfaire les différents écosystèmes, Fresh veut maintenant recommander un binaire statique musl avec une commande de mise à jour intégrée.1

L’auteur le résume lui-même avec une certaine ironie : il est en train d’implémenter son propre petit gestionnaire de paquets.

Ce choix n’est pas universel non plus. Un binaire qui se met à jour lui-même contourne une partie de la gouvernance et des garanties qu’offrent justement les gestionnaires de paquets système. Certaines organisations ne voudront jamais de ce modèle.

Mais pour un mainteneur seul ou une petite équipe, il réduit brutalement le nombre de surfaces à maintenir.

Le packaging est une décision produit

Le point important est là.

On traite souvent la distribution comme la dernière case après le build : produire le binaire, puis choisir deux ou trois formats.

En réalité, le choix influence qui peut installer le logiciel, comment il reçoit les mises à jour, ce que l’application peut faire sur la machine et combien de temps le mainteneur consacrera à chaque release.

Pour Fresh, un éditeur terminal multiplateforme de quelques dizaines de mégaoctets, le coût de cette matrice a fini par être suffisamment élevé pour modifier l’architecture de distribution du projet.1

Ce cas ne prouve pas qu’il existe une bonne réponse pour Linux. Il montre presque l’inverse.

Le format de livraison fait partie de l’outil. Et si vous êtes une petite équipe, le nombre de formats que vous promettez de maintenir est aussi une fonctionnalité, simplement une fonctionnalité que vos utilisateurs ne voient que lorsqu’elle casse.