Michael Biebl, quien ha estado involucrado en el desarrollo de Debian desde 2004 y el cual es uno de los principales contribuyentes a la distribución de en el área del administrador del sistema “systemd”, dejó el paquete a Debian.

Esto fue debido a que como mantenedor del paquete systemd, ha calificado la situación con la corrección de los errores del sistema como “estúpido e insano”, y prometiendo no enviar informes de errores a los desarrolladores de sistemas nuevamente.

¿Qué fue lo que ocasiono esto?

El conflicto surgió debido a la aparición de un cambio regresivo en la versión de systemd 240, lo que provocó cambios en el comportamiento al procesar las reglas udev existentes y los problemas para los usuarios de Debian al cambiar la lógica de cambio de nombre de las interfaces de red.

A pesar de usar la opción “NAME” para vincular el nombre de la interfaz de red a la dirección MAC después de la transición en udev de systemd 240.

Las interfaces de red de los adaptadores de Ethernet cambiaron sus nombres de fijo a generado automáticamente (anteriormente, el reemplazo se hizo solo una vez, y desde la versión 240 se puede usar) Hay varios reemplazos).

Michael Bibl pidió a los desarrolladores de systemd que volvieran al comportamiento anterior cuando la vinculación manual de nombres especificada en la configuración es de mayor prioridad.

Eso es una regresión en comparación con v239, y me inclino a agregarlo al hito de v241, ya que puede significar la pérdida de acceso a la red. Argumento Michael Bibl

Pero los desarrolladores de systemd no consideraron que este cambio regresivo fuera un problema, ya que los cambios realizados en systemd 240 no violaron el comportamiento documentado, se usaron características de udev no documentadas, cuyo rendimiento no estaba garantizado.

Sin embargo, más tarde se encontró evidencia de que el comportamiento anterior se describe en la documentación.

Así fue como Yu Watanabe, respondió, diciendo básicamente que no era algo que afectara:

¿Por qué se llama lan0cuando se carga el controlador? Si, el resultado final es, ens3entonces, espero que sea siempre ens3.

A lo que Michael Bibl le respondio:

Siempre se debe nombrar lan0 debido a la regla udev.

El problema fue escalando

Después de eso, los desarrolladores de systemd sugirieron que se deshabilitara de forma selectiva el nuevo comportamiento.

En caso de que las reglas de udev se creen para versiones anteriores de systemd (si el esquema de nomenclatura está definido para versiones menores de 240, configure la opción RenameOnce = yes de manera predeterminada, de lo contrario RenameOnce = no).

En la lista de correo de desarrolladores de systemd, también hubo una discusión sobre la propuesta de emitir, sin más dilación, versiones correctivas de systemd con la corrección de errores graves que aparecen en versiones importantes.

Lennart Pottering rechazó la idea, citando una falta de recursos. Tal opinión fue percibida por algunos desarrolladores como un concepto erróneo fundamental, ya que el enfoque prioritario en el desarrollo de la funcionalidad en detrimento de la estabilidad tiene un efecto negativo en los usuarios.

En respuesta, Lennart se refirió al hecho de que los usuarios finales no usan las últimas versiones de systemd, pero usan paquetes estabilizados por distribuciones, por ejemplo, se verifican en Fedora y el servicio de control de calidad antes de colocar los componentes del sistema en RHEL.

Ante esto Michael Bibl, argumento que si afecta a los usuarios, pues esto puede crear conflictos con las configuraciones ya prestablecidas por el usuario en el sistema:

No es mejor para los usuarios, ya que rompe las configuraciones de usuario existentes. Que es malo

En el caso de las prioridades cambiantes en el desarrollo y la corrección de errores en la opinión de Lennart, solo surgirá una generación de diferentes criterios, en la que los errores asociados con arquitecturas exóticas, entornos gráficos atípicos, bibliotecas y conductores a menudo serán ignorados y relegados a la comunidad.

Si quieres conocer un poco más acerca del problema puedes darle el seguimiento en el siguiente enlace.

El artículo Debian se queda sin un mantenedor de systemd debido a desacuerdos aparece primero en Debian se queda sin un mantenedor de systemd debido a desacuerdos.