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.

5 raisons pour lesquelles Debian unstable ne mérite pas son nom

Debian unstable (également connue sous le nom de sid) est l’une des 3 distributions proposées par Debian (les deux autres étant stable et testing).

Elle n’est pas conçue comme un produit pour les utilisateurs finaux, son rôle essentiel est de servir de dépôt pour les toutes dernières versions de paquets envoyés par les contributeurs, et ce quotidiennement. unstable est donc perpétuellement en évolution rapide, et par conséquent pas nécessairement appropriée pour tout public. Ceci étant, il est possible de l’utiliser sans que votre ordinateur n’explose !

1. unstable contient principalement des versions stables de logiciels

Oui oui, vous avez bien lu. unstable ne contient pas tout plein de versions de développement bien que, ponctuellement pour certains logiciels, ce soit le cas. Il s’agit la plupart du temps d’une décision réfléchie de la part du mainteneur de paquets, considérant qu’en l’état cette version particulière est déjà supérieure à l’ancienne.

Ceci s’explique par le fait que sid est l’antichambre de testing, dépôt où la prochaine version stable est préparée. Les mainteneurs ne doivent donc y envoyer que des paquets d’une qualité suffisante en vue de la publication, le reste devant prendre le chemin de experimental.

2. Elle ne crashe pas tous les jours

Des dysfonctionnements surviennent, mais ne sont en règle générale ni sérieux, ni difficiles à corriger. Voilà un bout de temps maintenant qu’il ne m’est pas arrivé, après une mise à jour, de ne plus pouvoir redémarrer mon ordinateur, ou que l’interface graphique soit non fonctionnelle. La plupart du temps, les dysfonctionnements rencontrés prennent la forme d’un logiciel cessant de fonctionner ou souffrant d’un bogue nouveau, ou bien que certains paquets ne puissent plus être installés.

Vous pouvez vous en sortir, dans la grande majorité des cas, en installant la version du paquet incriminé présente dans testing, ou en trouvant dans le suivi des bogues un moyen de contourner le problème. Il est également possible de prévenir plutôt que de guérir : apt-listbugs, en vous prévenant du problème, peut vous dissuader de mettre à jour.

3. Elle est à la base d’autres distributions

Si Debian unstable était de si piètre qualité, elle ne servirait pas de base de départ pour des distributions dérivées. Logique, non ? Deux exemples basées sur sid parmi d’autres : Ubuntu et Sidux Aptosid.

4. Sa conception ne la rend pas moins sécurisée que stable ou testing

Les vulnérabilités importantes sont généralement rapidement corrigées dans stable et unstable. L’équipe chargée de la sécurité s’occupe de stable, tandis que la correction d’unstable revient aux mainteneurs des paquets concernés. testing récupère généralement la correction à travers la mise à jour des paquets provenant d’unstable, entraînant ainsi une latence à l’obtention des corrections.

Les problèmes de sécurités d’importance moindre peuvent n’entraîner aucune correction dans stable. Dans ce cas, les utilisateurs de testing/unstable sont mieux servis, dans la mesure où ils récupèreront la correction avec la nouvelle version du paquet, quoi qu’il arrive.

Bien évidemment, il peut arriver que les mainteneurs soient particulièrement occupés ou que certaines failles arrivent quand même à se faufiler. Si le mainteneur ne réagit pas, d’autres personnes examinant les bogues RC (Release Critical) proposeront les corrections nécessaires.

5. Je l’utilise sur mon ordinateur principal

Et je ne suis pas le seul ! Vous pouvez le faire également si vous remplissez les conditions suivantes :

  • vous savez utiliser la ligne de commande (du moins suffisamment pour rétrograder de version un paquet, éditer des fichiers de configuration, …) ;
  • vous connaissez le fonctionnement d’APT et l’utilisation simultanée de plusieurs dépôts dans /etc/apt/sources.list ;
  • l’anglais lu/écrit n’est pas un problème, de telle sorte que vous pouvez lire/écrire les rapports de bogue, le cas échéant ;
  • vous disposez d’un autre ordinateur relié à Internet, d’où vous pouvez rechercher de la documentation (ou le système de suivi des bogues, ou les listes de diffusion dédiées au support) lorsque votre ordinateur principal est hors service pour une raison qui vous échappe.

Si vous ne vous sentez pas prêt à faire le grand saut, vous pouvez vous abonner à ce blog (ou vous abonner au flux RSS), dans la mesure où je posterai certainement d’autres articles permettant d’acquérir les compétences nécessaires pour y arriver.

PS: Sans renier ce qui précède, si vous avez une installation fonctionnelle de sid, n’allez pas jusqu’à la mettre à jour juste avant une importante présentation, ou un voyage : le crash a toujours lieu au pire moment. À moins que vous ne vous sentiez l’âme d’un aventurier, bien sûr !

Cet article est une traduction de 5 reasons why Debian Unstable does not deserve its name contribuée par Weierstrass01. Suivez moi sur Identi.ca, Twitter et Facebook.

Comment Ubuntu s’appuie sur Debian pour son développement

Dans quelle mesure Ubuntu est-elle liée à Debian ? De quelle façon les paquets « migrent »-ils de l’un vers l’autre ? Cet article est une ébauche de réponse à ces questions qui m’ont été posées.

D’où viennent les paquets ?

La plupart des paquets ont été créés par des contributeurs Debian, et uploadés dans dans Debian unstable (ou experimental). Les nouveaux paquets sont passés en revue par les ftpmasters Debian pour acceptation dans l’archive officielle. Le temps de l’audit, ces paquets sont conservés dans une file d’attente dédiée, pour une durée allant de quelques heures à quelques mois (une à deux semaines généralement).

Ubuntu importe tous les paquets Debian officiels, auxquels s’ajoutent leurs propres paquets. Environ 7% de la base de paquets Ubuntu correspondent à des applications tierces empaquetées pour Ubuntu et non pour Debian.

Quelles sont les modifications faites par Ubuntu ?

De tous les paquets en provenance de Debian, 17% incluent des modifications supplémentaires faites par Ubuntu. La plupart des paquets concernés appartiennent au dépôt main, qui est activement maintenu par Canonical et les core developers d’Ubuntu. Le dépôt universe est quant à lui beaucoup plus fidèle aux paquets Debian d’origine.

La plupart des modifications faites par Ubuntu sont motivées par les décisions prises lors du Ubuntu Developer Summit. Celles-ci tendent vers des objectifs bien précis : meilleure interface utilisateur, temps de démarrage plus rapide, meilleure accessibilité en tant que plateforme pour les applications tierces, intégration avec leurs propres services en ligne (Launchpad, Ubuntu One), etc. Les autres modifications sont le fruit des corrections de bogues soumis par les utilisateurs d’Ubuntu.

Il est à noter que même les paquets binaires Ubuntu n’ayant pas subi de modifications au niveau de leurs sources diffèrent de la version binaire Debian. Il s’agit là d’une conséquence du changement d’environnement de compilation réalisé par Ubuntu : ils ne supportent que les processeurs type x86 de classe supérieure ou égale à 686, activent des options de compilation que Debian n’activent pas, … Tous les paquets binaires sont de plus modifiés par un programme appelé pkgbinarymangler.

Cycle de publication d’Ubuntu et lien avec Debian

Ubuntu publie une nouvelle version tous les 6 mois (sur le concept des publications à date fixe). Le rapport au temps étant radicalement différent chez Debian, comment Ubuntu parvient-elle à réutiliser le travail de Debian ?

Réponse : en important les paquets de Debian unstable (parfois même d’experimental), ce qui assure la « fraîcheur » des paquets. Si la version Ubuntu du paquet contient déjà des modifications spécifiques à la distribution, elles sont simplement fusionnées dans le paquet Debian nouvellement copié. Dans le cas contraire, le paquet Debian est juste importé, puis recompilé pour Ubuntu… ce qui fonctionne plutôt bien, Debian unstable l’étant beaucoup moins que son nom le laisse supposer.

Cet import automatique ne dure que les deux premiers mois du cycle, jusqu’au gel de l’import Debian. Il reste donc pas mal de temps après coup pour corriger le plus gros des problèmes.

Durant les troisième et quatrième mois, l’import de paquets est toujours possible, mais non automatique : il doit être explicitement demandé par un développeur. A la fin du quatrième mois, le gel des fonctionnalités est décrété, mettant définitivement fin à la période d’import.

Les deux mois restants sont dédiés aux corrections de bogues, ainsi qu’aux finitions de détail. De nombreux gels mineurs interviennent durant cette période, le planning de publication de Natty en donne un exemple. L’import de paquets Debian est maintenant exceptionnel, et autorisé uniquement s’il s’agit de mises à jour correctives côté Debian.

Crédits : certains chiffres sont repris d’une conférence de Lucas Nussbaum, basés sur les paquets disponibles pour la version Lucid Lynx d’Ubuntu.

Cet article est une traduction de How Ubuntu builds up on Debian contribuée par Weierstrass01. Ne manquez pas une occasion de parfaire vos connaissances de Debian ou Ubuntu, abonnez-vous à ma newsletter en cliquant ici.

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.

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.