Les résultats du vote sur les systèmes d'initialisation Debian ont été résumés

Publié résultats vote général (GR, résolution générale) des développeurs du projet Debian impliqués dans la maintenance des paquets et la maintenance de l'infrastructure, réalisée sur la question de la prise en charge de plusieurs systèmes d'initialisation. Le deuxième élément (« B ») de la liste a gagné - systemd reste préféré, mais la possibilité de conserver des systèmes d'initialisation alternatifs demeure. Le vote s'est déroulé selon la méthode Condorcet, dans lequel chaque électeur classe toutes les options par ordre de préférence, et lors du calcul du résultat, le nombre d'électeurs préfèrent une option à une autre est pris en compte.

La proposition gagnante reconnaît que les unités de service systemd constituent le moyen privilégié pour configurer les démons et les services à exécuter, mais reconnaît qu'il existe des environnements dans lesquels les développeurs et les utilisateurs peuvent créer et utiliser des systèmes d'initialisation alternatifs et des alternatives fonctionnelles aux capacités de systemd. Les développeurs de solutions alternatives ont besoin de ressources pour mener à bien leur travail et formater leurs packages. Les solutions alternatives comme elogind pour exécuter des applications liées à des interfaces spécifiques à systemd restent importantes pour le projet. Soutenir de telles initiatives nécessite une assistance dans les domaines où le développement de technologies alternatives recoupe le reste du projet, comme par exemple en retardant l'examen des correctifs et les discussions.

Les packages peuvent inclure à la fois des fichiers d'unité systemd et des scripts d'initialisation pour démarrer les services. Les paquets peuvent utiliser toutes les fonctionnalités systemd souhaitées par le responsable du paquet, à condition que les fonctionnalités soient conformes aux règles Debian et ne soient pas liées à des fonctionnalités Debian expérimentales ou non prises en charge dans d'autres paquets. En plus de systemd, les packages peuvent également inclure la prise en charge de systèmes d'initialisation alternatifs et fournir des composants pour remplacer les interfaces spécifiques à systemd. Les décisions concernant l'inclusion de correctifs sont prises par les responsables dans le cadre de procédures standard. Debian s'engage à travailler avec des distributions dérivées qui choisissent d'utiliser d'autres systèmes d'initialisation, mais l'interaction est construite au niveau du responsable, qui décide quelles fonctionnalités préparées par des distributions tierces sont acceptées dans la composition principale de Debian et lesquelles sont laissées. dans la distribution dérivée.

Rappelons qu'en 2014 le comité technique approuvé transition distribution par défaut sur systemd, mais pas élaboré les décisions concernant la prise en charge de plusieurs systèmes d'approvisionnement (le point indiquant la réticence du comité à prendre une décision sur cette question a remporté le vote). Le chef du comité a recommandé aux responsables du paquet de maintenir le support de sysvinit comme système d'initialisation alternatif, mais a indiqué qu'il ne pouvait pas imposer son point de vue et que la décision devait être prise indépendamment dans chaque cas.

Après cela, certains développeurs ont tenté tenter de réaliser vote général, mais le vote préliminaire a montré qu'il n'était pas nécessaire de prendre une décision sur la question de l'utilisation de plusieurs systèmes d'initialisation. Il y a quelques mois, après проблем avec l'inclusion du paquet elogind (nécessaire pour exécuter GNOME sans systemd) dans la branche testing en raison d'un conflit avec libsystemd, le problème a de nouveau été soulevé par le chef du projet Debian, car les développeurs n'ont pas pu s'entendre et leur communication s'est transformée en un confrontation et aboutit à une impasse.

Options envisagées :

  • L'accent principal est mis sur systemd. Fournir un support pour des systèmes d'initialisation alternatifs n'est pas une priorité, mais les responsables peuvent éventuellement inclure des scripts d'initialisation pour de tels systèmes dans les packages.
  • systemd reste préféré, mais la possibilité de maintenir des systèmes d'initialisation alternatifs est laissée. Des technologies telles que elogind, qui permettent aux applications liées à systemd de s'exécuter dans des environnements alternatifs, sont considérées comme importantes. Les packages peuvent inclure des fichiers d'initialisation pour des systèmes alternatifs.
  • Prise en charge d'une variété de systèmes d'initialisation et possibilité de démarrer Debian avec des systèmes d'initialisation autres que systemd.
    Pour exécuter des services, les packages doivent inclure des scripts d'initialisation ; fournir uniquement des fichiers d'unité systemd sans scripts d'initialisation sysv est inacceptable.

  • Prise en charge des systèmes qui n'utilisent pas systemd, mais sans apporter de modifications qui gêneraient le développement. Les développeurs acceptent de prendre en charge plusieurs systèmes d'initialisation dans un avenir prévisible, mais estiment également qu'il est nécessaire de travailler à l'amélioration de la prise en charge de systemd. Le développement et la maintenance de solutions spécifiques doivent être laissés aux communautés intéressées par ces solutions, mais les autres responsables doivent activement aider et contribuer à la résolution des problèmes lorsque le besoin s'en fait sentir. Idéalement, les packages devraient fonctionner en utilisant n'importe quel système d'initialisation, ce qui peut être réalisé en fournissant des scripts d'initialisation traditionnels ou en utilisant d'autres mécanismes leur permettant de fonctionner sans systemd. L'incapacité de travailler sans systemd est considérée comme un bug, mais pas comme un bug bloquant la version, à moins qu'il n'existe une solution toute faite pour travailler sans systemd, mais sa sauvegarde est refusée (par exemple, lorsque le problème est causé par le suppression d'un script d'initialisation précédemment fourni).
  • Prend en charge la portabilité sans introduire de modifications qui entravent le développement. Debian continue d'être considérée comme un pont permettant d'intégrer différents logiciels offrant des fonctionnalités équivalentes ou similaires. La portabilité entre les plates-formes matérielles et les piles logicielles est un objectif important, et l'intégration de technologies alternatives est encouragée, même si la vision du monde de leurs créateurs diffère du consensus général. La position concernant systemd et les autres systèmes d'initialisation coïncide complètement avec le point 4.
  • Rendre obligatoire la prise en charge de plusieurs systèmes d’initialisation. Offrir la possibilité d'exécuter Debian avec des systèmes d'initialisation autres que systemd continue d'être important pour le projet. Chaque package doit fonctionner avec des gestionnaires pid1 autres que systemd, sauf si le logiciel inclus dans le package était initialement destiné à fonctionner uniquement avec systemd et ne prend pas en charge l'exécution sans systemd (l'absence de scripts d'initialisation ne compte pas comme destiné uniquement à travailler avec systemd) .
  • Prend en charge la portabilité et plusieurs implémentations. Les principes généraux sont exactement les mêmes que ceux du point 5, mais il n'y a pas d'exigences spécifiques pour les systèmes systemd et init, et aucune obligation n'est imposée aux développeurs. Les développeurs sont encouragés à prendre en compte les intérêts de chacun, à faire des compromis et à trouver des solutions communes satisfaisantes pour les différentes parties.
  • Discussion continue. L’élément peut être utilisé pour rétrograder des options inacceptables.
  • Source: opennet.ru

    Ajouter un commentaire