博士

やあ、ロボ子！今日のニュースはDebianとsystemdのちょっとした衝突についてじゃ。

ロボ子

博士、こんにちは。Debianとsystemdですか？興味深い組み合わせですね。どのような衝突があったのでしょうか？

博士

systemd v258で `/run/lock` ディレクトリのパーミッションが厳格化されたのが発端じゃ。Debianのポリシーとsystemdの設定がぶつかったみたいじゃな。

ロボ子

`/run/lock` ディレクトリは、複数のアプリケーションで共有されるリソースのロックファイルを格納するために使用されるのですよね。systemdの変更によって、具体的に何が問題になったのですか？

博士

そうじゃ、ロボ子。systemdの変更で、UUCPやcuといった古いソフトウェアが動かなくなってしまったんじゃ。Marco d'Itriさんがuucicoの破損を報告したのがきっかけじゃな。

ロボ子

UUCPですか。ずいぶんと懐かしい技術ですね。systemd側は、なぜそのような変更を行ったのでしょうか？

博士

Luca Boccassiさんは、`/run` 内のワールド書き込み可能なディレクトリはセキュリティリスクだと主張したみたいじゃ。でも、d'Itriさんは、systemdの意見はDebianポリシーには関係ないって反論したんじゃ。

ロボ子

Debianポリシーは、Filesystem Hierarchy Standard (FHS) に準拠することを求めているのですよね。FHSでは、`/run/lock` ディレクトリの扱いはどのように規定されているのでしょうか？

博士

そこがポイントじゃ！DebianポリシーはFHSを引用していて、`/run/lock` は共有リソースのロックファイル用と規定されている。だから、Debian Technical Committee (TC) が介入して、systemdにポリシー遵守を求めたんじゃ。

ロボ子

TCはsystemdメンテナをオーバーライドしたのですね。最終的に、どのような解決策になったのでしょうか？

博士

systemdパッケージが `/var/lock` を提供し、既存のDebianソフトウェアが動作するようにパーミッションを緩和する必要があると決定したんじゃ。古いソフトウェアのために、新しい技術が譲歩した形じゃな。

ロボ子

なるほど。しかし、記事には「DebianのUUCPスタイルのロックの使用は時代遅れに見える」ともありますね。Fedoraではlockdevを使用するパッチがあるとのことですが、Debianではどうなのでしょうか？

博士

d'Itriさんは、Boccassiさんが変更に反対しているから、自分では変更できないって言ってるみたいじゃ。なかなか難しい問題じゃな。

ロボ子

技術的な正しさと、既存のシステムとの互換性、そしてセキュリティ。さまざまな要素が絡み合っているのですね。

博士

まさにそうじゃ！今回の件は、Debianのパッケージ管理の自由度と、ポリシー遵守の重要性を示す良い例じゃな。それにしても、ロックファイルごときでこんな大騒ぎになるとは、ロックンロールじゃ！