Debian se retrouve sans mainteneur de systemd en raison de désaccords

Michael Biebl, qui est impliqué dans le développement Debian depuis 2004 et qui est l'un des principaux contributeurs à la distribution de dans la zone du gestionnaire système "systemd", a laissé le paquet à Debian.

C'était parce qu'en tant que mainteneur à partir du package systemd, a décrit la situation avec la correction des erreurs système comme "stupide et insensée", et promettant de ne plus envoyer de rapports de bogue aux développeurs système.

Qu'est-ce qui a causé cela?

Le conflit est survenu en raison de l'apparition d'un changement régressif dans la version de systemd 240, Que lo provoqué des changements de comportement lors du traitement des règles udev existantes et problèmes pour les utilisateurs Debian lors du changement de la logique de changement de nom des interfaces réseau.

Malgré l'utilisation de l'option "NAME" pour lier le nom de l'interface réseau à l'adresse MAC après la transition vers udev à partir de systemd 240.

Les interfaces réseau des adaptateurs Ethernet ont changé leur nom de fixe à auto-généré (auparavant, le remplacement n'était effectué qu'une seule fois et depuis la version 240, il peut être utilisé). Il y a plusieurs remplacements).

Michael Bibl a demandé aux développeurs de systemd de revenir au comportement précédent lorsque la liaison manuelle de nom spécifiée dans config est d'une priorité plus élevée.

C'est une régression par rapport à la v239, et je suis enclin à l'ajouter à l'étape v241 car cela peut signifier la perte d'accès au réseau. Contestation Michael Bibl

Mais les développeurs de systemd n'ont pas considéré ce changement régressif comme un problème car les modifications apportées à systemd 240 ne violaient pas le comportement documenté, des fonctionnalités udev non documentées ont été utilisées, dont les performances n'étaient pas garanties.

Cependant, des preuves ultérieures ont été trouvées que le comportement ci-dessus est décrit dans la documentation.

C'était comment Yu Watanabe, a répondu, disant essentiellement que ce n'était pas quelque chose qui affectait:

Pourquoi lan0 est-il appelé lorsque le pilote est chargé? Oui, le résultat final est, ens3, alors j'espère que c'est toujours ens3.

À quoi Michel Bible il a répondu:

Il doit toujours être nommé lan0 à cause de la règle udev.

Le problème s'aggravait

Après cela, Les développeurs de systemd ont suggéré que le nouveau comportement soit désactivé de manière sélective.

Si des règles udev sont créées pour les anciennes versions de systemd (si le schéma de dénomination est défini pour les versions inférieures à 240, définissez l'option RenameOnce = yes par défaut, sinon RenameOnce = no).

Sur la liste de diffusion des développeurs de systemd, il y avait aussi une discussion sur la proposition à émettre, sans plus tarder, des versions correctives de systemd avec des correctifs pour les bogues sérieux apparaissant dans les versions majeures.

Lennart Pottering a rejeté l'idée, invoquant un manque de ressources. TL'opinion a été perçue par certains développeurs comme une idée fausse fondamentale, car la priorité accordée au développement de fonctionnalités au détriment de la stabilité a un effet négatif sur les utilisateurs.

En réponse, Lennart Il a évoqué le fait que les utilisateurs finaux n'utilisent pas les dernières versions de systemd, mais utilisent des packages stabilisés par la distributionPar exemple, ils sont vérifiés par rapport à Fedora et au service QA avant de placer les composants du système sur RHEL.

Avant ça Michel Bible, argument Cela affecte les utilisateurs, car cela peut créer des conflits avec les configurations déjà prédéfinies par l'utilisateur dans le système:

Ce n'est pas mieux pour les utilisateurs car cela rompt les paramètres utilisateur existants. Qu'est que c'est mauvais

Dans le cas de changements de priorités dans le développement et de corrections de bogues selon Lennart, seule une génération de critères différents émergera, dans laquelle les bogues associés à des architectures exotiques, des environnements graphiques atypiques, des bibliothèques et des pilotes seront souvent ignorés. et relégué à la communauté.

Si vous voulez en savoir un peu plus sur le problème, vous pouvez suivre dans le lien suivant.