URL: https://linuxfr.org/news/distribuer-sans-distributions Title: Distribuer sans distributions ? Authors: saltimbanque Nÿco et Benoît Sibaud Date: 2013年05月23日T14:51:59+02:00 License: CC By-SA Tags: ubuntu et fedora Score: 20 L'une des grandes forces de Linux et BSD, ce sont les paquets. Mais voilà, il n'y a pas un format de paquet standard, ce système ne va pas sans défauts, et le foisonnement des distributions peut dérouter. Cette dépêche n'aborde pas tant la distribution pour l'utilisateur final que pour le contributeur ; cependant le mouvement que l'on peut constater à travers différents efforts devra bien aboutir à un changement radical pour l'utilisateur de Linux. ---- ---- ## Chez Gnome ## Après tout ils sont à l'initiative de Jhbuild, alors je commence par eux, nah ! À l'heure actuelle, le moyen recommandé pour contribuer à Gnome est de passer par [Jhbuild](https://live.gnome.org/Jhbuild ) : ce système ingénieux permet d'installer les versions instables des modules GNOME dans une arborescence à part, et d’exécuter les binaires générés dans cet environnement (avec les bonnes variables). Ainsi on garde un système en version stable, et l'on peut tester et modifier un ou plusieurs modules GNOME dans leur coin, sans désinstaller leur version stable. Très pratique, mais Jhbuild ne va pas sans défauts : il peut s'avérer très fastidieux de mettre en place son environnement, puisque l'on rencontre systématiquement des petits soucis au moment de la compilation. ### Os-tree ### [GNOME-OS](https://afaikblog.wordpress.com/2012/08/07/gnome-os/), petit pseudo qui fut la source de bien des confusions, est le projet d'offrir aux développeurs, designers, traducteurs, testeurs et autres contributeurs un système efficace et simple. Concrètement, il est d'ores et déjà possible d'installer [une image virtuelle](http://build.gnome.org/ostree/buildmaster/images/z/current/) incluant les développements les plus récents et de la lancer très facilement. La notion ayant été diffusée au Guadec 2012, elle était déjà abordée dans [cette dépêche]( http://linuxfr.org/news/guadec-2012-en-route-vers-gnome-4-0-et-gnome-os). L'auteur, [Colin Walters](http://blog.verbum.org), l'a présenté [ici](http://people.gnome.org/~walters/guadec-2012-building-gnome). Techniquement, on parle de [OSTree](https://live.gnome.org/OSTree), un outil créant des images virtuelles que l'on peut éxécuter (soit dans une machine virtuelle, ce qui est au moins pour l'instant recommandé, soit carrément en rebootant dessus, ce que je n'ai pas testé). Il ne s'agit pas de remplacer les distributions. C'est un système extrêmement pratique pour développer et tester : les distributions s'en trouveront améliorées. Opposer OSTree à jhbuild n'est pas tout à fait exact : on peut très bien utiliser OSTree pour avoir sous la main un environnment à jour et [faire mumuse avec jhbuild par dessus](https://live.gnome.org/AndreasNilsson/PathOfLeastResistance), ce qui effectivement reste un procédé rapide. Bien sur chez GNOME le concept est directement lié à celui, fonctionnel, d'écosystème cohérent : une image testable en live, sert justement aux designers à suivre de près le développement des applications, pour travailler à fournir un produit cohérent, soigné, etc. Et l'idée va de paire avec le projet de fournir un SDK aux développeurs GNOME (maintenant que le langage JavaScript a été choisi, reste à mon sens à documenter, puisque actuellement il y a de grosses lacunes, et à [implémenter l'IDE qui va bien](https://live.gnome.org/Design/Apps/IDE)). ### Logithèque ### Plus récemment, [une logithèque a vu son implémentation démarrer](http://blogs.gnome.org/hughsie/2013/03/05/gnome-software-overall-plan/). Il s'agit d'abord d'intégrer dans GNOME ce qu'Ubuntu a fait de son côté il y a déjà bien longtemps, à l'image des App Store, à savoir proposer à l'utilisateur une liste d'applications disponibles, avec des notes, captures d'écrans, etc.  Mais il s'agit aussi d'une volonté de proposer à l'utilisateur des applications qui ne soient pas forcément sous la forme de paquets. Si comme je le rappelais GNOME OS ne se veut pas un concurrent des distributions, à mon sens il y a au moins re-définition massive de la répartition des rôles entre l'environnement de bureau et son distributeur : de nombreuses tâches qui incombaient jusqu'ici aux distro sont intégrées, dans une volonté de proposer une expérience identique quelque soit la distribution. (Mais ce sujet upstream/distro demanderait d'aborder bien d'autres points, comme l'exemple évident de la concurrence récente entre l'outil de configuration post-installation GNOME et celui de Fedora, aux tâches pouvant se recouper) ## Ailleurs ## L'idée d'éviter les paquets ne date pas d'aujourd'hui. Vous vous souvenez encore des installeurs de [Loki](http://fr.wikipedia.org/wiki/Loki_Entertainment_Software) ! Avant de lister de manière fort incomplète des alternatives vieilles ou plus récentes, le plus précieux me parait de renvoyer à un avis de Ingo Molnar, employé de Red Hat travaillant sur le noyau, postée sur G+ : pour résumer, la notion de paquets est dépassée car les distributions veulent contrôler beaucoup trop, sont donc trop lentes à intégrer de nouveaux venus ou simplement les mises à jours. Son avis est détaillé sur [une première partie](https://plus.google.com/u/0/109922199462633401279/posts/HgdeFDfRzNe) et [une deuxième]( https://plus.google.com/u/0/109922199462633401279/posts/VSdDJnscewS). * [NixOS](http://nixos.org/nix/) Un idée du bundle et une distribution se basant sur cette idée. * [0install](http://0install.net/) , utilisé par exemple du côté du bureau [ROX](http://rox.sourceforge.net/desktop/) * [Glick2](http://people.gnome.org/~alexl/glick2) . Une idée fait son chemin de l'utiliser en complément de OSTree. * Ubuntu : sa propre [alternative aux paquets a été traitée ici](http://linuxfr.org/users/mtux/journaux/un-nouveau-format-de-paquets-pour-ubuntu), mais Martin Pitt s'intéresse de son côté à OSTree : des images OSTree sont construites pour Ubuntu depuis peu. * BTRFS : ce système de fichier permet de créer des "snapshot", aussi facilement qu'on clone une vm, ce qui permet de revenir en arrière. Le gros point fort de BTRFS étant de ne copier que les fichiers qui sont modifiés, ce qui serait donc en théorie [utilisable par des gestionnaires de paquets pour proposer différentes versions](http://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs). Mais même en préservant /home, quid si /var a été modifié et que l'on revient en arrière? voir [ces commentaires ici-même](http://linuxfr.org/users/steckdenis/journaux/btrfs-id%C3%A9es-dapplication-des-snapshots-inscriptibles). ## Une note sur Fedora et les bundles ## Fedora possède une règle pour ses paquets : il ne faut pas qu'ils intègrent de "bundles", des librairies ou bouts de codes disponibles ailleurs mais intégrés en dur dans le code (des exceptions étant autorisées). La logique étant que si des problèmes se posent dans le code, le fait qu'il soit copié à droite à gauche empêche de le corriger facilement : il ne suffit plus de modifier un paquet, mais il faut identifier tous les paquets ayant copié le même code problématique. Si l'argument fait parfaitement sens, les trois exemples ci-dessous en sont des contreparties. Par exemple [Chromium](http://code.google.com/p/chromium/) utilise de nombreux morceaux, mais modifiés pour son usage, et pas "upstream" : ce fut la raison de [refuser l'introduction d'un RPM dans Fedora]( http://ostatic.com/blog/making-projects-easier-to-package-why-chromium-isnt-in-fedora) Le problème peut également se poser avec l'utilisation de [submodule git](http://git-scm.com/book/en/Git-Tools-Submodules), puisque alors un logiciel va reprendre dans ses fichiers d'autres lui étant extérieurs, ou encore avec [php-composer](http://getcomposer.org) (toujours pas empaqueté chez Fedora, ce qui fait que OwnCloud 5 n'y figure toujours pas). ## Conclusion ## Eh non, pas encore de conclusion! à vous codeurs de l'écrire... en espérant que j'ai oublié encore plein d'autres alternatives. Ou à moins que la conclusion ne soit, tout simplement, les applications en html5...