Hace ya algunos meses aquí en el blog compartimos la noticia sobre una discusión que se llevaron los desarrolladores de Debian si soportar múltiples sistemas de inicialización seria una opción. Dado que esto se derivó de un desacuerdo con respecto a la entrega del paquete elogind (si quieres leer la nota lo puedes hacer en este enlace).

Y pues bien ahora, se anunció el inicio de una votación general para los desarrolladores del proyecto para decidir sobre si el sistema soportara múltiples sistemas de inicialización, lo que determinará la política adicional del proyecto con respecto a la vinculación a systemd, soporte para sistemas de inicialización alternativos e interacción con distribuciones derivadas que no usan systemd.

Hace unos meses, después de problemas con la inclusión del paquete elogind (necesario para que GNOME funcione sin systemd) en la rama de prueba debido a un conflicto con libsystemd, el líder del proyecto Debian volvió a plantear la pregunta, ya que los desarrolladores no podían estar de acuerdo y su comunicación se convirtió en una confrontación y estancado

La votación actual permitirá aprobar una política en varios sistemas de inicialización y si el elemento que obliga a soportar sistemas alternativos gana, los mantenedores no podrán ignorar o retrasar tales problemas.

Después de discutir los tres puntos de votación propuestos originalmente por el líder del proyecto, el número de opciones se amplió a ocho.

Al votar, se permite seleccionar varios elementos a la vez con la clasificación de los elementos seleccionados por nivel de preferencia. Alrededor de mil desarrolladores que participan en mantenimiento de paquetes y soporte de infraestructura tienen derecho a votar.

Dentro de las opciones sugeridas, se establece:

• El foco principal está en systemd. Brindar soporte para sistemas de inicialización alternativos no es una prioridad, pero se pueden incluir opcionalmente scripts de inicio para dichos sistemas en paquetes.
• Soporte para una variedad de sistemas de inicialización y la capacidad de arrancar Debian con sistemas no sean systemd.
  Para iniciar los servicios, los paquetes deben incluir scripts de inicio.
• Systemd sigue siendo preferible, pero la capacidad de mantener sistemas alternativos de inicialización permanece. Las tecnologías, como elogind, que le permiten ejecutar aplicaciones enlazadas al sistema en entornos alternativos, se consideran importantes. Los paquetes pueden incluir archivos init para sistemas alternativos.
• Soporte para sistemas que no usan systemd, pero sin realizar cambios que impidan el desarrollo. Los desarrolladores aceptan soportar múltiples sistemas de inicialización en el futuro previsible, pero también consideran necesario trabajar para mejorar el soporte de systemd. El desarrollo y mantenimiento de soluciones específicas debe ser llevado a cabo por las comunidades interesadas en tales soluciones, pero otros mantenedores deben ayudar activamente y contribuir a resolver problemas cuando surja la necesidad.
• Soporte para la portabilidad, sin realizar cambios que interfieran con el desarrollo. La portabilidad entre plataformas de hardware y pilas de software es una tarea importante y la integración de tecnologías alternativas es bienvenida, incluso si la visión del mundo de sus creadores difiere de una opinión común.
• Transfiera el soporte para sistemas de inicialización múltiple a la categoría de obligatorio. Proporcionar la capacidad de ejecutar Debian con sistemas de inicialización distintos de systemd continúa marcando la diferencia en el proyecto. Cada paquete debe funcionar con manejadores pid1 que no sean systemd, a menos que el software incluido en el paquete esté diseñado para funcionar solo con systemd y no haya soporte para comenzar sin systemd (la ausencia de scripts de inicio no se considera solo para trabajar con systemd).
• Soporte para portabilidad y múltiples implementaciones. Los principios generales son totalmente consistentes con el párrafo 5, pero con respecto a los sistemas systemd y de inicialización, no se hacen requisitos específicos ni se imponen obligaciones a los desarrolladores. Se alienta a los desarrolladores a tener en cuenta los intereses de los demás, hacer compromisos y encontrar soluciones comunes que sean satisfactorias para varias partes.

La votación durará hasta el 27 de diciembre inclusive, los resultados se anunciarán el 28 de diciembre. Si quieres conocer más al respecto, puedes consultar la publicación original en el siguiente enlace.