Sam Hartman, líder del proyecto Debian, resolver las discrepancias relacionadas con la inclusión del paquete elogind en la distribución. En julio, el equipo encargado de preparar las versiones la inclusión de elogind en la rama de testing, ya que este paquete entra en conflicto con libsystemd.
Recordemos que proporciona las interfaces necesarias para operar GNOME sin instalar systemd. El proyecto se basa en un fork de systemd-logind, convertido en un paquete independiente y desvinculado de los componentes de systemd. Además, elogind ofrece su propia versión de la biblioteca libelogind, que asume varias funciones ofrecidas en libsystemd, reemplazando esta biblioteca durante la instalación.
Como razones para la prohibición se mencionó el conflicto con el paquete systemd y el peligro de reemplazar libsystemd con una alternativa como libelogind, que es completamente incompatible con la biblioteca original a nivel de ABI.
El paquete elogind está marcado como conflictivo con las bibliotecas de systemd, pero en esencia está diseñado para funcionar solo sin systemd, y el conflicto con systemd incluso es beneficioso, ya que evita la instalación errónea de elogind. Por otro lado, en su forma actual, intentar actualizar la configuración de systemd a una alternativa con sysvinit y elogind a través de APT lleva a una con APT que no funciona. Pero incluso al solucionar este problema, la transición de systemd a elogind sigue siendo imposible sin eliminar los entornos de usuario ya instalados.
A los desarrolladores de elogind se les pidió adaptar elogind para que funcione sobre el libpam-systemd estándar, sin utilizar su propia capa libpam-elogind. La transición de elogind a libpam-systemd es obstaculizada por la falta de soporte para el concepto de slices, pero los desarrolladores de elogind no desean lograr una compatibilidad total con la API ni replicar todas las funcionalidades de systemd, ya que elogind solo proporciona la funcionalidad mínima para la gestión de inicios de sesión de usuarios y no tiene como objetivo replicar todos los subsistemas de systemd.
La resolución de los problemas técnicos descritos debe abordarse a 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 ya que los equipos no pudieron llegar a un acuerdo; el trabajo conjunto se transformó en un enfrentamiento y la solución del problema se estancó, donde cada parte tiene su propia razón. Según Sam Hartman, la situación se aproxima a un estado que requiere una votación general (GR, resolución general), en la que la comunidad tomará una decisión con respecto a los sistemas alternativos de inicialización y el soporte de sysvinit con elogind.
Si los participantes del proyecto votan a favor de la diversificación de los sistemas de inicialización, todos los mantenedores se involucrarán en el trabajo conjunto para abordar esta tarea, o se nombrarán desarrolladores responsables especiales para trabajar en este problema, y los acompañantes ya no podrán ignorar el sistema alternativo de inicialización, permanecer en silencio o retrasar el proceso.
Actualmente en el repositorio ya hay 1033 paquetes que proporcionan unidades de servicio para systemd, pero no incluyen scripts init.d. Para resolver este problema se deberían proporcionar archivos de servicio por defecto, pero preparar un manejador que interprete automáticamente los comandos de estos archivos y genere scripts init.d a partir de ellos.
Si la comunidad decide que en Debian es suficiente con el soporte de un único sistema de inicialización, ya no será necesario preocuparse por sysvinit y elogind, centrándose solo en los archivos de unidad y systemd. Tal decisión afectará negativamente a los puertos que no utilizan el núcleo de Linux (, y ), pero en el archivo principal de tales puertos aún no hay y no tienen estatus de .
La vinculación con systemd también dificultará significativamente un cambio de dirección en el desarrollo de la distribución en el futuro y limitará la realización de experimentos adicionales en el área de inicialización y gestión de servicios. Mantener elogind operativo es mucho más fácil que eliminarlo y luego intentar agregarlo nuevamente. Cada opción de solución tiene pros y contras, por lo que se requerirá una discusión exhaustiva de todos los argumentos a favor y en contra antes de la votación.
Fuente: opennet.ru
