意見の不一致により、Debianはsystemdメンテナを使い果たします

2004年からDebian開発に携わってきたMichaelBiebl そしてそれは 主な貢献者のXNUMX人 の配布に システムマネージャ領域「systemd」で、パッケージをDebianに任せました。

これはメンテナとして systemdパッケージから、 システムエラーの修正を伴う状況を「愚かで正気でない」と説明しました。 システム開発者にバグレポートを再度送信しないことを約束します。

何が原因ですか？

紛争 systemd240のバージョンに回帰的な変更が加えられたために発生しました。 LO Queの 既存のudevルールを処理するときに動作が変更されました およびDebianユーザーの問題 ネットワークインターフェイスの名前変更ロジックを変更する場合。

systemd 240からudevに移行した後、「NAME」オプションを使用してネットワークインターフェイス名をMACアドレスにバインドしたにもかかわらず。

イーサネットアダプタのネットワークインターフェイスは、名前を固定から自動生成に変更しました（以前は、置換は240回だけ行われ、バージョンXNUMX以降は使用できます）いくつかの置換があります）。

Michael Biblは、configで指定された手動の名前バインディングの優先度が高い場合、systemd開発者に以前の動作に戻すように依頼しました。

これはv239と比較した場合の回帰であり、ネットワークアクセスが失われる可能性があるため、v241マイルストーンに追加する傾向があります。 議論MichaelBibl

しかし systemd 240で行われた変更は文書化された動作に違反しなかったため、systemd開発者はこの回帰的な変更を問題とは見なしませんでした。、文書化されていないudev機能が使用されましたが、そのパフォーマンスは保証されていません。

ただし、後で、上記の動作がドキュメントに記載されているという証拠が見つかりました。

こうやって 渡辺悠、答えた、基本的には影響を受けたものではないと言っています：

ドライバがロードされたときにlan0が呼び出されるのはなぜですか？ はい、最終結果はens3です。それなら、常にens3であることを願っています。

何に マイケル・ビブル 彼は返事をした：

udevルールのため、常にlan0という名前にする必要があります。

問題はエスカレートしていました

その後、 systemd開発者は、新しい動作を選択的に無効にすることを提案しました。

古いバージョンのsystemdに対してudevルールが作成されている場合（名前付けスキームが240未満のバージョンに対して定義されている場合は、デフォルトでオプションRenameOnce = yesを設定し、そうでない場合はRenameOnce = noを設定します）。

systemd開発者のメーリングリストでは、発行する提案についての議論もありました。 さらに苦労することなく、メジャーバージョンに表示される重大なバグの修正を含むsystemdの修正。

Lennart Potteringは、リソースの不足を理由にこのアイデアを拒否しました。 T一部の開発者は、安定性を損なう機能の開発に重点を置くことはユーザーに悪影響を与えるため、この意見は根本的な誤解として認識されていました。

それに応じて、レナート 彼は、エンドユーザーが最新バージョンのsystemdを使用せず、ディストリビューションによって安定化されたパッケージを使用するという事実に言及しました。たとえば、システムコンポーネントをRHELに配置する前に、FedoraおよびQAサービスに対してチェックされます。

この前に Michael Bibl、 引数 これは、システムでユーザーがすでに設定した設定と競合する可能性があるため、ユーザーに影響します。

既存のユーザー設定が壊れるため、ユーザーにとっては良くありません。 それは何ですか 悪い

レナートの見解で開発の優先順位を変更し、バグ修正を行った場合、異なる基準の世代のみが出現し、エキゾチックなアーキテクチャ、非定型のグラフィック環境、ライブラリ、およびドライバーに関連するバグは無視されることがよくあります。そしてコミュニティに追いやられました。

問題についてもう少し知りたい場合は、フォローアップできます 次のリンクで.