[debian-devel:01909] Debian Policy Manual (Review)

[hattas@xxxxxxxxxxxxxx]

八田です。

ポリシーマニュアルの 3 章の前半を読んでみました。30 過ぎると集中力が途
切れがちなので、3 章 全部カバーできませんでした。残りはまた今度。

# って、いつだろうなぁ。

本家の Policy Manual は新版が出てますね。前回頑張ってみた 2 章が換骨奪
胎の改変を受けてて、ちょっとショック。まあ、訳した鴨志田さんに比べるべ
くもありません。

もひとつ。前回、from time to time を「時とともに」ではとコメントしまし
たが、鴨志田さんの訳の通り「時々」「時折」という意味でした。辞書見てな
いのが丸わかりですね。すみません鴨志田さん。
前回、今回問わず、他にもこの手の間違いがあるかもしれません。見つけたら
容赦なく叩いてもらって結構です。エラそうにコメントしてますが、書いてる
ことにはちょっとしか自信ありません。

# やさしく指摘されるほうがありがたいですが:-)

前振はこのへんで、本編行きます。

----------------------------------------------------------------------
> 3.1 ファイルシステムのしくみ

ファイルシステムの階層でいいんじゃないかな。

> 3.1.1 Linux のファイル構造

タイトルは Linux Filesystem Structure だから FSSTND のことですよね。
「Linux ファイルシステム構造」としといたら。

> 3.1.2 サイト固有のプログラム

ここの前半はわかりづらいですよね。

・/usr/local の下にファイルをインストールしてはいけない。
・/usr/local の直下にディレクトリを作っても構わない。
  ただし、作成できるディレクトリは次のいずれか(FSSTND の要請)。
  (bin、doc、etc、games、lib、info、man、sbin、etc)
  これらのディレクトリは作成することはできても、削除してはいけない。
・/usr/local/bin(他)の下にはディレクトリをいくら作ってもよい。
  この場合、パッケージが削除される時にそのディレクトリが空だったら
  ディレクトリも削除すべき。

というのはわかるんですが。分かりやすく訳すの、しんどい。

> ローカルな追加のために /usr/local ディレクトリを作成する場合，パッケージはその

/usr/local にディレクトリを作成する場合
           ^^
> パッケージによって作成される /usr/local ディレクトリ自身と全てのサブディレクト
> リは 2775 のパーミッション（グループ書き込み可， set-gid ）で root.staff のオー

/usr/local ディレクトリ自身とパッケージが作成する全てのサブディレクト
リは...

でしょう。

> 3.2 ユーザとグループ
> あるユーザ ID (UID) とグループ ID (GID) はいくつかのパッケージが予約されていま
> す． パッケージによっては，決められたユーザ ID やグループ ID を持つファイルが

「予約しています」では。あるいは「いくつかのパッケージに」

> 必要であったり，コンパイルに ID が必要だったりするので，これらの ID は決められ
> た場所に用意されていなければいけません． これは重大な制限で，何とかして取り除

need the ids compiled into binaries は コンパイルに ID が必要なのでは
なく、バイナリに組込まれた ID が必要なのでは。だから固定の ID が必要。

> 100-999:
>          システムが動的に割り当てる範囲です． ユーザとグループを必要とするパッ

システムユーザとグループに動的に割り当てられる範囲です。

> 60000-64999:
>          全体的に Debian プロジェクトによって割り当てられ，必要があれば使われ
>      ます． ID は中枢的，静的に割り当てられますが，現在のアカウントは必要なと
>      きにユーザのシステムによって作られます．

(これは翻訳へのコメントではないです)
The ids are allocated centrally and statically,
これは具体的にどういう意味なんでしょう？ statically はいいとして 
centrally はよくわからないんです。教えてください、識者の方。

> 65535:
>          (uid_t)(-1) == (gid_t)(-1) です． 用心弁を返すエラーが出るので使用禁
>      止です．

centinel は「番兵」とか「番人」「標識」と訳すんじゃないかな。
探索テクニックの一種のことを指してると思う。
「エラーを意味する"番兵"の値です」くらい？ (標識値のほうがよいか？)

> 3.3.1 バイナリ
> とすべきでしょう． まとまらない場合は，両方のプログラムがファイル名を変更すべ
> きです．

変更しなければなりません。
              ^^^^^^^^^^
> g オプションはコンパイル時に便利でソースをデバッグすることが可能になり，誰もが
> コアダンプのバグレポートを送ることができるようになります．
> 
> -N オプションは使うべきではありません． a.out システムではとても小さなバイナリ
> に対して便利でしたが ELF では良い影響を与えません．
> 

細かいですけど、-g、-N か g、Nかどちらかに揃えてください。

> なければいけません． computationally-intensive プログラムのようなバイナリでは， 

computationally-intensive は調べがつきませんでした。

> 断を下してください． そうした方が良いという理由だけのためにオプションを指定し
> ないでください． 環境によっては不適切な場合もあるので，どのコンパイルオプショ
> ンが最上かという考え方はしないでください．

Don't use flags と only use them は対照です。その次も upstream author 
がないのでわかりにくくなっているようです。

試訳。
あるオプションを使いたいというだけで使わないでください。そのオプション
を使うべきちゃんとした理由があるときだけ使ってください。上流の著者が最
善と考えているコンパイルオプションは、遠慮なく書換えてかまいません。そ
のオプションが私達の環境にとって不適切であることはよくあります。

> 3.3.2 ライブラリ
> （オプション `--strip-unneeded' は strip をリロケーション処理のために必要では
> ないシンボルを削除するだけです）。 ダイナミックリンクのシンボルは別の ELF オブ
> ジェクトにあるので，共有ライブラリは strip されても完全に機能します。

(オプション `--strip-unneeded'をつけると、strip はリロケーション処理に
必要ではないシンボルだけを削除します)ダイナミックリンクのためのシンボ
ルは ELF オブジェクトの異なる部分にあるので...ではないか。

> 3.3.3 共有ライブラリ

> イルを構築したものと実行するものとが一致していなければなりません（通常は， 
> soname はライブラリの一般的な名前です。）。 もう一つは librarynamesoname-dev 

major number of library は「ライブラリの一般的な名前」ではないのでは？

> 同時に一つの開発バージョンをサポートをするならば，開発パッケージを 
> libraryname-dev としても構いません。 それ以外は， dpkg の競合する機能を利用し
> て，ユーザだけがインストールする開発バージョンを用意すべきで，つまり，異なる開
> 発バージョンが同じヘッダファイルを持つならば両方をインストールするとファイル名
> で衝突してしまいます。 大抵，開発バージョンはランタイムライブラリに依存するバー
> ジョンも必要としていて，コンパイルとリンカは問題なくできるか確認しなければなり
> ません。

？？？
dpkg's conflicts mechanism が「dpkg の競合する機能」となってるのは間違
いじゃないような気もするので、惜くとして。意味とり違えてるところが多い
みたいですよ。

「ユーザだけがインストールする開発バージョンを用意すべき」なのではなく
「ユーザが一時にひとつの開発バージョンだけをインストールするのを確実に
するために」dpkg の競合する機能を利用するのを望んでもいい、です。
括弧内は「異なる開発バージョンには同じヘッダファイルが含まれがちだから」
と、どちらかというと理由を説明してます。
次は need an exact version dependency on のところ。version dependency 
は分離できないんではないかな。
「典型的には、開発バージョンはランタイムライブラリのバージョンに厳
密に依存する必要もあるでしょう。確実にコンパイルとリンクが正しく行なわ
れるようにするためです」

> ジに依存するようにすべきです。 soname が変更されたら，新しいものに変更するとき
> に両方のバージョンのライブラリがインストールされているべきです。

「べき」ではないです。
soname を変更するとき、古いライブラリから新しいものに移行する間、2 つ
のバージョンのライブラリをインストールしておくことができる、という可能
性の説明でしょう。

> 同じソースツリーから複数の共有ライブラリをを構築する場合，それらをまとめて一つ
> の共有ライブラリパッケージにすることができ，異なるバージョンが複数のパッケージ
> になっていて，それらを入れたときにファイル名の衝突が起きないように，すべての 
> soname の名前を供給するようにしておきます。

provided that は「〜の条件のときに」とか「〜であるならば」という意味の
接続詞ですよ。

> 3.3.4 スクリプト
> パッケージに含まれる管理スクリプトに含まれ dpkg に利用されるスクリプトは， #! 
パッケージ内の管理者スクリプトや dpkg が利用するスクリプトは全て、スク
リプトを実行するシェルの名前を #! の行に書きましょう。か？(自信なし)

> exit status) ををチェックしてください。
               ^^^^
> 3.3.5 シンボリックリンク
> ンク先にとって重要ではありません。 しかし，リンクを作るディレクトリに移動する
> 必要があります。 単にリンク先（リンク先のあるディレクトリへの相対ディレクトリ

not ... nor... の構造だと思います。
「同様に、リンクを作るディレクトリに移動する必要もありません。」

> 3.3.6 デバイスファイル
> ならば， postinst 中で makedev を呼び出すようにして，ユーザにそれを許可するか
> どうか聞くようにしなければなりません。

ユーザの許可を取ったあとに makedev を呼出すんですよね。

> postrm の中でデバイスファイルや他のスクリプトを削除すべきではありません。 これ
> はシステム管理者に残します。

postrm や他のスクリプトでデバイスファイルを削除しないようにしましょう。
デバイスファイルの削除は、システム管理者に任せてください。

> 3.3.7 設定ファイル
> ファイルシステムにある /etc 内のすべてのファイルは dpkg の conffiles コントロー
> ルファイルに書かれていなければなりません。 dpkg のプログラミングマニュアルを参

almost は...なくてもいいか。

> 3.3.8 パーミッションとオーナ
> 下で述べる詳細から外れてもかまいません． しかしながら，そうするからには何をし
> たら安全かを理解しているべきで，できるだけ残りのシステムは一致するようにすべき

「したことが安全であることを確かめなければなりません」

------------------------------------------------------------------------
ここで、息切れ。

// 日本インターシステムズ(株) 共通システム部 八田修三
// e-mail : hattas@xxxxxxxxxxxxxx / hattas@xxxxxxxxxx
// PGP fingerprint = A6 2A 8A C7 5C C3 86 EF  29 0C 50 1C 0B C5 61 E4