Comment trouver le bon paquet Debian: interfaces de recherche de haut-niveau

L’archive Debian est connue comme l’une des plus larges collections de logiciels libres au monde. Avec plus de 16 000 paquets source et plus de 30 000 binaires, les utilisateurs ont parfois quelques difficultés à trouver les paquets qui leurs sont utiles. Le développeur Debian Enrico Zini a travaillé sur l’infrastructure pour résoudre ce problème. Durant la dernière mini-debconf à Paris, Enrico a présenté ce sur quoi il travaillait ces dernières années lors d’une conférence; travaux qui « n’avaient pas encore obtenu l’attention qu’ils méritaient ».

Enrico est connu dans la communauté Debian pour l’introduction des debtags, système de classification des paquets se basant sur des facettes. Chaque facette décrit une propriété spécifique : type d’interface utilisateur, langage de programmation utilisé, types de document manipulés, vocation du logiciel, … Ses derniers travaux s’appuient sur cette classification, et sont disponibles au travers du paquet apt-xapian-index, que ce soit sous Debian ou sous Ubuntu. L’objectif étant de permettre l’interrogation de la base des paquets disponibles au travers de requêtes complexes.

Utilisateurs de apt-xapian-index

Lors de cette présentation, Enrico a évoqué les premières utilisations de ses travaux. La plus connue étant celle proposée dans l’Ubuntu Software Center, à travers sa fonction de recherche renvoyant quasi-instantanément les résultats, et ce grâce à apt-xapian-index. Il ne s’agit là toutefois que d’une utilisation basique, n’exploitant que peu des fonctionnalités avancées fournies par apt-xapian-index.

GoPlay! est également un des premiers à l’avoir adopté, et à en utiliser certaines fonctionnalités avancées. Il s’agit d’une interface graphique permettant de rechercher des jeux. À cette fin, GoPlay! utilise les debtags pour classer les jeux en différentes catégories de sorte que vous puissiez, par exemple, naviguez parmi tous les jeux d’action/arcade 3D ayant un lien avec les voitures. Le concept de GoPlay! a même été étendu jusqu’à devenir un navigateur de paquets plus généraliste se basant sur les debtags. C’est ainsi que le paquet fournit maintenant également GoLearn!, GoAdmin!, GoNet!, GoOffice!, GoSafe!, et GoWeb!.

Autre exemple, Fuss-launcher est un lanceur d’application, et non pas un navigateur de paquets. Mais il utilise également apt-xapian-index, et il est du coup capable, en se basant sur les informations stockées au niveau des paquets, de retrouver plus facilement les applications installées. En effet, les descriptions de paquets sont généralement plus verbeuses que celles contenues dans les fichiers .desktop. Autre fonctionnalité sympathique qu’Enrico a montré à son audience : en faisant un glisser-déposer d’un document dans Fuss-launcher, ce dernier vous dresse la liste des applications pouvant l’ouvrir !

Enfin, apt-xapian-index met également à disposition un outil de recherche en ligne de commande qui est beaucoup plus efficace, et de loin, au traditionnel apt-cache search : il s’agit de axi-cache search (axi étant ici l’acronyme de apt-xapian-index). Enrico fit la comparaison de la sortie d’apt-cache avec celle d’axi-cache, avec comme entrée la recherche de la lettre « r » : tandis que apt-cache énumérait une liste infinie de paquets contenant cette lettre quelque part dans leurs descriptions, axi-cache ne lista que les paquets concernant GNU R. Il fit également une démonstration de la complétion contextuelle automatique : contextuelle car se basant sur les debtags pour raffiner la recherche. En effet, une fois un premier mot-clé tapé, la complétion via la touche Tab ne montre que certains mots-clé ou debtags : ceux permettant de restreindre encore plus la recherche. L’interrogation via des requêtes à base d’opérateurs logiques (AND, OR, NOT, XOR) est également supportée.

Sous le capot

Enrico présenta ensuite les rouages de cette mécanique. Le moteur de recherche Xapian est au cœur de l’infrastructure, et il l’apprécie car il ne s’agit que d’une simple librairie (et non un démon), pourvue de sympathiques bindings Python. Des plugins, également écrits en Python, peuvent venir étendre les capacités d’apt-xapian-index, qui, même si sa fonction principale reste l’indexation des descriptions de paquets, enregistre beaucoup plus d’informations que nécessaires à cette tâche.

Parmi les informations stockées, on compte par exemple :

  • des mots apparaissant dans la description des paquets (ce qui inclut les traductions, dans le cas où l’utilisateur utilise une locale non anglaise);
  • l’origine des paquets;
  • leurs sections;
  • leurs tailles, ainsi que l’empreinte disque une fois installés;
  • leurs dates de première apparition;
  • les icônes, catégories ou descriptions des fichiers .desktop contenus (via app-install-data);
  • les alias d’applications populaires non disponibles sous Linux (par exemple « excel » renvoie au debtag office::spreadsheet).

Enrico a d’ores et déjà prévu d’enregistrer encore plus d’information : ajouter les données du popularity contest (cf. les rapports de bogue #602180 et #602182) lui permettrait ainsi de trier les résultats de manière efficace. En effet, les applications les plus utilisées sont généralement un bon choix en terme de support de la communauté, ainsi que du point de vue de la qualité, précisément du fait de cette large base d’utilisateurs. Stocker les dates de dernière installation/mise à jour/suppression rendrait plus facile la détermination d’une régression, due à une mise à jour d’un paquet particulier.

L’index étant accessible sans restriction, n’importe quelle application peut en tirer profit, sous réserve qu’elle puisse utiliser la librairie Xapian – écrite en C++ mais disposant de bindings Perl, Python, PHP, Java, Tcl, C# et Ruby.

Appel à l’expérimentation

De nombreuses applications utiles reposant sur apt-xapian-index restent encore à inventer, selon Enrico. Il lance ainsi un appel à « l’expérimentation », ainsi qu’à de nouvelles idées. La seule limite pratique à laquelle il s’est confronté est la taille de l’index : entre 50 (Debian unstable sans aucune traduction) et 70 Mo (Debian stable/testing/unstable avec les traductions dans une langue). Il préférerait ne pas le voir dépasser 100 Mo, dans la mesure, d’une part, où le paquet est installé par défaut (étant un paquet recommandé par aptitude), et d’autre part parce qu’il serait mal à l’aise à l’idée d’utiliser plus de 20% de l’empreinte disque d’une installation minimale juste pour ce service. C’est la raison pour laquelle l’index a été configuré pour ne pas stocker la position des mots-clé : il n’est donc pas possible de trouver les paquets dont la description contient le terme « calcul » immédiatement suivi de « statistique ». Par contre, il est possible de trouver ceux contenant les deux mots n’importe où dans leurs descriptions.

Apt-xapian-index offrirait-il trop de libertés ? C’est la question que s’est posé Enrico. Ce qui pourrait expliquer pourquoi si peu de personnes l’ont testé, malgré les nombreux billets sur son blog, dûment documentés avec exemples de code et tutoriaux. Mais il n’est pas difficile d’imaginer d’autres exemples d’utilisation : on pourrait ainsi étendre les fonctionnalités d’outils tels que rc-alert ou wnpp-alert par exemple, qui fournissent une longue liste de paquets Debian cherchant un peu d’aide, et qui sont installés sur la machine. Il serait ainsi possible d’utiliser apt-xapian-index pour restreindre les résultats aux seuls paquets écrits dans un certain langage, ou dédiés à un environnement de bureau particulier.

L’explication la plus probable étant certainement que trop peu de personnes ont entendu parler de cet outil. Il y a bien d’autres cas où les fonctionnalités d’apt-xapian-index pourrait être utile, et, à mon sens, le souhait d’Enrico pourrait bien devenir réalité.

Cet article est une traduction de How to find the right Debian packages: high-level search interface contribuée par Weierstrass01. Suivez moi sur Identi.ca, Twitter et Facebook. Ou abonnez-vous à ce blog par RSS ou par email.

Comprendre les processus d’adhésion aux projets Debian et Ubuntu

Les contributeurs réguliers de Debian ou d’Ubuntu peuvent se voir charger d’un rôle officiel au sein de la communauté, parmi un ensemble bien défini. À ces rôles sont assortis des droits permettant aux contributeurs d’accomplir leurs tâches ainsi que de prendre part à la gouvernance du projet (élections, prise de décisions, …). Ces rôles sont également le moyen, pour les distributions, de reconnaître le travail accompli, de telle sorte que la plupart des contributeurs sont fiers du statut qu’ils atteignent.

Le processus d’adhésion joue un rôle important dans le développement d’une distribution : par la nature des contributeurs conviés au projet, ce qu’elle attend de ces derniers ainsi que leurs droits en son sein. Elle façonne en dernier ressort la capacité du projet à recruter de nouveaux contributeurs et à garder le projet en bonne santé. Cet article décrit les statuts Debian et Ubuntu existants, et le jargon — parfois déroutant — associé.

Le cas Debian

Debian n’a que deux rôles de membres officiels : les Développeurs Debian (DD) et les Mainteneurs Debian (DM – Debian Maintainers). Leurs prérogatives sont définies dans la Constitution Debian, tandis que celles des mainteneurs sont définies dans la résolution générale de 2007. Ceci étant, le statut de mainteneur est principalement documenté dans la page wiki correspondante. L’intégration de ce nouveau statut dans le circuit officiel Debian a été assez lente, en large partie du au manque de concertation – à l’époque – avec les différentes parties impliquées. L’obtention de ce statut avant toute candidature à un poste de développeur est actuellement encouragé.

Être Mainteneur Debian ne confère que peu de droits : ils ne peuvent qu’uploader des paquets leurs faisant déjà expressément référence (que ce soit dans les champs « Mainteneur » ou « Uploader« ), et pourvu de l’attribut spécifique DM-Upload-Allowed positionné à « oui ». Ce dernier n’étant modifiable que par les Développeurs Debian. Les mainteneurs n’ont aucun autre droit, et uniquement un accès limité aux ressources Debian.

Au-delà de ces deux rôles officiels existe aussi une classe de mainteneurs n’étant mentionnés officiellement qu’à travers le champ « Mainteneur » du paquet. Ils assurent la maintenance du paquet mais tous les uploads sont réalisés par les Développeurs Debian, après vérification du travail effectué (ce « parrainage » – sponsorship – étant le passage obligé pour gravir les échelons officiels du processus d’empaquetage). Une fois que le mainteneur a gagné la confiance du Développeur Debian, ce dernier va lui demander de faire acte de candidature au poste de Mainteneur Debian, afin d’être affranchi du « parrainage ».

Il existe au final pas moins de trois différents types de mainteneurs de paquets, ce qui entraîne une belle confusion quand il s’agit de discuter des questions structurelles… d’autant plus lorsque le Processus du nouveau Mainteneur décrit les règles à suivre pour devenir un Développeur Debian. Attention donc aux « facéties » lexicales lorsque vous parcourez la documentation Debian !

Le cas Ubuntu

Ubuntu a depuis le début défini le statut de Membre Ubuntu, incluant tous les types de contributeurs : les développeurs bien sûr, mais aussi les rédacteurs de la documentation, artistes, traducteurs, etc. Ce statut donne notamment la possibilité de voter lors des élections du Conseil de la Communauté, le droit de participer au Planet Ubuntu ainsi que l’alias email @ubuntu.com.

La situation est plus compliquée pour les développeurs : la page wiki dédiée liste pas moins de cinq statuts différents. Les développeurs étaient initialement séparés entre Ubuntu Core Developers et MOTU (Masters of the Univers). Ces derniers étant responsables des sections d’archives universe/multiverse, tandis que les premiers avaient également les droits d’uploads pour les sections main/restricted. Mais, en but à de réels problèmes de gestion des archives, et inspirés par le concept de Mainteneur Debian, l’organisation changea pour permettre un contrôle plus précis des uploads de paquets.

Le droit d’upload peut maintenant être accordé au niveau du paquet, mais Ubuntu peut aussi déléguer la capacité d’autoriser l’upload, toujours paquet par paquet. Cela conduisit au nouveau statut d’Uploader propre au paquet (Per-Package Uploader), qui se résume à un Membre Ubuntu disposant de droits d’uploads sur un nombre restreint de paquets sur lesquels il possède une expertise. Le statut plus générique de Développeur Ubuntu inclut maintenant les membres de diverses équipes de développement (actuellement Ubuntu Desktop, Mythubuntu, Kubuntu et Edubuntu), auxquels ont été délégués, sur un vaste ensemble de paquets, la capacité à gérer les droits d’upload. Ces équipes peuvent définir leur propre politique d’ajout de nouveaux membres, du moment qu’elles suivent les règles basiques définies par le Conseil des Développeurs – Developer Membership Board. (voir à ce propos cette page wiki.)

Le statut de « Développeur Ubuntu impliqué » – Ubuntu Contributing Developer est un statut intermédiaire, dédié aux personnes qui ne sont pas encore prêtes pour les autres statuts de développeurs, mais qui ont fait preuve de suffisamment d’engagement pour devenir des Membres Ubuntu.

La procédure pour accéder à chacun de ces statuts est la même : préparer une page de wiki listant vos contributions, recueillir les témoignages de personnes déjà Membres avec lesquelles vous avez travaillé, vous ajouter à l’agenda de la prochaine session du comité qui accorde le statut recherché, et attendre ladite réunion. Les membres du comité décideront si vous êtes prêts (ou non) pour le statut d’après ce que vous aurez déclaré sur la page wiki, vos réponses lors du comité, sur une mailing-list dédiée aux développeurs, ainsi que quoi que ce soit que vous auriez à dire vous concernant.

Les comités les plus importants sont généralement élus par la communauté, tandis que les autres sont désignés par le Conseil de la Communauté. Ces instances gouvernantes comprennent des employés de Canonical, bien qu’en nombre inférieur à ce que l’on pourrait penser : 2 sur 8 dans le Comité d’adhésion des Développeurs, 2 sur 8 dans le Conseil de la Communauté, mais 6 sur 6 dans le Comité technique. Ce dernier chiffre, bien que non prémédité, n’est pas surprenant, étant donné la très grande implication attendue des membres potentiels du Comité technique. Mark, en tant que fondateur, est la seule personne à siéger de manière permanente à la fois au Conseil de la Communauté et au Comité technique.

Comparaison entre statuts Debian et Ubuntu

Le tableau suivant résume les autorisations accordées à chaque rôle existants parmi l’un ou l’autre projet (Passer la souris sur les acronymes pour en lire la signification).

Autorisations Debian Ubuntu
DM DD MU UPP/DU MOTU UCD
Maintenance du paquet via parrainageON/AOOON/A
Email officiel-OOOOO
Participation aux élections de membres-OOOOO
Participation aux élections de développeurs-O-OOO
Droits d’upload restreints sur liste de paquets déterminésO--O--
Droits d’upload restreints sur une section de l’archive----O-
Droits d’upload non restreints-O---O
Nombre de contributeurs (au 27/07/2010)117904462278563

Il est à noter que le nombre de contributeurs Ubuntu est approximatif, étant donné qu’un contributeur peut avoir plusieurs statuts (adhésion directe à un groupe launchpad) obtenus avec le temps (en engrangeant de l’expérience). L’imprécision a été grandement réduite en tenant compte des différences de membres entre les différents groupes mais cela reste forcément imparfait : certains MOTU sont également UPP de paquets présents dans l’archive principale, ce qui est tout à fait permis (dans ce cas ils n’ont été compté que comme MOTU). Une autre limitation du calcul vient du fait que certains membres d’équipes administratives sont indirectement inclus dans d’autres équipes, et apparaissent donc à tort dans le total.

Quoi qu’il en soit, ce tableau montre clairement qu’Ubuntu offre un panel de statuts bien plus large, reconnaissant le travail de chaque contributeur depuis le commencement tout en n’accordant les autorisations sensibles qu’à ceux qui ont clairement montré qu’ils les méritaient. Malgré cette différence, l’avantage reste de loin à Debian en ce qui concerne le nombre de développeurs, bien que ce chiffre ne fasse pas tout : beaucoup des contributeurs Ubuntu sont employés par Canonical (36 des 63 Core Developers ont enregistré une adresse @canonical.com sur leur compte launchpad, par exemple). En conséquence, ils consacreront vraisemblablement plus de temps à leur distribution que la moyenne des membres Debian. Il faudrait ramener la comparaison au nombre d’heures-hommes et, même s’il s’agit d’un défi théorique intéressant, il n’est pas d’une grande utilité dans la mesure où les projets continuent de coopérer.

Debian est conscient des imperfections de sa structure, et les possibles changements visant à intégrer les contributeurs non mainteneurs de paquets ont été abordés maintes fois. Les derniers efforts en date dans cette direction furent malheureusement perçus plus comme une solution imposée que comme une plate-forme de discussion, et furent rapidement enterrés par une résolution générale (RG). Et même si la résolution invitait à de nouvelles discussions et propositions, il n’en reste pas moins que lorsqu’une initiative particulière est corrigée de cette sorte, toute motivation d’aller plus loin s’évanouit.

Une évolution possible ?

Côté Ubuntu, les changements structurels effectués récemment écartent tout changement dans un avenir proche. Cependant, Ubuntu prévoit d’étendre encore l’usage de ces nouvelles fonctions, de sorte que d’avantage d’équipes bénéficient de la possibilité de contrôler les droits d’upload des paquets les concernant, et que plus de développeurs candidatent à un poste d’Uploader propre au paquet pour les paquets qu’ils connaissent très bien.

En ce qui concerne Debian, une récente discussion sur la liste de diffusion du projet a remis sur la table la problématique de la terminologie et il a été convenu que le Processus nouveau Mainteneur devait être renommé (« Processus du nouveau Développeur » a été suggéré). Mais Christoph Berg – Chargé de compte Debian et donc grandement impliqué dans l’équipe « Nouveau Mainteneur » a suggéré qu’il serait préférable d’implémenter au préalable les modifications longtemps attendues relatives à l’adhésion avant toute mise à jour de la documentation. Ce qui entraînera sans doutes une mise à jour du vocabulaire. Plus avant dans la discussion, il a confirmé que la réforme de l’adhésion fait partie des priorités de l’équipe (juste après la refonte du site nm.debian.org).

Que doit-on attendre de cette réforme ? Quelques éléments de réponse qui n’engagent que moi, basés sur mon expérience du projet; Debian n’ayant encore rien décidé.

  • En premier lieu : un nouveau statut pour les contributeurs non empaqueteurs. La difficulté résidant dans le parcours imposé et les droits accordés

  • Changements dans l’implémentation technique du statut de DM. Il est aujourd’hui impossible de donner les droits d’upload d’un paquet à un DM uniquement lorsque deux noms sont mentionnés dans le champ idoine (malgré le fait que l’un d’eux peut avoir une plus grande connaissance du paquet que l’autre). Au-delà de ce problème, on peut citer d’autres restrictions ennuyeuses telles que l’impossibilité d’uploader de nouveaux paquets binaires.

  • Un changement de la Constitution Debian en vue d’intégrer ces nouveaux statuts est quasi-inévitable.

  • D’autres changement invasifs ont été proposés, tels que le remplacement du processus de nouveau mainteneur par une simple désignation par les DD. Un tel changement est improbable. Le processus peut dès aujourd’hui être grandement simplifié par le responsable des candidatures si le candidat atteste de bonnes références des autres développeurs, et qu’il fait montre de contributions tangibles (par exemple telles que rapportées par des entrées dans l’historique des modifications de paquets Debian).

Presque deux ans se sont écoulés depuis les précédents efforts déployés en ce sens. L’équipe des nouveaux mainteneurs a recruté de nouveaux membres et est de manière générale en meilleure forme. Espérons que le prochain épisode connaîtra un meilleur dénouement.

Cet article est une traduction de Understanding Membership Structures in Debian and Ubuntu contribuée par Weierstrass01. Ne manquez pas une occasion de parfaire vos connaissances de Debian ou Ubuntu, abonnez-vous à ma newsletter en cliquant ici.

PS: Depuis que l’article a été rédigé, la situation a un peu évolué du côté Debian. Les contributeurs non-empaqueteurs ont officiellement accès au statut de « Développeur Debian » (voir l’annonce).