Debian vuelve a soportar múltiples sistemas de inicio

Sam Hartman, líder del proyecto Debian, intentado comprender los desacuerdos asociados con la entrega del paquete elogind como parte de la distribución. En julio, el equipo encargado de preparar los lanzamientos obstruido inclusión de elogind en la rama de pruebas, ya que este paquete entra en conflicto con libsystemd.

Recordemos que eloguinda proporciona las interfaces necesarias para ejecutar GNOME sin instalar systemd. El proyecto se fundó como una bifurcación de systemd-logind, se colocó en un paquete separado y se liberó de la vinculación a los componentes de systemd. Entre otras cosas, elogind proporciona su propia versión de la biblioteca libelogind, que asume una serie de funciones ofrecidas en libsystemd y reemplaza esta biblioteca durante la instalación.

Las razones del bloqueo fueron un conflicto con el paquete systemd y el peligro de reemplazar libsystemd con una alternativa libelogind, que es completamente incompatible con la biblioteca fuente a nivel ABI.
El paquete etiqueta elogind como conflictivo con las bibliotecas systemd, pero está inherentemente diseñado para funcionar solo sin systemd, y el conflicto con systemd es realmente beneficioso porque evita que elogind se instale por error. Por otro lado, en su forma actual, los intentos a través de APT de actualizar la configuración de systemd a la versión con sysvinit y elogind dan como resultado sistema dañado con APT no funciona. Pero incluso si se elimina esta deficiencia, la transición de systemd a elogind sigue siendo imposible sin eliminar los entornos de usuario ya instalados.

Los desarrolladores de elogind fueron propuesto por Adapte 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 se ve obstaculizada por la falta de soporte para el concepto de cortes, pero los desarrolladores de elogind no quieren lograr el cumplimiento total de la API y repetir exactamente todas las capacidades de systemd, ya que elogind solo proporciona un mínimo funcionalidad para organizar los inicios de sesión de los usuarios y no tiene como objetivo replicar todos los subsistemas de systemd.

La resolución de los problemas técnicos descritos debería 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 pudieron ponerse de acuerdo, el trabajo conjunto se convirtió en confrontación y la solución al problema. El problema llegó a un callejón sin salida, en el que cada lado tenía razón a su manera. Según Sam Hartman, la situación se acerca a un estado que requiere una votación general (GR, resolución general), en la que la comunidad decidirá sobre sistemas alternativos para init y soporte para sysvinit con elogind.

Si los miembros del proyecto votan para diversificar los sistemas de inicio, todos los mantenedores participarán en el trabajo conjunto para resolver este problema o se asignarán desarrolladores específicos para trabajar en este tema y los mantenedores ya no podrán ignorar un sistema de inicio alternativo, permanecer en silencio o retrasar el proceso.

Actualmente ya en el repositorio acumulado 1033 paquetes que proporcionan unidades de servicio para systemd, pero no incluyen scripts init.d. Para resolver este problema propuesto proporcionar archivos de servicio de forma predeterminada, pero preparar un controlador que analizaría automáticamente los comandos de estos archivos y generaría scripts init.d basados ​​en ellos.

Si la comunidad decide que Debian tiene suficiente soporte para un único sistema de inicio, ya no podremos preocuparnos por sysvinit y elogind y centrarnos sólo en los archivos unitarios y systemd. Esta decisión afectará negativamente a los puertos que no utilizan el kernel de Linux (Debian GNU / Hurd, Debian GNU / NetBSD и Debian GNU / kFreeBSD), pero todavía no existen dichos puertos en el archivo principal y no tienen el estado apoyado oficialmente.

La vinculación a systemd también hará que sea mucho más difícil cambiar la dirección de la distribución en el futuro y limitará la experimentación adicional en el campo de la inicialización y la gestión de servicios. Mantener elogind en funcionamiento es mucho más fácil que eliminarlo y luego intentar agregarlo nuevamente. Cada opción de decisión tiene pros y contras, por lo que será necesaria una discusión completa de todos los pros y los contras antes de votar.

Fuente: opennet.ru

Añadir un comentario