Sam Hartmann, le chef de projet Debian, essayé de résoudre les désaccords concernant la livraison du colis elogind dans le cadre de la distribution. En juillet, l'équipe chargée de préparer les lancements bloqué l'inclusion d'elogind dans la branche test, puisque ce paquet est en conflit avec libsystemd.
Comme raison de plantage, il y avait un conflit avec le paquet systemd et le danger de remplacer libsystemd avec une version alternative de libelogind, qui est totalement incompatible avec la bibliothèque source au niveau ABI.
L'inclusion d'elogind fournit sa propre version de la bibliothèque libelogind, qui reprend un certain nombre de fonctions offertes par libsystemd et remplace cette bibliothèque lors de l'installation.
Dans le paquet, elogind est marqué 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 même bénéfique car il ne vous permet pas d'installer elogind par erreur.
D'autre part, dans la forme actuelle, les tentatives via APT de mettre à jour la configuration de systemd vers la version avec sysvinit et elogind entraînent un système corrompu avec un APT inopérant. Mais même avec la suppression de cette faille, le passage de systemd à elogind est toujours impossible sans supprimer les environnements utilisateurs déjà installés.
Sur quoi les développeurs Elogind ont été invités à adapter l'éloge funèbred pour travailler sur le libpam-systemd normal, sans utiliser sa propre couche libpam-elogind.
La transition d'elogind à libpam-systemd est entravée par le manque de prise en charge du concept de secteurs, mais les développeurs d'elogind ne veulent pas atteindre une conformité API complète et répéter exactement toutes les fonctionnalités de systemd car elogind ne fournit que des fonctionnalités minimales pour organiser connexions utilisateur et il n'est pas prévu de répéter tous les sous-systèmes de systemd.
La résolution des problèmes techniques décrits doit être résolue au niveau de l'interaction entre l'équipe de publication et les responsables d'elogind et de systemd, mais le chef de projet a été contraint d'intervenir car les équipes ne pouvaient s'entendre, le travail commun s'est transformé en confrontation et la solution du problème a atteint une impasse, dans laquelle chaque côté du droit à sa manière.
Selon Sam Hartman, la situation se rapproche d'un état qui nécessite un vote général (GR, résolution globale), dans lequel la communauté décidera des systèmes alternatifs pour initialiser et supporter sysvinit avec elogind.
Si les participants au projet votent pour diversifier les systèmes d'initialisation, tous les responsables de la maintenance participeront à un effort conjoint pour résoudre ce problème ou des développeurs responsables spéciaux seront nommés pour travailler sur ce problème et ceux qui les accompagnent ne pourront plus contourner le système d'initialisation alternatif, garder le silence ou retarder le processus.
Actuellement, le référentiel a déjà accumulé 1033 packages qui fournissent des unités de service pour systemd, mais n'incluent pas les scripts init.d.
Pour résoudre ce problème, il est proposé de fournir des fichiers de service par défaut, mais de préparer un pilote qui analyse automatiquement les commandes de ces fichiers et génère des scripts init.d basés sur eux.
Si la communauté décide que Debian a suffisamment de support pour un seul système d'initialisation, elle n'a plus à se soucier de sysvinit et elogind, se concentrant uniquement sur les fichiers unit et systemd.
Une telle solution affectera négativement les ports qui n'utilisent pas le noyau Linux, mais il n'y a pas encore de tels ports dans le fichier principal et ils n'ont pas de statut de support officiel.
Lien vers systemd compliquera également considérablement le changement dans le sens du développement de la distribution à l'avenir et limitera les expériences ultérieures dans le domaine de l'initialisation et de la gestion des services.
Chaque solution a ses avantages et ses inconvénients, de sorte qu'une discussion approfondie de tous les arguments pour et contre sera nécessaire avant le vote.
source: https://lists.debian.org/
Il n'est donc toujours pas sûr qu'ils supporteront à nouveau sysvinit !! D'après ce que j'ai compris, ils vont le soumettre pour étude et vote !! Nous allons voir ce qui se passe!!
Non
Le cirque Debian "s'est déjà montré" avec la "décision" risible d'adopter systemd. Maintenant, ils ne reculeront pas, de sorte qu'un éventuel "vote général" a déjà été annoncé. Pour moi, continuez à jouer avec systemd. Q ils vont finir pendu est aussi un autre résultat chanté.