pkgsrc/doc/guide/files/options.xml 1.22 -> 1.24

[kano@na.rim.or.jp (OKANO Takayoshi)]

以下のページの更新をしました。ツッコミをお願いします。

pkgsrc/doc/guide/files/options.xml 1.22 -> 1.24
> revision 1.24
> date: 2007/09/22 02:52:48;  author: kano;  state: Exp;  lines: +2 -2
> fix typo
> ----------------------------
> revision 1.23
> date: 2007/09/21 13:28:29;  author: gdt;  state: Exp;  lines: +31 -1
> At Dieter's urging, rant about options vs split packages.  (I am not
> set up for tools, and am guessing that commiting to source and not
> regenerating is better than not writing text.)

火曜日までに異議がなければ commit します。

訳の全文は
  http://www.na.rim.or.jp/%7Ekano/tmp/docs/pkgsrc/options.xml
  http://www.na.rim.or.jp/%7Ekano/tmp/docs/pkgsrc/options.html
に置いてあります。

以下は、追加された部分の、原文と訳との差分です。

-<para>There are two broad classes of behaviors that one might want to
-control via options.  One is whether some particular feature is
-enabled in a program that will be built anyway, often by including or
-not including a dependency on some other package.  The other is
-whether or not an additional program will be built as part of the
-package.  Generally, it is better to make a split package for such
-additional programs instead of using options, because it enables
-binary packages to be built which can then be added separately.  For
-example, the foo package might have minimal dependencies (those
-packages without which foo doesn't make sense), and then the foo-gfoo
-package might include the GTK frontend program gfoo.  This is better
-than including a gtk option to foo that adds gfoo, because either that
-option is default, in which case binary users can't get foo without
-gfoo, or not default, in which case they can't get gfoo.  With split
-packages, they can install foo without having GTK, and later decide to
-install gfoo (pulling in GTK at that time).  This is an advantage to
-source users too, avoiding the need for rebuilds.</para>
+<para>パッケージの振舞を、オプションの枠組を使って制御したい状況は、
+大きく分けて二つあります。
+ひとつは、プログラム自体の構築は常におこなうものの、
+そのなかのある機能を有効にするかしないかです
+(他のパッケージに依存させるかさせないかによって制御することがよくあります)。
+もうひとつは、別のプログラムを、
+そのパッケージの一部として追加するかしないかです。
+後者は、一般的には、オプションの枠組を使わずに、
+パッケージを分割したほうがいいでしょう。
+パッケージを分割すれば、
+バイナリーパッケージを別々に追加できるようになるからです。
+たとえば、foo パッケージには最小限の
+(それがないと foo パッケージに何の意味もなくなるような) 依存性を持たせておいたうえで、
+別の foo-gfoo パッケージに GTK のフロントエンドプログラム gfoo を入れておくのです。
+この方法は、foo パッケージに gfoo を追加する gtk オプションを用意する方法より、
+すぐれています。なぜなら、オプションの枠組を使ってしまうと、
+このオプションが標準で有効な場合は、
+バイナリーパッケージの利用者は gfoo 抜き版の foo を使えず、
+また、標準で有効ではない場合は、
+バイナリーパッケージの利用者は gfoo を使えないからです。
+パッケージを分割すれば、バイナリーパッケージの利用者は、
+GTK 抜き版の goo をインストールすることも、
+後から gfoo をインストールする (GTK はそのときになってから取り寄せる) こともできます。
+また、ソースの利用者にとっても、
+foo パッケージの再構築の必要がなくなるという利点があります。</para>
 
-<para>Plugins with widely varying dependencies should usually be split
-instead of options.</para>
+<para>依存性が大きく変化するようなプラグインは、通常は、
+オプションではなく分割したほうがよいでしょう。</para>
 
-<para>It is often more work to maintain split packages, especially if
-the upstream package does not support this.  The decision of split
-vs. option should be made based on the likelihood that users will want
-or object to the various pieces, the size of the dependencies that are
-included, and the amount of work.</para>
+<para>パッケージを分割すると、保守の手間が増えることがよくあります。
+そのパッケージの本家が分割に対応していない場合は特にそうです。
+分割するかオプションにするかは、
+たくさんのパッケージの細切れや、依存パッケージの大きさや、作業量に対して、
+利用者がどう思うであろうか、という見地に立って判断するようにします。</para>
 
-<para>A further consideration is licensing.  Non-free parts, or parts
-that depend on non-free dependencies (especially plugins) should
-almost always be split if feasible.</para>
+<para>さらに考慮が必要なことは、ライセンスです。フリーではない部品や、
+フリーでないもの (特にプラグイン) に依存する部品は、
+分割可能な限り分割するのがよいでしょう。</para>