Debian init システムに関する投票の結果がまとめられました

発行済み 結果 一般投票 (GR、一般決議) パッケージのメンテナンスとインフラストラクチャのメンテナンスに携わる Debian プロジェクト開発者は、複数の init システムのサポートの問題に関して実行されました。 リストの XNUMX 番目の項目 (「B」) が優先されます。systemd が引き続き優先されますが、代替の初期化システムを維持する可能性も残っています。 投票は以下の方法で行われました コンドルセでは、各投票者がすべての選択肢を好みの順にランク付けし、結果を計算する際に、何人の投票者が XNUMX つの選択肢を他の選択肢よりも好むかが考慮されます。

受賞した提案では、systemd サービス ユニットがデーモンとサービスを実行するように設定するための好ましい方法であることを認めていますが、開発者とユーザーが代替の init システムや systemd の機能に代わる機能を作成して使用できる環境があることも認めています。 代替ソリューションの開発者は、作業を実行してパッケージをフォーマットするためのリソースを必要とします。 systemd 固有のインターフェイスにバインドされたアプリケーションを実行するための elogind のような代替ソリューションは、引き続きプロジェクトにとって重要です。 このような取り組みをサポートするには、パッチのレビューや議論を遅らせるなど、代替テクノロジーの開発がプロジェクトの残りの部分と交差する分野での支援が必要です。

パッケージには、systemd ユニット ファイルとサービスを開始するための init スクリプトの両方を含めることができます。 パッケージは、その機能が Debian ルールに準拠し、他のパッケージの実験的またはサポートされていない Debian 機能に関連付けられていない限り、パッケージ管理者が希望する任意の systemd 機能を使用できます。 systemd に加えて、パッケージには代替 init システムのサポートが含まれ、systemd 固有のインターフェイスを置き換えるコンポーネントが提供される場合もあります。 パッチの組み込みに関する決定は、標準手順の一部としてメンテナによって行われます。 Debian は、他の init システムの使用を選択する派生ディストリビューションと連携することに取り組んでいますが、その相互作用はメンテナ レベルで構築され、サードパーティ ディストリビューションによって準備されたどの機能がメインの Debian 構成に受け入れられ、どの機能が残されるかが決定されます。微分分布で。

2014 年に技術委員会が開催されたことを思い出してください。 承認済み 移行 systemd 上のデフォルトのディストリビューションですが、そうではありません うまくいきました 複数のプロビジョニング システムのサポートに関する決定 (この問題に関して委員会が決定を下す意思がないことを示す項目が投票に勝ちました)。 委員会のリーダーは、パッケージ管理者が代替の init システムとして sysvinit のサポートを維持することを推奨しましたが、自分の見解を押し付けることはできず、それぞれの場合に独立して決定を下すべきであると述べました。

この後、一部の開発者は試みました 実行しようとする 一般投票は行われましたが、予備投票では、複数の初期化システムの使用の問題について決定を下す必要がないことが示されました。 数か月前、その後 проблем libsystemd との競合により、テスト ブランチに elogind パッケージ (systemd なしで GNOME を実行するために必要) が組み込まれたため、開発者が同意できず、開発者間のコミュニケーションが議論になったため、この問題が Debian プロジェクト リーダーによって再び提起されました。対立し行き詰まりました。

考慮されるオプション:

主な焦点は systemd です。 代替の init システムのサポートを提供することは優先事項ではありませんが、メンテナはオプションでそのようなシステムの init スクリプトをパッケージに含めることができます。

systemd が引き続き優先されますが、代替の初期化システムを維持する可能性も残されています。 systemd にバインドされたアプリケーションを代替環境で実行できるようにする elogind などのテクノロジーが重要とみなされています。 パッケージには、代替システム用の init ファイルが含まれる場合があります。

さまざまな init システムのサポートと、systemd 以外の init システムで Debian を起動する機能。
サービスを実行するには、パッケージに init スクリプトが含まれている必要があります。sysv init スクリプトなしで systemd ユニット ファイルのみを提供することは受け入れられません。

systemd を使用しないシステムのサポートですが、開発を妨げるような変更は加えません。 開発者は、当面は複数の init システムをサポートすることに同意していますが、systemd サポートの改善に取り組む必要があるとも考えています。 特定のソリューションの開発と保守は、それらのソリューションに関心のあるコミュニティに任せるべきですが、必要が生じた場合には、他の保守者が積極的に支援し、問題解決に貢献する必要があります。 理想的には、パッケージは任意の init システムを使用して機能する必要があります。これは、従来の init スクリプトを提供するか、systemd なしで動作できるようにする他のメカニズムを使用することで実現できます。 systemd なしで動作できないことはバグとみなされますが、systemd なしで動作するための既製のソリューションがあり、保存が拒否されない限り、リリースを妨げるバグではありません (たとえば、問題が原因で発生した場合)以前に提供された init スクリプトの削除)。

開発を妨げる変更を導入することなく移植性をサポートします。 Debian は、同等または類似の機能を提供するさまざまなソフトウェアを統合するための架け橋として見なされ続けています。 ハードウェア プラットフォームとソフトウェア スタック間の移植性は重要な目標であり、作成者の世界観が一般的なコンセンサスと異なる場合でも、代替テクノロジの統合が奨励されます。 systemd およびその他の初期化システムに関する立場は、ポイント 4 と完全に一致します。

複数の初期化システムのサポートを必須にします。 systemd 以外の init システムで Debian を実行できる機能を提供することは、プロジェクトにとって引き続き重要です。 各パッケージは、パッケージに含まれるソフトウェアが元々 systemd でのみ動作することを意図しており、systemd なしでの実行をサポートしていない限り、systemd 以外の pid1 ハンドラーで動作する必要があります (init スクリプトがないことは、systemd での動作のみを目的としたものとしてカウントされません)。 。

移植性と複数の実装をサポートします。 一般原則はポイント 5 とまったく同じですが、systemd および init システムに対する特定の要件はなく、開発者に義務は課されません。 開発者は、互いの利益を考慮し、妥協し、さまざまな関係者が満足できる共通のソリューションを見つけることが推奨されます。

議論を続けます。 このアイテムは、受け入れられないオプションをダウングレードするために使用できます。

出所： オープンネット.ru