Salut,
Je ne suis pas un expert dans le domaine, mais un ami m’a fait une remarque sur les méthodes de packaging des applications sur Yunohost, qui fonctionne sur des scripts, et pas sur des paquets comme pour les applications de Debian par exemple.
Pourquoi ce choix ? Quels sont les avantages et inconvénients des 2 systèmes ?
C’est une question qui revient souvent.
Techniquement parlant, il s’agit bien d’un format de paquet: celui de YunoHost. Donc la question c’est pourquoi mettre en place un autre format de paquet. Car oui techniquement on aurait plus ou moins était en mesure d’utiliser des .deb .
Paquets d’app construit sur une base pré-définis
Alors déjà, il faut bien comprendre que Yunohost est constituées d’une base de dépendance (nginx, postfix, ssowat, rmilter, yunohost, helpers yunohost, slapd …) et de configuration précise (structure du ldap, structure des conf nginx…) . Donc, les paquets d’applications même si ils étaient au format .deb ne pourraient être installés qu’à la condition que ce soit effectivement sur un yunohost (ou alors sur un système qui émule tout l’environnement et les commandes ynh).
Ce choix a été fait, car il est plus simple de packager des apps sur une base pré-définis.
Autrement dit, même si ça avait été des .deb il aurait été nécéssaire d’abandonner l’idée de pouvoir installer le .deb sur sa debian classique ou sur une ubuntu.
Les + du format Yunohost
Fonctionnalités avancées
Les paquets d’app Yunohost offrent des fonctionnalités avancées tel que la sauvegarde/restauration de l’app, le changement d’url, l’interconnexion avec des actions systèmes (ajout utilisateur, refresh du parefeu…). Et nous avons d’autres idées du même genre. Fonctionnalités qui seraient réalisables avec des .deb via les custom scripts, mais au final il aurait bien fallu les faire ces scripts… (ceci dit la taille des scripts pourrait être réduite par l’usage de convention, mais c’est une autre histoire)
Installation multiple (et distincte) possible
Ensuite, le format de yunohost permet des installations multiples d’une même app, avec un .deb pas possible de le faire de cette façon et moins de chose aurait été possible.
Déploiement d’un dépot d’app plus simple
Il faut aussi dire qu’un .deb doit être hébergé quelques part. Mettre en place un repo debian est loin d’être simple. Yunohost en a toutefois un pour les paquets yunohost, yunohost-admin, moulinette, ssowat, rmilter et metronome. Mais si on peut envisager que les apps officielles soient dans un tel repo, il aurait été plus complexe d’héberger les packages communautaires.
Là le format yunohost peut prendre la forme d’un repo git quelconque, facilement hébergeable et clonable sur tout un tas de plateforme. Même si la plupart sont sur github, notamment car nous avons souhaité rassembler le maximum de paquet sur l’orga YunoHost-Apps pour des raisons pratiques. Ce format git permet vraiment un déploiement décentralisé facile.
Il est aussi possible de mettre à dispo un tar.gz ou un simple dossier (mais jusqu’ici ce format alternatif n’est utilisé que pour le développement).
Pas de compilations/compressions nécessaires
Un paquet yunohost au format git est directement lisible et exploitable. Alors qu’un .deb nécessite qu’on le compile avec les bons outils. Ca prend du temps et l’utilité reste à prouver.
Format léger
Un autre point différenciant est que le format yunohost n’inclus pas les sources du logiciel packagé. Au lieu de cela, elles sont téléchargées sur l’upstream le plus officiels possibles et l’intégrité est vérifiée. Un mécanisme (peu documenté) permet de télécharger à l’avance les sources upstream pour les situations d’installation déconnectées (le cas typique est celui d’asso qui oeuvrent dans des zones sans internet, notamment en afrique et en inde ).
Plus simple ?
C’est peut être moins vrai aujourd’hui à cause de nombreux helpers et de problématiques de sécurité, mais empaqueter une app pour yunohost pour qu’elle soit installable c’est finalement juste faire les opérations qu’on aurait fait en cli (modulo quelques adaptations et bonne pratique). Il est possible de parvenir à créer un package juste en partant de l’app d’exemple ou d’une autre.
Avantage du format debian
Maturité
De son côté le format de debian a l’avantage d’être plus mature et connu. Le fait qu’il soit répandu ne change rien car les paquets d’apps sont conçus pour s’installer par dessus yunohost.
Apt est très connu
Si nous avions opté pour des .deb nous pourrions utiliser apt pour installer les apps, cettte cli à l’avantage d’être connu par beaucoup de linuxiens.
Inconvénient si nous avions opté pour les .deb
Toutefois, il ne faut pas s’y tromper, si nous avions opté pour ce choix nous aurions du rajouter de nombreuses règles pour faire que les .deb soient compatibles yunohost. Ce qui aurait abouti à un format fils. Le packaging serait finalement probablement plus complexe car il aurait été nécessaire de comprendre les règles de debian + celles de yunohost. ET nous aurions tout de même été obligé de faire une cli à part pour les fonctionnalité avancées.
La question des dépendances
Les dépendances sont en général géré via apt/dpkg au sein des paquets YunoHost. Mais c’est vrai que si un dépot existe pour celles-ci.
Très souvent il n’y en a pas, car les créateurs de ces dépendances ne font pas les paquets debian. Je pense au paquet npm, pip etc…
De nombreuses webapp en dépendent, pourtant à ce jour nous n’avons pas de jolie solution. Certains argumentent que nous devrions créer les .deb de ces dépendances, que c’est potentiellement automatisable. C’est sans doute vrai, mais y a toute de même du boulot pour le faire. Et on retombe sur la question de la facilité de déploiement d’un repo tiers, si quelqu’un qui veux paquager une app doit déployer un repo, ça va tout complexifier.
Et surtout, est-ce a yunohost de faire ce boulot. Pour l’instant, au vu du nombre de contrib, on peut probablement pas.
Celà dit cette question de la gestion des dépendances n’est pas tranchée et d’ailleurs on empêche pas ceux qui le souhaite de créer un dépot de dépendances.
2 Likes