J'envisageais de faire une petite rétrospective "d-i vs. Debian 11" sur le blog de ma boîte, comme je travaille trop et ne rédige pas assez, c'est encore sur une todo-list... → C'est parti pour quelques réponses en commentaire sur cette dépêche, en te remerciant pour les questions.
Tu peux jeter un œil aux annonces publiées sur la liste debian-devel-announce@, à savoir une annonce par version publiée (Alpha ou RC). Dans chacune, j'essaie de reprendre les changements dans les composants individuels qui peuvent être impactants pour les utilisateurs (plus rarement les développeurs) du système d'installation, et de les résumer à destination des utilisateurs avancés.
Par exemple, pour le cycle de publication de Debian 11 :
C'est donc le debian-installer de la RC 3 qui est utilisé pour Debian 11.0, puisque nos développements de dernière minute n'ont pas explosé en vol.
C'est principalement de la maintenance corrective, ou ce qui semble maintenant s'appeler du « maintien en condition opérationnelle ». La base de code n'est pas toute récente, elle pourrait bénéficier de simplifications, réécritures, etc. (notamment en ce qui concerne la gestion des différentes architectures) mais globalement le système d'installation actuel a une certaine flexibilité (mode texte, mode graphique, installation par SSH ou console série, démarrage par le réseau, etc.), et les investissements en temps/énergie pour le maintenir en état sont relativement raisonnables. À titre personnel, j'aurais aimé avoir plus de temps à y consacrer pendant ce cycle de publication, et les évolutions pour la gestion des micrologiciels sont arrivées bien tard (cf. introduction de l'annonce D-I Bullseye RC 3), mais elles ont fini par arriver...
Cela étant dit, il ne s'agit pas que de corriger les problèmes quand ils apparaissent. Comme cela peut être constaté en parcourant les annonces mentionnées ci-dessus, il y a régulièrement de petites améliorations à gauche à droite dans tel ou tel composant, à la demande d'utilisateur, ou parce que telle technologie de stockage/réseau/autre propose des options supplémentaires, etc.
Dans les évolutions nécessaires durant le nouveau cycle de publication (Debian 12), il y a le passage de GTK 2 à GTK 3 ou 4. Les premiers paquets GTK 3 n'étaient pas utilisables directement dans le contexte du système d'installation, donc cela a traîné. Simon McVittie a indiqué que le passage à GTK 3+ supposera de revoir l'architecture. Nous ne sommes pas passés loin de la catastrophe à forcer de rester sur GTK 2, d'où mes chaleureux remerciements en introduction de l'annonce D-I Bullseye RC 2 (cf. les entrées cdebconf et gtk+2.0 pour plus de détails).
J'ai également des patches qui traînent depuis des années pour proposer, par exemple à mi-chemin du cycle de publication, des images d'installation de stable qui utiliseraient le noyau de stable-backports afin de simplifier l'installation sur du matériel tout récent, mais il faudrait changer quelques composants (comme base-installer) pour avoir une intégration propre. J'espère que Steve McIntyre (debian-cd) et moi (debian-boot) arriverons à trouver le temps d'intégrer cela dans les mois qui viennent. Note : Il s'agit des noms historiques, debian-cd s'occupe « bien évidemment » de produire les images d'installation pendant que debian-boot s'occupe de produire le système d'installation à intégrer dans lesdites images.
Peut-être aurons-nous aussi un jour une nouvelle résolution générale concernant les micrologiciels, et peut-être pourrons-nous proposer des images qui ne soient plus marquées au fer rouge de l'aspect unofficial. Cela étant, je ne considère pas qu'une telle évolution relève des prérogatives de l'équipe du système d'installation (debian-boot) ou de celle qui gère les images d'installation (debian-cd), et Steve semble d'accord sur ce point : c'est au niveau du projet tout entier que cela devrait être discuté, et validé. Cf. mon premier message sur le rapport de bogue #989863.
Il y a plus ou moins régulièrement des personnes qui veulent révolutionner le système d'installation. Elles sont libres de proposer des alternatives, et c'est ensuite au projet Debian en général et à l'équipe qui gère le site web, etc. de voir ce qui est mis en avant et comment. Je note qu'un certain nombre de telles propositions reposent sur des images autonomes (« live ») que nous avons déjà du mal à produire... Nous avons d'ailleurs déjà une alternative à D-I (Calamares).
Pour ma part, je contribue à maintenir l'existant depuis bientôt 10 ans (mon tout premier message sur debian-devel-announce@ date de mai 2012), et bien qu'imparfait, cela permet d'installer Debian de versions majeures en versions majeures... Ce n'est pas forcément fascinant côté utilisateur, mais il me semble que cette constance colle plutôt à la réputation de stabilité de Debian.
[^] # Re: Évolutions de l'installeur
Posté par Cyril Brulebois (site web personnel) . En réponse à la dépêche Sortie de Debian 11 « Bullseye ». Évalué à 10.
J'envisageais de faire une petite rétrospective "d-i vs. Debian 11" sur le blog de ma boîte, comme je travaille trop et ne rédige pas assez, c'est encore sur une todo-list... → C'est parti pour quelques réponses en commentaire sur cette dépêche, en te remerciant pour les questions.
Tu peux jeter un œil aux annonces publiées sur la liste
debian-devel-announce@, à savoir une annonce par version publiée (Alpha ou RC). Dans chacune, j'essaie de reprendre les changements dans les composants individuels qui peuvent être impactants pour les utilisateurs (plus rarement les développeurs) du système d'installation, et de les résumer à destination des utilisateurs avancés.Par exemple, pour le cycle de publication de Debian 11 :
C'est donc le
debian-installerde la RC 3 qui est utilisé pour Debian 11.0, puisque nos développements de dernière minute n'ont pas explosé en vol.C'est principalement de la maintenance corrective, ou ce qui semble maintenant s'appeler du « maintien en condition opérationnelle ». La base de code n'est pas toute récente, elle pourrait bénéficier de simplifications, réécritures, etc. (notamment en ce qui concerne la gestion des différentes architectures) mais globalement le système d'installation actuel a une certaine flexibilité (mode texte, mode graphique, installation par SSH ou console série, démarrage par le réseau, etc.), et les investissements en temps/énergie pour le maintenir en état sont relativement raisonnables. À titre personnel, j'aurais aimé avoir plus de temps à y consacrer pendant ce cycle de publication, et les évolutions pour la gestion des micrologiciels sont arrivées bien tard (cf. introduction de l'annonce D-I Bullseye RC 3), mais elles ont fini par arriver...
Cela étant dit, il ne s'agit pas que de corriger les problèmes quand ils apparaissent. Comme cela peut être constaté en parcourant les annonces mentionnées ci-dessus, il y a régulièrement de petites améliorations à gauche à droite dans tel ou tel composant, à la demande d'utilisateur, ou parce que telle technologie de stockage/réseau/autre propose des options supplémentaires, etc.
Dans les évolutions nécessaires durant le nouveau cycle de publication (Debian 12), il y a le passage de GTK 2 à GTK 3 ou 4. Les premiers paquets GTK 3 n'étaient pas utilisables directement dans le contexte du système d'installation, donc cela a traîné. Simon McVittie a indiqué que le passage à GTK 3+ supposera de revoir l'architecture. Nous ne sommes pas passés loin de la catastrophe à forcer de rester sur GTK 2, d'où mes chaleureux remerciements en introduction de l'annonce D-I Bullseye RC 2 (cf. les entrées
cdebconfetgtk+2.0pour plus de détails).J'ai également des patches qui traînent depuis des années pour proposer, par exemple à mi-chemin du cycle de publication, des images d'installation de
stablequi utiliseraient le noyau destable-backportsafin de simplifier l'installation sur du matériel tout récent, mais il faudrait changer quelques composants (commebase-installer) pour avoir une intégration propre. J'espère que Steve McIntyre (debian-cd) et moi (debian-boot) arriverons à trouver le temps d'intégrer cela dans les mois qui viennent. Note : Il s'agit des noms historiques,debian-cds'occupe « bien évidemment » de produire les images d'installation pendant quedebian-boots'occupe de produire le système d'installation à intégrer dans lesdites images.Peut-être aurons-nous aussi un jour une nouvelle résolution générale concernant les micrologiciels, et peut-être pourrons-nous proposer des images qui ne soient plus marquées au fer rouge de l'aspect unofficial. Cela étant, je ne considère pas qu'une telle évolution relève des prérogatives de l'équipe du système d'installation (
debian-boot) ou de celle qui gère les images d'installation (debian-cd), et Steve semble d'accord sur ce point : c'est au niveau du projet tout entier que cela devrait être discuté, et validé. Cf. mon premier message sur le rapport de bogue #989863.Il y a plus ou moins régulièrement des personnes qui veulent révolutionner le système d'installation. Elles sont libres de proposer des alternatives, et c'est ensuite au projet Debian en général et à l'équipe qui gère le site web, etc. de voir ce qui est mis en avant et comment. Je note qu'un certain nombre de telles propositions reposent sur des images autonomes (« live ») que nous avons déjà du mal à produire... Nous avons d'ailleurs déjà une alternative à D-I (Calamares).
Pour ma part, je contribue à maintenir l'existant depuis bientôt 10 ans (mon tout premier message sur
debian-devel-announce@date de mai 2012), et bien qu'imparfait, cela permet d'installer Debian de versions majeures en versions majeures... Ce n'est pas forcément fascinant côté utilisateur, mais il me semble que cette constance colle plutôt à la réputation de stabilité de Debian.Debian Consultant @ DEBAMAX