Sam Hartman, líder do proxecto Debian, comprender os desacordos asociados á entrega do paquete elogind como parte da distribución. En xullo, o equipo encargado de preparar os lanzamentos inclusión de elogind na rama de proba, xa que este paquete entra en conflito con libsystemd.
Lembre que proporciona as interfaces necesarias para executar GNOME sen instalar systemd. O proxecto foi fundado como un fork de systemd-logind, colocado nun paquete separado e liberado da vinculación aos compoñentes de systemd. Entre outras cousas, elogind proporciona a súa propia versión da biblioteca libelogind, que asume unha serie de funcións ofrecidas en libsystemd e substitúe esta biblioteca durante a instalación.
Os motivos do bloqueo foron un conflito co paquete systemd e o perigo de substituír libsystemd por un libelogind alternativo, que é completamente incompatible coa biblioteca de orixe a nivel ABI.
O paquete etiqueta elogind como en conflito coas bibliotecas systemd, pero está deseñado inherentemente para funcionar só sen systemd, e entrar en conflito con systemd é realmente beneficioso porque evita que elogind se instale por erro. Por outra banda, na súa forma actual, os intentos mediante APT de actualizar a configuración de systemd á versión con sysvinit e elogind dan como resultado con APT non funcionando. Pero aínda que se elimine esta deficiencia, a transición de systemd a elogind segue sendo imposible sen eliminar os contornos de usuarios xa instalados.
Os desenvolvedores de elogind foron adaptar elogind para que funcione sobre libpam-systemd estándar, sen usar a súa propia capa libpam-elogind. A transición de elogind a libpam-systemd vese obstaculizada pola falta de soporte para o concepto de slices, pero os desenvolvedores de elogind non queren acadar o cumprimento total da API e repetir exactamente todas as capacidades de systemd, xa que elogind só ofrece un mínimo. funcionalidade para organizar os inicios de sesión dos usuarios e non pretende replicar todos os subsistemas systemd.
A resolución dos problemas técnicos descritos debería resolverse no nivel de interacción entre o equipo de lanzamento e os mantedores de elogind e systemd, pero o líder do proxecto viuse obrigado a intervir porque os equipos non podían poñerse de acordo, o traballo conxunto desenvolveuse en enfrontamento e a solución o problema chegou a un camiño sen saída, no que cada bando tiña razón á súa maneira. Segundo Sam Hartman, a situación achégase a un estado que require unha resolución xeral (GR), na que a comunidade decidirá sistemas alternativos para init e soporte para sysvinit con elogind.
Se os membros do proxecto votan para diversificar os sistemas de inicio, todos os mantedores participarán no traballo conxunto para resolver este problema ou asignaranse desenvolvedores específicos para traballar neste problema e os mantedores xa non poderán ignorar un sistema de inicio alternativo, permanecer en silencio ou atrasar o proceso.
Actualmente xa no repositorio 1033 paquetes que proporcionan unidades de servizo para systemd, pero non inclúen scripts init.d. Para resolver este problema proporcionar ficheiros de servizo de forma predeterminada, pero preparar un manejador que analizaría automaticamente os comandos destes ficheiros e xeraría scripts init.d baseados neles.
Se a comunidade decide que Debian ten soporte suficiente para un único sistema de inicio, xa non podemos preocuparnos por sysvinit e elogind e centrarnos só nos ficheiros unitarios e systemd. Esta decisión afectará negativamente aos portos que non usan o núcleo de Linux (, и ), pero aínda non hai estes portos no arquivo principal e non teñen o estado .
A vinculación a systemd tamén fará moito máis difícil cambiar a dirección da distribución no futuro e limitará a experimentación adicional no campo da inicialización e da xestión do servizo. Manter elogind en forma de traballo é moito máis doado que borralo e despois tentar engadilo de novo. Cada opción de decisión ten pros e contras, polo que será necesario un debate completo de todos os pros e contras antes de votar.
Fonte: opennet.ru