Garder un système Debian propre, astuce n°3 : se débarrasser des paquets externes à Debian

Le dernier billet de notre série évoquait la suppression des paquets obsolètes. Le billet d’aujourd’hui va vous montrer comment faire retrouver à votre ordinateur un état proche de celui obtenu après une installation de Debian/Ubuntu, sans paquets tiers.

APT a cela de puissant qu’il permet facilement l’ajout de nouveaux dépôts externes, et l’installation de logiciels à partir de ces derniers. Malheureusement, certains de ces logiciels ne s’avèrent pas être très bien maintenus : paquets de piètre qualité ou plus mis à jour. Un paquet fonctionnant parfaitement au début peut devenir une plaie pour la maintenance du système, par exemple en posant une dépendance sur un paquet devant être supprimé lors de la mise à jour.

Mon but ici est donc de vous montrer comment identifier ces paquets, qui ne proviennent ni de Debian, ni d’Ubuntu, de telle sorte que vous puissiez les passer en revue de temps en temps, et ne garder que ceux dont vous avez réellement besoin. Les paquets obsolètes sont en fait un sous-ensemble de ces paquets mais, les ayant traités dans le dernier billet, je n’y reviendrai pas.

Tout dépôt APT bien conçu est fourni avec un fichier Release le décrivant (celui-ci par exemple). Ces fichiers contiennent un certain nombre de valeurs permettant à APT d’identifier les paquets que contiennent les dépôts correspondants. Tous les dépôts officiels Debian mentionnent ainsi Origin=Debian (ou Origin=Ubuntu pour Ubuntu). L’attribut Origin de chaque dépôt présent dans votre fichier sources.list peut être vérifié grâce à apt-cache policy :

[...]
 500 http://ftp.debian.org/debian/ lenny/main i386 Packages
     release v=5.0.8,o=Debian,a=stable,n=lenny,l=Debian,c=main
     origin ftp.debian.org
[...]

Partant de là, il suffit de demander à aptitude de renvoyer la liste des paquets installés mais non présents dans un dépôt Debian officiel :

$ aptitude search '?narrow(?installed, !?origin(Debian))!?obsolete'
ou
$ aptitude search '~S ~i !~ODebian !~o'

search peut être remplacé par purge ou remove si vous souhaitez supprimer/purger tous les paquets correspondants. Ceci étant, il est plus probable que vous ne vouliez en supprimer que quelques-uns, intelligemment choisis : il y en a encore sûrement que vous utilisez !

synaptic vous permet également de parcourir le contenu de chaque dépôt : cliquez sur le bouton « Origine » et une liste de dépôts apparaît. Il suffit de parcourir les dépôts non-Debian à la recherche des paquets installés et à jour.

Mais il est possible de faire mieux : créer une vue personnalisée. Pour cela cliquez sur l’entrée « Filtres » du menu « Configuration ». Cliquez ensuite sur « Nouveau » pour créer un nouveau filtre, appelez-le par exemple « Paquet externe ». Décochez toutes les entrées de l’onglet « État », à l’exception de « Installés ».

Allez ensuite dans l’onglet « Propriété » pour ajouter une nouvelle entrée : « Origine » « exclut » « ftp.debian.org ». Remplacez évidemment ftp.debian.org par le nom du miroir que vous utilisez (il apparaît dans la sortie d’apt-cache policy, cf. l’exemple présenté un peu plus haut).

Note : le terme « Origine » fait référence à deux notions distinctes : un attribut du fichier Release évoqué précédemment, mais aussi le nom de l’hôte d’un dépôt APT. Ce qui est un peu perturbant si l’on y prête pas attention.

Fermez la fenêtre de définition des filtres en cliquant sur « OK ». Une nouvelle liste « Paquet externe » est maintenant disponible dans l’onglet « Filtres personnalisés ». Vous pouvez maintenant voir quels paquets sont installés et à jour, et décider si vous souhaitez les garder ou pas. Si le paquet est également fourni par Debian/Ubuntu et que vous désirez changer pour ce dernier, utilisez « Paquet > Forcer version ».

Ceci est une traduction de mon article Debian Cleanup Tip #3: get rid of third-party packages contribuée par Weierstrass01. Ne manquez pas une occasion de parfaire vos connaissances de Debian ou Ubuntu, abonnez-vous à ma newsletter en cliquant ici.

Garder un système Debian propre, astuce n°2 : se débarrasser des paquets obsolètes

Dans le billet précédent, nous avons appris comment supprimer les fichiers de configuration inutiles. Dans cet article, nous allons maintenant voir comment s’occuper des paquets obsolètes.

Un paquet est considéré comme obsolète du moment que plus aucun des dépôts APT présents dans le fichier /etc/apt/source.lists (et /etc/apt/sources.list.d/) ne le fournit. De nombreuses raisons peuvent conduire à cet état :

  • L’auteur amont du paquet a arrêté tout support depuis un long moment, personne n’a pris la relève et le mainteneur Debian a préféré retirer le paquet de l’archive Debian. Des alternatives sont la plupart du temps disponibles en remplacement ;
  • Le paquet Debian était orphelin depuis longtemps, personne ne l’a repris en charge et il n’avait que peu d’utilisateurs. Il se peut également que l’équipe Debian QA (Quality Assurance – Assurance Qualité) ait demandé son retrait ;
  • La dernière version du paquet a été empaquetée sous un nom différent. Soit en raison d’un nombre de changements tellement important qu’il était préférable de ne pas mettre à jour automatiquement vers le dernier paquet (ce fut le cas pour request-tracker et nagios par exemple, qui embarquaient tous les deux un numéro de version dans leurs noms), soit simplement parce que le mainteneur du paquet souhaitait permettre à l’utilisateur d’avoir plusieurs versions du paquet installées en même temps (ce qui est le cas par exemple pour le noyau Linux, l’interpréteur Python et de nombreuses bibliothèques) ;
  • l’application a été renommée, et le mainteneur a donc renommé le paquet. Il a gardé un paquet de transition sous l’ancien nom pendant un cycle de publication puis ce dernier a été supprimé.

Ce n’est dans tous les cas jamais une bonne idée de conserver les paquets obsolètes : ils ne profitent d’aucune mise à jour de sécurité, et peuvent causer des problèmes lors des mises à jour, en dépendant de paquets devant être supprimés pour finir celles-ci.

Vous pouvez les supprimez d’un seul coup grâce à aptitude purge ~o (ou aptitude purge ?obsolete), mais vous souhaitez peut-être analyser un peu plus la situation avant : il se pourrait que certains paquets que vous avez installés manuellement (et absents des dépôts APT) fassent partie du lot, et ces derniers ne doivent pas subir le même traitement (me concernant, j’ai par exemple Skype et quelques paquets personnels). Vous pouvez obtenir la liste des paquets concernés via aptitude search ?obsolete.

Cette même liste est bien sûr accessible en passant par Synaptic, gestionnaire de paquets en mode graphique : cliquez sur le bouton « État », puis sur « Installés (locaux ou obsolètes) ». Vous pouvez maintenant parcourir la liste et décider, pour chaque paquet, s’il doit être conservé ou non.

Ceci est une traduction de mon article Debian Cleanup Tip #2: Get rid of obsolete packages contribuée par Weierstrass01. Abonnez-vous à ce blog par RSS ou par email pour recevoir tous les prochains articles et améliorer votre maîtrise de Debian/Ubuntu.

Garder un système Debian propre, astuce n°1 : se débarrasser des fichiers de configuration inutiles

Si vous êtes de ceux aimant garder un bureau bien rangé, il en va certainement de même avec votre ordinateur ! À cette fin, je vais détailler, au travers de 4 articles dont voici le premier, quelques astuces pour maintenir votre Debian/Ubuntu toute propre !

Au fil du temps et de l’utilisation de votre ordinateur, l’ensemble des paquets installés va évoluer. Soit parce que vous avez installé/supprimé des applications, soit parce que vous avez mis à jour votre distribution.

Ceci étant, le système de gestion des paquets Debian est construit de telle sorte qu’il conserve les fichiers de configuration d’un paquet lors de sa suppression. C’est une fonctionnalité intéressante, dans la mesure où vous n’aurez pas à refaire le paramétrage de ce paquet lorsque vous le réinstallerez. Oui, mais… et si vous ne réinstallez jamais ?

Dans ce dernier cas, ces fichiers de configuration « encombrent » inutilement votre système, voire le « parasitent » ! Un exemple (m’étant récemment arrivé) : des scripts init obsolètes empêchant le passage à une séquence de boot basée sur les dépendances, car ils n’embarquaient aucune dépendance nécessaire. Bref, vous préféreriez vous en débarrasser.

La solution à ce problème consiste à « purger » tous les paquets dont il ne reste plus que les fichiers de configuration présents sur le système. Avec aptitude c’est possible avec la commande aptitude purge ~c (ou aptitude purge ?config-files). Il suffit de remplacer purge par search pour visualiser uniquement la liste des paquets concernés.

Si vous souhaitez une mise en forme adaptée de cette liste, de sorte qu’elle puisse être repassée en argument à un autre programme, utilisez une des commandes suivantes (et passez le résultat à apt-get si aptitude n’est pas installé) :

$ grep-status -n -sPackage -FStatus config-files
[...]
$ dpkg-query -f '${Package} ${Status}\n' -W | grep config-files$ | cut -d" " -f1
[...]

Note : grep-status fait partie du paquet dctrl-tools .

La solution précédente faisait intervenir la ligne de commande, mais vous pouvez tout aussi bien utiliser un gestionnaire graphique de paquets, comme Synaptic. Cliquez sur le bouton « État » en bas à gauche, puis sur « Non installés (résidus de configuration) », et la liste des paquets pouvant être purgés s’affiche. Sélectionnez-les tous, puis clic-droit « Marquer pour suppression complète » (cf. la capture d’écran ci-dessous). Enfin, cliquez sur « Appliquer » pour lancer la purge des paquets.

Ceci est une traduction de mon article Debian Cleanup Tip #1: Get rid of useless configuration files contribuée par Weierstrass01. Vous voulez d’autres tutoriels comme celui-ci ? Cliquez ici pour vous abonner à ma newsletter et recevoir les nouveaux articles par email.

Économisez de l’espace disque en excluant les fichiers inutiles avec dpkg

La plupart des paquets contiennent des fichiers dont vous n’avez pas besoin, comme par exemple des traductions dans des langues qui vous sont inconnues, ou de la documentation que vous ne lirez pas. Ne serait-il pas intéressant de s’en dispenser et sauver ainsi quelques méga-octets ? Bonne nouvelle : à partir de dpkg 1.15.8, c’est possible !

dpkg met à disposition deux options dans ce but :

  • --path-include=motif-de-type-glob
  • --path-exclude=motif-de-type-glob

D’elles dépend l’installation ou non d’un fichier. Le motif de recherche « glob » fonctionne de la même façon que ce à quoi vous êtes habitués au travers du shell (cf. la page de manuel glob(7)).

Passer ces deux options via la ligne de commande étant tout sauf pratique, la meilleure manière de les utiliser reste de les mettre dans un fichier de configuration résidant dans /etc/dpkg/dpkg.cfg.d/. Attention toutefois : l’ordre dans lequel sont énumérées les options compte. Lorsqu’un fichier correspond à plusieurs motifs de recherche, la dernière entrée l’emporte !

Un de leurs usages habituels consiste à exclure un dossier entier, puis à réintégrer certaines de ses parties que vous voulez conserver. Par exemple exclure les traductions gettext et manuels dans toutes les langues sauf le français. Il faut alors que le fichier /etc/dpkg/dpkg.cfg.d/excludes contienne :

# Supprimer toutes les locales, sauf le français
path-exclude=/usr/share/locale/*
path-include=/usr/share/locale/fr/*
path-include=/usr/share/locale/locale.alias

# Supprimer les pages de manuels, sauf celles en français
path-exclude=/usr/share/man/*
path-include=/usr/share/man/man[1-9]/*
path-include=/usr/share/man/fr*/*

Notez bien qu’à partir du moment où vous aurez mis à jour /etc/dpkg/dpkg.cfg.d/excludes, les fichiers commenceront à disparaître au fur et à mesure des mises à jour des paquets. Si l’objectif consiste à sauver de l’espace disque immédiatement, alors il vous faudra réinstaller les paquets installés sur votre système. aptitude reinstall ou apt-get --reinstall install pourront alors vous être utiles. En théorie, il serait même possible d’utiliser aptitude reinstall ~i, mais cela a de grandes chances d’échouer, du fait d’un paquet non disponible (parce qu’il a été installé manuellement ou parce qu’une nouvelle version a pris la place sur le miroir de l’ancienne ayant été installée).

Cet article est une traduction de Save disk space by excluding useless files with dpkg contribuée par Weierstrass01. Abonnez-vous à ce blog par RSS ou par email pour recevoir tous les prochains articles et améliorer votre maîtrise de Debian/Ubuntu.

5 raisons qui font qu’un paquet Debian est plus qu’une simple archive de fichiers

Folder with gearsLes paquets Debian font certainement partie de votre quotidien… mais savez-vous seulement ce qu’ils sont exactement ? De simples archives ? Sûrement plus que ça, sinon de « simples » archives TAR (vous savez, les fameux fichiers finissant par .tar.gz) feraient l’affaire. Cet article vous propose de plonger au cœur de leurs structures… suivez le guide !

1. Un paquet Debian ? Deux archives TAR dans une archive AR !

Un fichier .deb est, en premier lieu, une archive au format AR. Archive que vous pouvez manipuler à l’aide de la commande ar. Cette archive contient 3 fichiers, comme vous pouvez le constater par vous-même en téléchargeant n’importe quel .deb, et en lui passant la commande « ar t » :

$ ar t gwibber_2.31.91-1_all.deb
debian-binary
control.tar.gz
data.tar.gz

Le fichier debian-binary est un fichier texte indiquant la version du format du .deb, la version actuelle étant la 2.0.

$ ar p gwibber_2.31.91-1_all.deb debian-binary
2.0

Le fichier data.tar.gz contient quant à lui les fichiers « utiles » du paquets, i.e. tous les fichiers décompressés lorsque vous exécutez dpkg --unpack.

Jusque-là…rien d’extraordinaire. Ce qui fait qu’un .deb est plus qu’une archive est contenu dans le dernier fichier : control.tar.gz. Il contient des métainformations utilisées par le gestionnaire de paquets. Par exemple :

$ ar p gwibber_2.31.91-1_all.deb control.tar.gz | tar tzf -
./
./postinst
./prerm
./preinst
./postrm
./conffiles
./md5sums
./control

2. Des méta-informations concernant le paquet et ses relations…

Le fichier control contenu dans l’archive control.tar.gz est le plus important de tous : il contient des informations basiques sur le paquet telles que son nom, sa version, sa description, les architectures supportées, son mainteneur, etc. Il contient également tout le jeu de dépendances nécessaires au paquet, grâce auquel le gestionnaire de paquets peut s’assurer de la cohérence de l’écosystème avant l’installation du paquet. La page dédiée aux Binary control files vous en dira plus quant à l’utilisation de tous ces attributs.

Ces informations sont copiées dans le fichier /var/lib/dpkg/status après que le paquet a été installé.

3. …et des scripts pour que tout fonctionne dès l’installation

Aux différentes étapes de la vie d’un paquet — installation, mise à jour, suppression… — dpkg exécute les scripts du mainteneur, embarqués dans le paquet :

  • postinst : après l’installation
  • preinst : avant l’installation
  • postrm : après la suppression
  • prerm : avant la suppression

Il s’agit là d’une description largement simplifiée. Plus exactement, ces scripts sont exécutés en de nombreuses autres occasions, avec des paramètres d’appel différents. Un chapitre entier de la Charte Technique Debian est dédié à ce sujet. Cette page du wiki Debian pourrait vous paraître plus digeste pour une première approche.

Bien qu’effrayante de prime abord, il s’agit là d’une fonctionnalité très importante, indispensable à la bonne gestion des mises à jour non réversibles, à la création d’utilisateurs système, pour la configuration automatique, etc.

4. Les fichiers de configuration sont… spéciaux

Décompresser une archive entraîne la suppression des versions précédentes des fichiers, ce qui constitue le comportement désiré lorsqu’un paquet est mis à jour… sauf pour les fichiers de configuration : il vaut mieux ne pas écraser vos modifications, non ?

C’est dans cette optique que les paquets listent les fichiers de configuration dans le fichier conffiles fourni par control.tar.gz. De cette manière, dpkg les traitera différemment.

5. Vous pouvez toujours ajouter de nouvelles méta-informations

Et il existe déjà des outils qui exploitent la possibilité d’ajouter des fichiers supplémentaires dans control.tar.gz :

  • debsums utilise le fichier md5sums pour s’assurer qu’aucun fichier n’a été modifié par accident
  • dpkg-shlibdeps utilise les fichiers shlibs et symbols pour générer les dépendances à une bibliothèque
  • debconf utilise les scripts config pour obtenir des informations de configuration de la part de l’utilisateur

Une fois installés, ces fichiers sont conservés par dpkg dans /var/lib/dpkg/info/package.* à côté des scripts du mainteneur du paquet.

Cet article est une traduction de 5 reasons why a Debian package is more than a simple file archive contribuée par Weierstrass01. Suivez moi sur Identi.ca, Twitter et Facebook. Ou abonnez-vous à ce blog par RSS ou par email.

Le processus de publication de Debian expliqué

À l’heure actuelle, le seul et unique but du projet Debian est la parution de sa version stable[1]. Celle-ci intervient généralement tous les 18 à 24 mois, par le biais d’un processus dont cet article va tenter de brosser une vue générale.

Créer une nouvelle distribution

La publication de la nouvelle version stable est immédiatement suivie de la création d’une nouvelle distribution dans l’archive Debian, peuplée précisément par la version fraîchement publiée. Le choix de son nom de baptême revient aux Release Managers et il est de tradition qu’il soit choisi parmi l’un des noms de personnages du film d’animation Toy Story.

Dans le cas qui nous occupe actuellement, Wheezy vient d’être créée, maintenant que Squeeze (ou Debian 6.0) vient d’être publiée.

La distribution utilisée pour préparer la prochaine version stable est par contre toujours nommée testing, dans un souci de simplicité. Dans l’archive Debian, testing n’est qu’un lien symbolique pointant vers le répertoire approprié (wheezy, depuis peu).

Mises à jour des paquets, implémentation des objectifs

Les développeurs sont occupés, pendant la majeure partie du cycle de publication, par l’empaquetage des nouvelles versions amont, ainsi que par l’implémentation des « objectifs de publication » (release goals). L’envoi des paquets se fait d’abord dans l’archive unstable.

De là les paquets migrent vers testing une fois quelques tests de qualité passés : ils ne doivent pas être entachés de bogues critiques pour la publication, être disponibles pour toutes les architectures déjà supportées, ne briser aucune dépendance dans testing et enfin avoir au moins passé 10 jours dans unstable.

Cette période minimale permet d’assurer que le paquet a été testé et que ceux qui ont procédé aux tests ont eu suffisamment de temps pour rapporter les bogues éventuels. Si jamais l’un d’entre eux est critique pour la publication, le paquet est bloqué pour la migration vers testing.

La principale activité de la Release Team consiste pendant cette phase à s’assurer que les mises à jour des paquets migrent de unstable vers testing. Tâche pouvant se révéler ardue : les dépendances entre paquets « lient » souvent ces derniers ensemble, de sorte qu’ils ne puissent migrer vers testing qu’en même temps. Si un seul des paquets n’est pas prêt (par exemple parce que la nouvelle version de l’un d’entre eux n’a pas encore passé les 10 jours réglementaires dans unstable), c’est la migration de tous les paquets liés qui est bloquée.

Stabilisation, finition et correction des bogues critiques pour la publication

L’afflux constant de nouveaux paquets rend difficile la publication d’une version bien « léchée ». C’est la raison pour laquelle, atteint un certain point, les Release Managers gèlent testing : les mises à jour automatiques sont interrompues et chaque mise à jour de chaque paquet est soumise à validation. La sélection est impitoyable, seules sont autorisées les mises à jour corrigeant les bogues critiques pour la publication, ou ceux apportant à la fois une importante plus-value à l’expérience utilisateur (nouvelles traductions, documentation mise à jour, …) tout en présentant de faibles risques d’entraîner des régressions.

Certains paquets sont même retirés durant cette période de gel, si leurs versions actuelles ne seront pas supportées pour toute la durée de vie de la version stable de Debian.

La période de gel tend à ralentir considérablement les changements dans unstable. La plupart des mainteneurs de paquets optent en effet pour l’envoi des nouvelles versions dans experimental, de telle sorte qu’ils puissent toujours mettre à jour leurs paquets dans testing via unstable. Il s’agit là du processus recommandé par les Release Managers, dans la mesure où les mises à jour qu’ils autorisent ont été testées de la manière usuelle. Ce qui n’est pas le cas si elles sont directement envoyées dans testing (via testing-proposed-updates).

Cette caractéristique se révèle plutôt ennuyeuse pour les utilisateurs voulant rester à l’avant-garde en terme de versions de paquets, et qui utilisent testing ou unstable dans cette optique, celle d’une distribution en évolution perpétuelle (rolling release).

Publication

Dès que les Release Managers sont satisfaits de la qualité de la nouvelle distribution, les dernières opérations préalables à la publication sont lancées, telles que la génération des images CD. Dans l’archive Debian, la publication est officialisée par la redirection du lien symbolique de la version stable vers la nouvelle distribution – et celui de la version oldstable vers la désormais ancienne distribution.

Champagne ! Cette boucle est bouclée, une nouvelle peut commencer ! :-)

[1] Le projet « Testing Constamment Utilisable » vise à faire de testing une distribution officiellement supportée, tout comme la version stable, mais avec une politique de mise à jour très différente.

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

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).

Tout ce qu’il faut savoir sur les conffiles: les fichiers de configuration gérés par dpkg

La charte Debian enjoint chaque mainteneur de paquet à conserver, lors des mises à jour, les modifications des fichiers de configuration effectuées par l’utilisateur. Cet article a pour but de présenter la manière dont la plupart des paquets accomplissent cette tâche. Il s’agit d’un sujet critique pour quiconque est amené à gérer des mises à jour, avec en ligne de mire une automatisation aisée du processus et une réduction des effets de bord !

Comment dpkg gère les fichiers de configuration

La plupart des paquets se basent sur dpkg pour installer correctement leurs fichiers de configuration. Dpkg garde une somme de contrôle de la version originale de chaque fichier de configuration, de sorte qu’à chaque mise-à-jour la comparaison entre la somme de contrôle originale et celle du fichier de configuration actuel suffit à savoir si l’utilisateur y a apporté des modifications, ou non. Si tel est le cas — les sommes de contrôle sont alors différentes — le remplacement du fichier de configuration est intercepté et le système demande à l’utilisateur quoi faire. Vous avez probablement déjà croisé ces quelques lignes :

Fichier de configuration "/etc/bash.bashrc"
 ==> Modifié (par vous ou par un script) depuis l'installation.
 ==> Le mainteneur du paquet a envoyé une version mise à jour.
   Que voulez-vous faire ? Les options sont les suivantes
    Y or I  : installer la version du responsable de paquet
    N or O  : garder votre version actuellement installée
      D     : afficher les différences entre les versions
      Z     : suspendre ce processus pour examiner la situation
 L'action par défaut garde votre version actuelle.
*** bash.bashrc (Y/I/N/O/D/Z) [défaut=N] ? 

Dans l’exemple précédent, la réponse « Y » (« Yes ») ou « I » (« Install ») entraînera l’installation de la version mise à jour de /etc/bash.bashrc, ainsi que la sauvegarde de la version actuelle sous le nom de /etc/bash.bashrc.dpkg-old. Dans le cas inverse (option « N » (« No ») ou « O » (« Old »)), dpkg laissera au contraire la version actuelle de /etc/bash.bashrc intacte, tandis que la nouvelle version sera sauvegardée dans le fichier /etc/bash.bashrc.dpkg-dist. Les deux options restantes permettent de suspendre la mise à jour, le temps d’examiner la situation. Dans le cas où vous décidez de lancer un terminal (« Z »), la nouvelle version est alors disponible en tant que /etc/bash.bashrc.dpkg-new (les variables d’environnement — apparues avec Squeeze — $DPKG_CONFFILE_OLD et $DPKG_CONFFILE_NEW permettant de créer un script de comparaison « maison »).

Le nom de « conffiles » donné aux fichiers de configuration traités par dpkg leur vient du nom du champ dans lequel ils sont enregistrés dans la base de données dpkg. L’option --status permet d’afficher la liste des conffiles pour n’importe quel paquet :

$ dpkg --status bash
[...]
Conffiles:
 /etc/skel/.profile ecb6d3479ac3823f1da7f314d871989b
 /etc/skel/.bashrc 2afdd6c53990f2387a7ef9989af0bc07
 /etc/skel/.bash_logout 22bfb8c1dd94b5f3813a2b25da67463f
 /etc/bash.bashrc 5b3c3bc73d236e4e1b6f9b6c1ed5964e
[...]

La commande « dpkg-query --showformat='${Conffiles}\n' --show bash » vous permet de restreindre la sortie à cette information uniquement. Les 32 caractères à droite de chaque chemin d’accès correspondent à la somme de contrôle MD5 du fichier de configuration original correspondant.

Éviter l’indécision due aux fichiers de configuration

Chaque fois que dpkg se trouvera dans la situation de devoir installer un fichier de configuration dont vous aurez modifié la version précédente (ou supprimé, ce qui n’est qu’un cas particulier de la modification pour dpkg), il suspendra le processus dans l’attente d’une décision de votre part. Ce qui peut-être particulièrement ennuyeux lors de mises à jour conséquentes. Pour parer à de telles situations, le comportement de dpkg peut être prédéterminé à l’aide des options --force-conf* :

  • --force-confold: la version actuelle est systématiquement conservée, la nouvelle étant installée avec le suffixe .dpkg-dist. Cette option passée seule entraîne également le non-remplacement des anciens fichiers de configuration que vous n’avez pas modifiés. L’option --force-confdef doit être également passée pour que ces derniers soient remplacés.
  • --force-confnew: installer systématiquement la nouvelle version du fichier, l’ancienne étant conservée avec le suffixe .dpkg-old.
  • --force-confdef: comportement standard de dpkg, à savoir décider seul si possible et demander à l’utilisateur sinon. Utile principalement en combinaison avec l’option --force-confold.
  • --force-confmiss: avec cette option, dpkg installera le fichier de configuration s’il n’est pas présent sur le système (par exemple parce que vous l’avez supprimé par erreur).

Ces options peuvent être passées à dpkg lors de l’utilisation d’Apt, grâce à une syntaxe similaire à celle ci-dessous :

$ apt-get -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade

Ce comportement peut être retenu de manière permanente via la création du fichier /etc/apt/apt.conf.d/local :

Dpkg::Options {
   "--force-confdef";
   "--force-confold";
}

Laisser le choix à l’utilisateur systématiquement

Dpkg ne demandera l’avis de l’utilisateur que dans le cas où le paquet contient une nouvelle version du fichier de configuration. Réinstaller la même version du paquet n’entraînera par conséquent aucune demande, à moins de passer l’option --force-confask. Cette option, apparue dans Squeeze, ne demandera le choix de l’utilisateur que dans le cas de fichiers modifiés localement.

Cet article est une traduction de Everything you need to know about conffiles: configuration files managed by dpkg contribuée par Weierstrass01. Ne manquez pas une occasion de parfaire vos connaissances de Debian ou Ubuntu, abonnez-vous à ma newsletter en cliquant ici.