Le vote général sur les systèmes d'initialisation Debian a commencé

Projet Debian объявил au début vote général (GR, résolution générale) porteurs de projets pour problème de prise en charge de plusieurs systèmes d'initialisation, qui déterminera la politique future du projet concernant la liaison à systemd, la prise en charge de systèmes d'initialisation alternatifs et l'interopérabilité avec les distributions dérivées qui n'utilisent pas systemd. Le vote durera jusqu'au 27 décembre inclus, les résultats seront annoncés le 28 décembre.

Rappelons qu'en 2014 le comité technique approuvé transition distribution par défaut sur systemd, mais pas élaboré décisions concernant la prise en charge de plusieurs systèmes d'approvisionnement (le vote a été remporté par le point indiquant la réticence du comité à prendre une décision sur cette question). 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.

Le vote actuel permettra d'adopter une politique concernant les systèmes d'approvisionnement multiples, et si la clause exigeant la prise en charge de systèmes alternatifs l'emporte, les responsables ne pourront pas ignorer ou retarder ces problèmes. Après avoir discuté des trois points de vote initialement proposés par le porteur du projet, le nombre d'options a été porté à huit. Lors du vote, vous pouvez sélectionner plusieurs éléments à la fois, en classant les éléments sélectionnés par niveau de préférence. Environ un millier de développeurs qui participent à la maintenance des packages et à la maintenance de l'infrastructure ont le droit de vote.

Options suggéré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.
  • 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.

  • 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 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 proche, 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 ils refusent de la sauvegarder (par exemple, lorsque le problème est causé par la suppression d'un script d'initialisation fourni précédemment).
  • 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