Sam Hartman, chef de projet Debian, s'est penché sur les divergences concernant la fourniture du paquet elogind dans la distribution. En juillet, l'équipe responsable des préparations de versions, a inclus elogind dans la branche testing, car ce paquet entre en conflit avec libsystemd.
Rappelons que fournit les interfaces nécessaires au fonctionnement de GNOME sans installation de systemd. Le projet a été fondé comme un dérivé de systemd-logind, dissocié dans un paquet distinct et libéré de la dépendance à des composants systemd. Entre autres, elogind propose sa propre version de la bibliothèque libelogind, qui assume certaines fonctions offertes par libsystemd et remplace cette bibliothèque lors de son installation.
Parmi les raisons du blocage, le conflit avec le paquet systemd a été mentionné, ainsi que le risque de remplacer libsystemd par une alternative libelogind, complètement incompatible avec la bibliothèque d'origine au niveau de l'ABI.
Le paquet elogind est marqué comme conflit avec les bibliothèques systemd, mais il est essentiellement conçu pour fonctionner uniquement sans systemd, et le conflit avec systemd est même bénéfique, car il empêche par erreur l'installation d'elogind. D'autre part, dans sa forme actuelle, les tentatives via APT de mettre à jour la configuration de systemd vers une option avec sysvinit et elogind entraînent avec un APT non fonctionnel. Mais même en corrigeant ce problème, la transition de systemd à elogind reste impossible sans désinstaller les environnements utilisateurs déjà installés.
Les développeurs d'elogind ont été amener elogind à fonctionner au-dessus de l'implémentation standard de libpam-systemd, sans utiliser sa propre couche libpam-elogind. La transition d'elogind vers libpam-systemd est entravée par l'absence de soutien pour le concept de slices, mais les développeurs d'elogind ne souhaitent pas atteindre une conformité totale avec l'API ni reproduire toutes les fonctionnalités de systemd, car elogind ne fournit que la fonctionnalité minimale pour organiser l'authentification des utilisateurs et n'a pas pour objectif de reproduire tous les sous-systèmes de systemd.
La résolution des problèmes techniques décrits doit être abordée au niveau de l'interaction entre l'équipe de publication et les mainteneurs d'elogind et systemd, mais le leader du projet a dû intervenir car les équipes n'ont pas pu parvenir à un accord, le travail collaboratif s'est transformé en confrontation et la solution du problème est tombée dans un impasse où chaque partie a raison à sa manière. Selon Sam Hartman, la situation approche un état nécessitant un vote général (GR, général resolution), où la communauté prendra une décision concernant les systèmes d'initialisation alternatifs et le support de sysvinit avec elogind.
Si les participants au projet votent pour la diversification des systèmes d'initialisation, tous les mainteneurs seront impliqués dans le travail collaboratif pour résoudre cette tâche ou des développeurs responsables spécifiques seront désignés pour travailler sur ce problème et les mainteneurs ne pourront plus ignorer le système d'initialisation alternatif, rester silencieux ou retarder le processus.
Actuellement, il y a déjà 1033 paquets fournissant des unités de service pour systemd, mais n'incluant pas de scripts init.d. Pour résoudre ce problème, il faudrait fournir par défaut des fichiers de service, mais préparer un gestionnaire qui analyserait automatiquement les commandes de ces fichiers et générerait des scripts init.d basés sur ceux-ci.
Si la communauté décide que Debian n'a besoin que d'un système d'initialisation, il ne sera plus nécessaire de se soucier de sysvinit et elogind, en se concentrant 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 (, et ), mais il n'y a actuellement aucun archive de tels ports et ils n'ont pas le statut .
Une dépendance sur systemd compliquera également considérablement le changement de direction du développement de la distribution à l'avenir et limitera les expérimentations futures en matière d'initialisation et de gestion des services. Maintenir elogind en état de fonctionnement est beaucoup plus facile que de l'éliminer et de tenter de le rajouter ensuite. Chaque option de solution a ses avantages et inconvénients, donc avant le vote, une discussion approfondie sur tous les arguments pour et contre sera nécessaire.
Source : opennet.ru
