Pourquoi AUR contribue au succès d’Arch Linux

Si vous parcourez les blogs linuxiens, et plus particulièrement ceux des utilisateurs d’Arch Linux, il y a un mot qui sort très régulièrement, c’est AUR, acronyme de Arch User Repository. Peut être vous demandiez vous ce qu’est l’AUR, ce que cela implique dans le fonctionnement de la distribution, et pourquoi est-il si populaire parmi les archers (utilisateurs d’Arch Linux). Si vous vous posiez ces questions, ce billet est pour vous.

Dans un premier temps, je pense qu’il faut garder ces deux caractéristiques en tête.

• N’importe qui peut contribuer sur l’AUR.
• Il est très facile de contribuer sur l’AUR.

L’AUR est une sorte de dépôt complètement public, ouvert à toutes personnes voulant contribuer à une mise à disposition commune de ressources venant de l’Internet. Pas de cérémonial, d’approbation ou encore de longue initiation rituel pour soumettre une ressource sur AUR.

S’il est facile de contribuer à AUR, il l’est tout autant pour s’en servir, grâce à des utilitaires comme yaourt ou ses autres alternatives, l’installation d’un paquet venant d’AUR n’est pas plus compliqué que d’installer un paquet avec un gestionnaire de paquet, pacman pour Arch Linux, mais comparable à apt-get pour Debian ou Ubuntu. Facilitant la gestion de dépendance et de recherche entre les paquets. Un système de vote est en place, pour reconnaître la popularité d’un paquet, mais aussi pour lui donner une crédibilité au niveau de la sécurité et de ses sources.

Le principe de base est d’écrire des directives d’installation dans un fichier appelé PKGBUILD, tout en suivant quelques normes dont la prise en main est assez facile. Le dépôt ne contient que ça, uniquement des directives, aucun binaire Une des caractéristiques donc, c’est qu’il est vraiment facile d’écrire un PKGBUILD. D’une part, le dépôt est libre d’accès à tout le monde, mais comme la réalisation d’un paquet est facile, cela renforce l’idée que AUR est accessible à tout le monde. Lisant par exemple sur le forum, une personne pensant qu’il faut être programmeur pour écrire un PKGBUILD, c’est une fausse idée de complexité de la réalisation d’un PKGBUILD.

De ces deux idées, la facilité de contribuer, et pour tout le monde, en découle des implications très bénéfique pour Arch Linux.

Par exemple, pour une personne habituée, il peut mettre à disposition un script ou un programme en quelques minutes seulement (ce qui était le cas par exemple pour proposer hacker-top et reddit-top un peu sur un coup de tête). S’il fallait beaucoup plus de temps, est-ce que je l’aurais fait ? probablement pas. Ceci est également bénéfique pour l’utilisateur, pouvant ainsi bénéficier facilement de programmes intéressant qui n’était pourtant pas connu.

Cette simplification de mise à disposition favorise également les applications un peu exotique, avec par exemple des drivers très récent qui ne serait pas incorporé autrement. Mais également niveau programmation avec les derniers frameworks en vogues. Sachant qu’un framework peut se faire une très grosse réputation en peu de temps, il est évidant que ce principe favorise son intégration par rapport à d’autre procédé, plus officialisé. Et surtout, il permet de les avoir à jour, ce qui est important si l’évolution en est rapide. Par exemple, si j’essaye Node.js, je ne veux pas la version de l’année dernière, mais la dernière. Pareil pour Ruby on Rails, je ne veux pas une veille version de Ruby, qui ne sera peut être pas compatible avec le dernier Rails. Ce dernier exemple, tiré d’un exemple bien réel, lorsqu’on voyait sur les forums les soucis rencontré pour faire fonctionner Rails lors de son passage pour la version 3. Le tout installé avec la propreté d’un gestionnaire de version, et non à la main comme on le vois souvent conseillé dans de tels cas.

Toute cette facilité, et cette non-formalité pourrait même être quantifiable. Le site web, front-end de AUR, annonce 32.000 paquets mis à disposition pour les archers, c’est plus que les 29.000 paquets qu’annonce debian sur leur page d’accueil. Alors, je sais que, c’est pas pareil, et que c’est pas loin d’être un troll, mais c’est un fait, bien que Arch Linux possède une communauté et un nombre de développeurs bien moins important que Debian, et c’est indéniable, par ce système, Arch Linux parvient à proposer à ces utilisateurs quasiment autant de paquets.

D’un point de vue mainteneur officiel, ceux s’occupant du dépôt officiel [community], ils peuvent facilement rétrograder un paquet dans l’AUR alors qu’il était officiellement supporté, sans qu’il n’y ait trop de contrainte, associé au fait que Arch Linux ne supporte que deux architectures, ne trainant pas un lourd fardeau avec une dizaine d’architecture à leur actif. Ces deux points sont je crois la clé de la réactivité, et de pouvoir garder une équipe de la core team restreinte (pas plus d’une vingtaine core-dev, plus les TU. Une réactivité d’une équipe réduite permettant un rolling release suffisamment stable pour intéresser des utilisateurs lambda de Linux.

AUR permet également à un développeur de partager son application facilement, quelque soit le langage choisis, de façon homogène, certes chaque langage offre généralement des possibilités, comme pip (python) gem (ruby), Il est quand même agréable d’avoir une possibilité de s’assurer du bon déroulement de l’installation sur sa propre distribution. Simplifier l’installation et la distribution d’un logiciel qui n’est pas connu et en développement, c’est un point important pour faire connaitre son application. De plus, PKGBUILD permet d’être facilement couplé à un gestionnaire de révision tel que git ou svn, permettant d’avoir plus facilement des retours sur le développement en temps réel, détail non négligeable pour un développement.

Parmi tout ces points, tout le monde s’y retrouve gagnant, de l’utilisateur lambda aux développeurs. J’espère qu’avec ces quelques explications, loin d’être exhaustives, le succès de l’AUR pour Arch Linux est plus clair, des implications qui peuvent être floues au début.

Sans AUR, Arch Linux ne serait plus le même.