Sam Hartman, el líder del proyecto Debian, trató de resolver los desacuerdos con respecto a la entrega del paquete elogind como parte de la distribución. En julio, el equipo responsable de preparar los lanzamientos bloqueó la inclusión de elogind en la rama de prueba, ya que este paquete entra en conflicto con libsystemd.

Como motivo de bloqueo, hubo un conflicto con el paquete systemd y el peligro de reemplazar libsystemd con una versión alternativa de libelogind, que es completamente incompatible con la biblioteca fuente en el nivel ABI.

La inclusión de elogind proporciona su propia versión de la biblioteca libelogind, que asume una serie de funciones ofrecidas por libsystemd y reemplaza esta biblioteca durante la instalación.

En el paquete, elogind está marcado como conflictivo con las bibliotecas systemd, pero está diseñado inherentemente para funcionar solo sin systemd y un conflicto con systemd es incluso beneficioso, ya que no le permite instalar elogind por error.

Por otro lado, en la forma actual, los intentos a través de APT para actualizar la configuración de systemd a la versión con sysvinit y elogind resultan en un sistema dañado con un APT inoperativo. Pero incluso con la eliminación de este defecto, la transición de systemd a elogind sigue siendo imposible sin eliminar los entornos de usuario ya instalados.

Con lo cual se pidió a los desarrolladores de Elogind que adaptaran elogind para trabajar sobre el libpam-systemd regular, sin usar su propia capa libpam-elogind.

La transición de elogind a libpam-systemd se ve obstaculizada por la falta de soporte para el concepto de sectores, pero los desarrolladores de elogind no quieren lograr el pleno cumplimiento de la API y repetir exactamente todas las características de systemd, ya que elogind solo proporciona una funcionalidad mínima para organizar los inicios de sesión de los usuarios y no se propone repetir todos los subsistemas de systemd.

La resolución de los problemas técnicos descritos debe resolverse en el nivel de interacción entre el equipo de lanzamiento y los mantenedores de elogind y systemd, pero el líder del proyecto se vio obligado a intervenir porque los equipos no podían ponerse de acuerdo, el trabajo conjunto se convirtió en una confrontación y la solución al problema llegó a un callejón sin salida, en el que cada lado de la ley a su manera.

Según Sam Hartman, la situación se acerca a un estado que requiere un voto general (GR, resolución general), en el que la comunidad decidirá sobre sistemas alternativos para inicializar y apoyar sysvinit con elogind.

Si los participantes del proyecto votan para diversificar los sistemas de inicialización, todos los encargados del mantenimiento participarán en un trabajo conjunto para resolver este problema o se designarán desarrolladores responsables especiales para que trabajen en este problema y aquellos que los acompañen ya no podrán ignorar el sistema de inicialización alternativo, permanecer en silencio o retrasar el proceso.

Actualmente, el repositorio ya ha acumulado 1033 paquetes que suministran unidades de servicio para systemd, pero no incluyen scripts init.d.

Para resolver este problema, se propone suministrar archivos de servicio de forma predeterminada, pero preparar un controlador que analice automáticamente los comandos de estos archivos y genere scripts init.d basados ​​en ellos.

Si la comunidad decide que Debian tiene suficiente soporte para un único sistema de inicialización, ya no se debe preocupar por sysvinit y elogind, centrándose solo en los archivos de la unidad y systemd.

Dicha solución afectará negativamente a los ports que no usan el kernel de Linux, pero todavía no hay tales puertos en el archivo principal y no tienen un estado de soporte oficial.

La vinculación a systemd también complicará significativamente el cambio en la dirección del desarrollo de la distribución en el futuro y limitará más experimentos en el campo de la inicialización y la gestión del servicio.

Cada solución tiene sus ventajas y desventajas, por lo que antes de la votación se requerirá una discusión exhaustiva de todos los argumentos a favor y en contra.

Fuente: https://lists.debian.org/