Mes activités Debian en mai 2011

Voici mon récapitulatif mensuel de toutes mes activités gravitant autour de Debian. Si vous faites partie des personnes m’ayant fait un don pour soutenir mon travail, c’est l’occasion de constater ce que je fais de votre argent ! Sinon, c’est toujours quelques nouvelles intéressantes sur l’avancement de mes différents projets.

Au cours du mois de mai, j’ai donc…

…un peu travaillé sur le concept de Debian Rolling

Les discussions au sujet de Debian Rolling étaient encore très actives en début de ce mois sur la liste debian-devel. L’idée de renommer testing en rolling (ce que je soutenais) n’a pas prévalu car certains jugeaient que des bugs Release Critical restaient ouverts trop longtemps dans cette distribution et me méritait donc pas ce label. La proposition la plus consensuelle a été celle de Josselin Mouette : elle consiste à bâtir la distribution rolling d’après testing, en y ajoutant quelques paquets choisis de unstable.

Je considère cette solution viable à la condition de la restreindre à un sous-ensemble précis d’architectures. Dans le cas contraire, les raisons pour lesquelles les paquets ne migrent pas vers testing impacteront rolling de la même manière. Et si ces raisons n’existent pas, alors autant effectuer les migrations correspondantes directement dans testing au lieu de rolling.

Étant donné ce qui précède, j’ai installé sur mon ordinateur portable britney — le logiciel qui contrôle testing — pour voir comment créer rolling avec cet outil. britney s’avère être un logiciel très spécialisé, avec très peu de possibilités de paramétrage.

Au même moment, Joachim Breitner fit une proposition qui attira immédiatement mon attention. Il suggère d’utiliser les solveurs SAT pour déterminer l’ensemble des paquets devant migrer de unstable vers testing. rolling peut être, à mon sens, un excellent banc d’essai pour cette nouvelle implémentation de britney (qu’il nomme ici SAT-britney). J’ai donc embarqué sans hésiter à bord de ce projet.

Les notions scientifiques sous-tendant le concept m’étant peu familières, j’ai compulsé de la documentation et appris que tous les solveurs SAT intégraient le problème sous une forme bien particulière, appelée Forme Normale Conjonctive. De plus, le format DIMACS est le format de fichiers retenu pour présenter ces contraintes booléennes. Plusieurs solveurs SAT sont disponibles pour Debian, et picosat semble être un des meilleurs.

J’ai donc commencé à coder pour voir comment appliquer le concept, le résultat est disponible dans ce dépôt git. Vous pouvez en récupérer une copie via git clone git://git.debian.org/~hertzog/sat-britney.git.

Il n’y a pas encore grand chose, excepté un peu de code (en Python) générant un problème SAT pouvant être passé à un solveur. Mais je suis impatient de voir les développements de ce projet.

…représenté Debian au salon Solutions Linux

J’ai passé 3 jours à Paris dans la deuxième semaine du mois de mai, pour prêter main forte à la tenue du stand Debian au salon Solutions Linux

Nous avons répondu à beaucoup de questions mais la majorité des visiteurs connaissaient déjà Debian, et beaucoup l’utilisent à la maison et/ou au travail. Nous avons essayé de recruter de nouveaux adhérents dans l’association Debian France, et vendu les goodies qui nous restaient.

Les représentants d’Ubuntu ont été interviewés par France 3, et nous avons profité de l’opportunité (avec leur accord !) pour exhiber nos t-shirts Debian à l’arrière-plan. La vidéo est disponible ici, et vous pouvez nous y voir (Carl Chenet et moi-même) à 1:21.

Nous avons été interviewés quant à nous par Intelli’n TV: une première vidéo et une seconde. J’avoue ne pas exceller dans cet exercice ! :-)

…amélioré les triggers dpkg

La troisième semaine de mai était une semaine de vacances, et j’aurai du me tenir loin de mon ordinateur. Mais je tenais vraiment à la mettre à profit pour améliorer l’état des triggers dpkg dans Debian.

J’ai déjà abordé mon travail dans un précédent article : Trying to make dpkg triggers more useful and less painful.

Dans l’attente d’une synthèse des réponses à la question que j’ai envoyée à tous les mainteneurs de paquets utilisant les triggers, je n’ai pas encore intégré le résultat de mon travail dans le dépôt officiel.

…aidé les utilisateurs suite à la migration d’Alioth

Lorsque je suis revenu de vacances, un certain nombre de services fournis par alioth.debian.org étaient non-fonctionnels après la migration vers un nouvel environnement, impliquant deux machines au lieu d’une auparavant. Étant donné que je fus longtemps un administrateur d’Alioth, je suis bien placé pour savoir qu’en de telles circonstances, vous vous retrouvez vite submergé par les demandes de support utilisateur. Je suis donc retourné sur le canal #alioth d’IRC afin d’aider au mieux.

J’ai investigué certains des problèmes soulevés et mis au point des corrections (scripts mis à jour, fichiers de configuration, etc.) pour quelques-uns d’entre eux. J’ai également créé une liste des problèmes restants. Elle n’aurait du exister que quelques jours mais, en raison de régressions encore non résolues, est toujours active.

Les fonctionnalités les plus importantes manquant encore sont :

  • un support propre pour la délégation des droits. Par le passé, nous utilisions les ACL mises en place par les administrateurs. Avec le nouveau FusionForge, chaque admin de projet devrait être capable de déléguer des droits à des « rôles » extérieurs. Un rôle « Développeur Debian » existe déjà, mais la délegation echoue… ;
  • l’accès à l’Ultimate Debian Database. De nombreux outils s’appuient sur cette base de données pour fonctionner ;
  • l’accès en FTP anonyme pour télécharger les fichiers des projets ;
  • des directives claires sur la manière dont nous sommes censés gérer les sites web mis à jour à travers des hooks VCS ;
  • des directives claires sur la manière dont nous sommes supposés gérer les dépôts git personnels.

…amélioré le format de paquet source « 3.0 (quilt) »

J’ai émis plusieurs propositions visant à modifier le comportement du nouveau format source. L’objectif visé est double : premièrement, le rendre moins pénible à l’utilisation pour les empaqueteurs utilisant un VCS, et, deuxièmement, éviter les changements non souhaités qui s’immisceraient via un nouveau patch généré par dpkg-source.

Ces propositions semblent être consensuelles, je pourrai donc les implémenter dans un avenir proche.

…un peu laissé de côté la version anglaise de mon blog

Beaucoup de travail a été abattu pour Debian entre les déplacements et les vacances et, dans le temps restant, je n’ai pas réussi à écrire beaucoup de nouveaux articles pour mon blog anglophone.

En fait, mis à part l’article sur les triggers mentionné précédemment, je n’ai publié qu’une interview : People behind Debian: Steve Langasek, release wizard.

Je vais essayer de faire mieux ce mois-ci !

Merci !

Un grand merci à ceux qui m’ont soutenu à hauteur de 151.61 € durant le mois de mai.

Rendez-vous le mois prochain pour un nouveau compte-rendu de mes activités Debian !

Cet article est une traduction de My Debian activities in May 2011 contribuée par Weierstrass01.

Debian peut-elle proposer une distribution testing constamment utilisable ?

Testing est le dépôt où Debian prépare la prochaine version stable, et bien que cela reste sa mission première, de nombreux utilisateurs l’ont adoptée en tant que distribution courante, leurs offrant un bon compromis entre stabilité et « fraîcheur » des paquets. Il y a cependant des inconvénients à l’utiliser dans cette optique et le projet de « Testing Constamment Utilisable » — Constantly Usable Testing (CUT) — tend à les résorber. Cet article présente ce projet ainsi que les défis à surmonter pour y parvenir.

À propos de Debian unstable et Debian testing

Debian unstable est le premier dépôt dans lequel les nouvelles versions des paquets sont envoyées. Il est ainsi très fréquent que certains paquets n’y soient pas utilisables du fait de modifications dans des dépendances ou tout simplement parce que leur mise à jour n’est pas totalement terminée.

Debian testing assure a contrario la cohérence de son écosystème. La nouvelle version d’un paquet dans unstable n’est répliquée dans testing que si le paquet a été suffisamment testé (au bout de 10 jours, habituellement), s’il est exempt de nouveau bogue critique, s’il est disponible pour toutes les architectures supportées, et enfin s’il ne « casse » aucun autre paquet déjà présent dans testing. La Release Team (RT) contrôle ce processus et aide à cibler les ensembles de paquets candidats au passage de unstable vers testing.

Ces dispositions permettent également d’assurer avec une relativement bonne probabilité que les paquets qui migrent vers testing sont exempts de bugs rédhibitoires (qui empêchent le boot par exemple, ou X de démarrer). Cette caractéristique rend testing particulièrement attractive pour les utilisateurs intéressés par les dernières versions des logiciels qu’ils utilisent, débarassées toutefois des plus gros bugs les affectant. Bien que l’exposé fasse apparaître testing très séduisante, les développeurs Debian recommandent de ne pas l’utiliser dans cette optique. Pourquoi donc ?

Problèmes connus dans testing

Disparition de logiciels

La Release Team utilise ce dépôt pour préparer la prochaine version stable et, de temps à autre, en retire des paquets. Soit parce que la migration d’autres paquets de unstable vers testing le requiert, soit parce qu’ils sont affectés par des bugs critiques qui ne semblent pas être en voie de résolution. Il arrive également que des paquets soient retirés sur la demande des mainteneurs de ces derniers, dans la mesure où ils pensent que la version actuelle du paquet ne pourra être maintenue (question sécurité) pour les 2 années à venir ou plus. L’équipe Debian en charge de la sécurité émet également régulièrement de telles requêtes.

Délais de correction important pour les failles de sécurité / bugs importants

Malgré la période d’attente de 10 jours minimum dans unstable, certains bugs « très ennuyeux » ne sont découverts qu’une fois dans testing (y compris les failles de sécurité). Bien que le mainteneur puisse être très rapide à renvoyer une version corrigée dans unstable, voire à élever l’importance de la correction à « urgent » pour accélérer la migration, il arrive que cette dernière doive attendre la fin d’une migration massive de paquets en cours, ce qui peut parfois prendre des semaines.

Cette attente peut être court-circuitée en envoyant le paquet corrigé directement dans testing (via testing-proposed-updates), mais cela n’arrive que rarement hors période de gel, où la résolution d’anomalies bien définies devient la norme.

Pas toujours installable…

Testing évoluant quotidiennement, il arrive que les modifications « brisent » les dernières images d’installation disponibles (les netboot en particulier, permettant de tout récupérer par le réseau). Les paquets de l’installeur Debian sont généralement corrigés rapidement, mais ne migrent pas automatiquement vers testing car la combinaison de tous les paquets de l’installeur n’a pas forcément déjà été validée. Colin Watson résume le problème :

Migrer le nouveau code de l’installeur vers testing prend trop de temps, et par conséquent les anomalies restent non corrigées dans testing pendant trop longtemps. [...] Le problème actuel concernant le développement de l’installeur Debian tient plus du fait que nous sommes trop lents à publier de nouvelles *versions* de ce dernier. [...] Les options qui s’offrent à vous sont soit de travailler avec la version stable (trop vieille), soit la version testing (intéressante sauf lorsque rendue inutilisable, sachant que cela prend une semaine à tout corriger), soit enfin la version instable (perpétuellement brisée).

Origine de CUT

CUT trouve ses origines dans une ancienne proposition de Joey Hess poussant l’idée qu’une version stable n’était pas le seul produit de Debian et que testing pouvait, avec « du travail », devenir un choix viable pour les utilisateurs finaux. Mais personne ne prit à son compte ce « travail » et aucun progrès ne fut fait ces 3 dernières années.

Mais Joey relança récemment la question de TCU sur la liste de diffusion de testing et Stefano Zacchiroli (le chef de projet Debian) le mit au défi de monter un atelier TCU pour DebConf10. Cet atelier fut l’un des plus attendus de la conférence (vidéo disponible ici), témoignant de l’intérêt majeur porté à ce sujet.

Un wiki dédié est maintenant disponible, ainsi qu’une page et une liste de diffusion. La suite de cet article tente de résumer les différentes options proposées et la manière dont elles entendent résoudre les problèmes identifiés.

CUT : choix du mode de fonctionnement

Parmi toutes les solutions possibles, deux approches ont été particulièrement approfondies. La première consiste à faire une image régulière de testing à des états réputés – relativement - stables. Ces images seraient alors nommées « cut ». La seconde serait de bâtir une distribution testing améliorée (« rolling »), conçue pour répondre aux attentes des utilisateurs souhaitant des mises à jour quotidiennes.

Images régulières de testing

La nécessité de telles images « instantanées » de testing recueille un large consensus, étant la seule solution garantissant la viabilité de l’installeur généré jusqu’à la prochaine image. Si l’image générée ne montre aucun problème sérieux, alors elle devient la dernière cut en date. La codification serait de type « cut-AAAA-MM » pour plus de clarté, la cut-2010-09 serait donc l’instantané de septembre 2010 par exemple.

Bien que non définitive, une approche « agressive » de la fréquence de capture des images est plébiscitée : au pire tous les 6 mois, mais une base mensuelle a également été proposée. La décision finale doit prendre en compte plusieurs aspects.

L’un de ceux-ci (et probablement le plus important) tient à la sécurité. Etant donné que l’équipe en charge de la sécurité est déjà sous l’eau, il serait difficile de proclamer que tout instantané sera supporté comme une version stable sans les faire sombrer. A l’inverse, aucun support sécurité semble de prime abord impensable, bien que l’on puisse y objecter un argument de poids : le suivi sécurité de testing est généralement meilleur que celui de la version stable (cf. le security tracker). En effet, les corrections de sécurité arrivent naturellement avec les migrations dans testing. Debian stable obtient toujours les corrections de sécurité importantes plus rapidement que testing mais, dans l’ensemble, il existe moins de failles de sécurité connues dans testing que dans la version stable à un instant donné.

Etant donné que les patches de sécurité ne sont qu’affaire de temps, une fréquence élevée de cut entraîne une obtention plus rapide des correctifs pour les utilisateurs. Mais Stefan Fritsch, qui fit parti autrefois de la Debian testing security team, a également relevé les inconvénients que cela occasionne pour les contributeurs des correctifs de sécurité :

Les mises à jour de sécurité ne sont utiles dans testing que pendant quelques semaines, jusqu’à ce qu’une version corrigée du paquet ne migre depuis unstable. Dans la version stable, les correctifs restent appliquées pendant quelques années, ce qui motive bien plus à les réaliser.

S’il est difficile de former une équipe chargée de la sécurité dédiée, alors le travail d’application des correctifs de sécurité incombe aux mainteneurs des paquets concernés. Ceux-ci envoient généralement assez rapidement la version corrigée dans unstable, mais ne prêtent pas attention à la migration de la version vers testing — ce dont on ne peut les blâmer : testing étant initialement prévue pour préparer la prochaine version stable, il n’y a aucune urgence à ce que la correction y parvienne, tant qu’elle intervient avant le lancement de la nouvelle version stable.

CUT peut précisément aider à faire bouger les lignes sur ce point, étant donné qu’à travers elle des utilisateurs finaux seront censés utiliser au quotidien des paquets de testing, et qu’ils méritent donc des mises à jour de sécurité au même titre que ceux utilisant la version stable.

Un autre aspect à considérer quant à la détermination de la fréquence de cut est l’ensemble du travail demandé pour toute sortie de version officielle : tester les montées de version, documenter les changements et préparer les images d’installation. Il semble difficile d’accomplir ce travail tous les mois. Cette fréquence ne permet pas non plus de fournir une nouvelle révision majeure du noyau avec chaque cut (puisque ce dernier est publié tous les 2-3 mois). Or un nouveau noyau est toujours intéressant pour les utilisateurs puisqu’il vient avec son lot de nouveau matériel supporté.

En résumé, la publication d’instantanés apporte une solution au problème d’une testing pas toujours installable, et change la perception qu’ont les mainteneurs de cette dernière, de telle sorte qu’on puisse espérer qu’ils apportent plus d’attention aux mises à jour de sécurité dans testing, et donc dans les cuts. Mais cela ne résout pas la problématique des paquets qui « disparaissent ». Une autre approche est nécessaire pour adresser ce problème.

Une nouvelle distribution rolling?

Lucas Nussbaum a mis en évidence que des instantanés de Debian n’étaient pas vraiment un concept novateur :

En quoi cela se différencierait-il des autres distributions s’imposant un cycle de publication de 6 mois, et en particulier d’Ubuntu, qui s’apparente déjà à une image instantanée de Debian (+ valeur ajoutée) ?

CUT ne devient intéressante pour Lucas que si elle est capable de fournir une distribution type rolling release (à l’instar de testing) avec un « flux constant de publications amont ». Ce serait pour lui « unique dans le monde du Logiciel Libre ». Les instantanés seraient utilisés comme point de départ pour l’installation, et le système installé pointerait vers les archives de la distribution, de telle sorte que les utilisateurs mettraient à jour aussi souvent qu’ils le désireraient. Les mises à jour de sécurité ne sont pas très importantes dans ce scénario, au contraire de l’état de la distribution.

Mais si c’est testing qui fait office de distribution rolling release, le problème des paquets qui disparaissent inopinément n’est pas résolu. C’est la raison pour laquelle l’introduction d’une nouvelle distribution nommée rolling a été proposée. Celle-ci serait similaire à testing, mais avec quelques règles propres. Les images instantanées seraient effectuées à partir de celle-ci plutôt qu’à partir de testing.

La solution basique consiste à faire une copie de testing en y ré-introduisant les paquets qui en ont été enlevés, pour les raisons préalablement mentionnées qui n’ont plus de raison d’être pour une distribution constamment mise à jour. L’exemple le plus récent étant Chromium).

Toujours dans l’optique d’une rolling release, il faudrait reconfigurer rolling pour pointer directement vers unstable lors des périodes de gel de testing. Cette dernière n’étant alors plus mise automatiquement à jour.

De par ses publications fréquentes, seul un sous-ensemble d’architectures serait supporté, ce qui n’est pas réellement un problème puisque les utilisateurs souhaitant les toutes dernières fonctionnalités tournent la plupart du temps sur des architectures i386/amd64 (voire armel pour les tablettes et produits mobiles similaires). Ce choix — si acté — permettrait même d’envisager une migration plus rapide de certains paquets vers rolling par rapport à testing, notamment ceux qui sont simplement pénalisés par le retard de certaines architectures en terme d’auto-compilation (par les buildd).

Mais si précéder testing peut être un point positif pour les utilisateurs, cela peut être également problématique sous divers aspects : tout d’abord le travail de la Release Team ne pourrait plus être réutilisé en l’état, rendant la gestion de rolling beaucoup plus compliquée. Cela introduirait ensuite une compétition entre les deux distributions, ce qui pourrait avoir comme corollaire une plus grande difficulté de publication de la version stable, si par exemple les mainteneurs ne se soucient plus que de l’arrivée de leurs paquets dans rolling.

L’idée d’une distribution type rolling release n’en reste pas moins une belle idée, mais dont les règles de gestion doivent être construites avec soin pour éviter toute perturbation du processus de publication de la version stable. Elle aurait au moins le mérite de nous débarrasser du problème marketing qui entâche testing, à savoir que son nom même suggère qu’elle n’est pas prête à être utilisée.

Conclusion

Même si tout reste à faire pour que CUT se concrétise, le démarrage est encourageant : Joerg Jaspert (responsable FTP) a d’ores et déjà déclaré que le nouveau serveur d’archives pourrait supporter une nouvelle distribution, et une proposition est à l’étude. Le projet pourrait commencer rapidement : un plan d’implémentation existe déjà pour le volet « instantané »; l’aspect rolling pourra toujours être introduit par la suite, une fois prêt. L’une et l’autre approche sont complémentaires et apportent chacune des éléments utiles à des populations différentes d’utilisateurs.

La proposition dans son ensemble est séduisante : contrer « l’obsolescence » des versions stables Debian par des publications intermédiaires. Quiconque souhaitant une version actuelle pour le support de matériels récents commencerait par l’installation d’une image instantanée, dont il suivrait les cuts ultérieures jusqu’à la publication finale. Les utilisateurs cherchant toujours les dernières versions de paquets utiliseraient quant à eux le système de rolling après avoir installé un instantané.

Du point de vue utilisateur, on peut apercevoir une proximité avec l’alternance de versions normales et de versions à long support d’Ubuntu. Mais le processus serait considérablement différent du point de vue développement, d’autant plus que les contraintes imposées par une distribution constamment opérationnelle sont plus fortes : tout changement à grande échelle doit être introduit progressivement de manière à ce qu’il soit transparent pour l’utilisateur.

Cet article est une traduction de Can Debian offer a Constantly Usable Testing distribution? 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.