Debian revient au support de plusieurs systèmes d'initialisation

Sam Hartman, chef du projet Debian, essayé comprendre les désaccords liés à la livraison du package elogind dans le cadre de la distribution. En juillet, l'équipe chargée de préparer les sorties bloqué inclusion d'elogind dans la branche testing, car ce paquet est en conflit avec libsystemd.

Rappelons que elogind fournit les interfaces nécessaires pour exécuter GNOME sans installer systemd. Le projet a été fondé comme un fork de systemd-logind, placé dans un package séparé et libéré de toute liaison aux composants systemd. Entre autres choses, elogind fournit sa propre version de la bibliothèque libelogind, qui reprend un certain nombre de fonctions proposées dans libsystemd et remplace cette bibliothèque lors de l'installation.

Les raisons du blocage étaient un conflit avec le package systemd et le danger de remplacer libsystemd par une alternative libelogind, totalement incompatible avec la bibliothèque source au niveau ABI.
Le paquet étiquette elogind comme étant en conflit avec les bibliothèques systemd, mais il est intrinsèquement conçu pour fonctionner uniquement sans systemd, et un conflit avec systemd est en fait bénéfique car il empêche elogind d'être installé par erreur. En revanche, dans sa forme actuelle, les tentatives via APT de mettre à jour la configuration de systemd vers la version avec sysvinit et elogind aboutissent à système endommagé avec APT ne fonctionne pas. Mais même si cette lacune est éliminée, la transition de systemd vers elogind reste impossible sans supprimer les environnements utilisateurs déjà installés.

Les développeurs d'elogind étaient Proposé par adapter elogind pour qu'il fonctionne au-dessus du standard libpam-systemd, sans utiliser sa propre couche libpam-elogind. La transition d'elogind vers libpam-systemd est entravée par le manque de prise en charge du concept de tranches, mais les développeurs d'elogind ne veulent pas se conformer pleinement à l'API et répéter exactement toutes les capacités de systemd, car elogind ne fournit que des fonctionnalités minimales. fonctionnalité permettant d'organiser les connexions des utilisateurs et ne vise pas à répliquer tous les sous-systèmes systemd.

La résolution des problèmes techniques décrits devrait être résolue au niveau de l'interaction entre l'équipe de publication et les responsables d'elogind et systemd, mais le chef de projet a été contraint d'intervenir car les équipes ne parvenaient pas à se mettre d'accord, le travail commun s'est transformé en confrontation et la solution au Le problème était dans une impasse, dans laquelle chaque partie avait raison à sa manière. Selon Sam Hartman, la situation se rapproche d'un état nécessitant un vote général (GR, résolution générale), dans lequel la communauté décidera des systèmes alternatifs d'initialisation et de prise en charge de sysvinit avec elogind.

Si les membres du projet votent en faveur de la diversification des systèmes d'initialisation, tous les responsables seront impliqués dans une collaboration pour résoudre ce problème ou des développeurs spécifiques seront chargés de travailler sur ce problème et les responsables ne pourront plus ignorer un système d'initialisation alternatif, rester silencieux ou retarder le processus.

Actuellement dans le référentiel déjà accumulé 1033 packages qui fournissent des unités de service pour systemd, mais n'incluent pas de scripts init.d. Pour résoudre ce problème proposé fournir des fichiers de service par défaut, mais préparer un gestionnaire qui analyserait automatiquement les commandes de ces fichiers et générerait des scripts init.d basés sur eux.

Si la communauté décide que Debian prend suffisamment en charge un seul système d'initialisation, nous ne pouvons plus nous soucier de sysvinit et elogind et nous concentrer uniquement sur les fichiers unité et systemd. Cette décision aura un impact négatif sur les ports qui n'utilisent pas le noyau Linux (Debian GNU / Hurd, Debian GNU / NetBSD и Debian GNU / kFreeBSD), mais il n'y a pas encore de ports de ce type dans l'archive principale et ils n'ont pas le statut officiellement soutenu.

La liaison à systemd rendra également beaucoup plus difficile le changement de direction de la distribution à l'avenir et limitera les expérimentations ultérieures dans le domaine de l'initialisation et de la gestion des services. Maintenir elogind sous forme fonctionnelle est beaucoup plus facile que de le supprimer puis d'essayer de l'ajouter à nouveau. Chaque option de décision comporte des avantages et des inconvénients. Une discussion approfondie de tous les avantages et inconvénients sera donc nécessaire avant de voter.

Source: opennet.ru

Ajouter un commentaire