[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Packages.txt: 1.267 -> 1.290



In message <E1EwNxD-0000ks-E2@moeko.iri.co.jp>
  Tsubai Masanari <tsubai@iri.co.jp> writes:
> ナナメ読みしただけですが、

いつもありがとうございます。

> あるパッケージを、一旦インストールしたら削除できないようにするためには、
> そのパッケージのMakefileでPKG_PRESERVE定義を設定します。
> 
> 一般論ですが、should を「〜するべき」と訳すのはどうも堅いような
> 気がするんですよねー。「〜しましょう」ぐらいでいいんでないかと。

つい「すべき」と書いてしまいますですね。すみません。
「〜するがいいにょ」的なものは書き直してみましたが、いかがでしょうか。

--- Packages.txt.orig	Wed Jan 11 02:40:45 2006
+++ Packages.txt	Wed Jan 11 21:52:31 2006
@@ -273,8 +273,8 @@
 
 	LOCALBASE=/usr/local
 
-と設定してください。なお、ルートにはパッケージ専用の場所を使うべきであり、
-他のプログラムと共有させてはいけません(つまり、 LOCALBASE=/usr などとしては
+と設定してください。なお、ルートにはパッケージ専用の場所を使い、
+他のプログラムと共有させないようにします(つまり、 LOCALBASE=/usr などとしては
 いけません)。また、LOCALBASEツリー内には、独自のファイルやディレクトリー(た
 とえば、src, obj, pkgsrcのようなもの)は一切追加しないようにしてください。こ
 れは、パッケージシステムがインストールするプログラムなどのファイルが、そこ
@@ -743,14 +743,14 @@
 patch-abより前に適用されます。
 
 問題を避けるため、patch-??ファイルは"diff -bu"フォーマットとし、かつ、曖昧
-さなしで適用可能であるべきです。(曖昧さがあっても強制的にパッチを適用させる
+さなしで適用できるようにします。(曖昧さがあっても強制的にパッチを適用させる
 ため、PATCH_FUZZ_FACTOR=-F2を設定することができます)。なお、将来の変更が難
 しくなってしまうので、一つのパッチファイルに、複数のファイルへの変更を入れ
 るのは止めてください。
 
 同様に、一つのファイルへのパッチあては最大一回とし、複数のパッチを使って複
 数回パッチをあててはいけません。もしファイルに複数のパッチが必要なら、それ
-は一つのファイルにまとめるべきです。
+は一つのファイルにまとめておきます。
 
 一つ重要なこととして、NetBSD CVSツリーにチェックインした後に問題を引き起こ
 すので、パッチファイルにRCS IDを含ませないように注意してください。これを避
@@ -1001,7 +1001,7 @@
 ムを判断できるように、CPPの定義を使います。
 
 4.4 BSDから派生したシステム上で作業しているかどうかをテストするためには、
-BSD定義を使用するべきです。これは<sys/param.h>で定義されています。
+BSD定義を使用します。これは<sys/param.h>で定義されています。
 
         #include <sys/param.h>
 
@@ -1124,7 +1124,7 @@
    2. -dlopenオプションが実行形式のリンク時に使われている。
 
  * ルーチンの初期化を適切に呼ばずにlibltdlを使う。関数lt_dlinit()を呼んで、
-   マクロLTDL_SET_PRELOADED_SYMBOLSを実行形式にインクルードすべきです。
+   マクロLTDL_SET_PRELOADED_SYMBOLSを実行形式にインクルードするようにしましょう。
 
 
  6.4 GNU Autoconf/Automake
@@ -1483,7 +1483,7 @@
    した後)場合には、このターゲットを使ってはいけません。もし使用すると、更
    新するつもりのパッケージのいくつかを失う可能性があります。経験的には、初
    めて「make update」を実行する前、あるいは汚れたパッケージツリーがある場
-   合(例えばNOCLEANを使用した場合)にのみ使用すべきです。
+   合(例えばNOCLEANを使用した場合)にのみ使用するとよいでしょう。
 
    パッケージのツリーが掃除されているかどうかわからない場合は、ツリーの最上
    層で"make clean"を実行するか、更新しようとしているパッケージのディレクト
@@ -1968,7 +1968,7 @@
 リーパッケージ内に記録されますが、BUILD_DEPENDS定義では記録されません。
 
 つまり、あるパッケージが必要となるのが構築時だけである場合、そのパッケージ
-はBUILD_DEPENDSとして書くべきです。
+はBUILD_DEPENDSとして書きます。
 
 BUILD_DEPENDSおよびDEPENDS定義の書式は以下の通りです:
 
@@ -2064,7 +2064,7 @@
 
 NetBSDパッケージシステムは、HOMEPAGE変数をサポートしています。もし、パッケー
 ジ化されたソフトウェアのホームページが存在するのであれば、そのページのURLを
-MakefileのHOMEPAGE変数に設定するべきです。この変数はMAINTAINER変数のすぐ後
+MakefileのHOMEPAGE変数に設定します。この変数はMAINTAINER変数のすぐ後
 に定義してください。
 
 
@@ -2134,8 +2134,8 @@
 きる5個のmake変数を定義しています:
 
  * RESTRICTED:
-   なにか制限がある場合は常に、(制限の種類にかかわらず)この変数を設定す
-   べきです。この変数を、その制限の理由を含む文字列に設定してください。
+   なにか制限がある場合は常に、(制限の種類にかかわらず)この変数を設定します。
+   この変数を、その制限の理由を含む文字列に設定してください。
  
  * NO_BIN_ON_CDROM:
    バイナリーをCD-ROMに収録してはいけません。バイナリーパッケージを
@@ -2158,7 +2158,7 @@
    ${RESTRICTED}に設定してください。
 
 NO_PACKAGE, IGNORE, NO_CDROMなど、制限を意味する上記以外の汎用make変数は使
-うべきでないことに注意してください。これらは、ユーザーのバイナリーパッケー
+わないようにしてください。これらは、ユーザーのバイナリーパッケー
 ジ作成を、無条件にできないようにするからです。
 
 
@@ -2291,7 +2291,7 @@
 ことに、それより前のバージョンとコマンド行のレベルで互換性がありません。ま
 た、TeXinfoマクロセットに拡張がいくつか導入されています。このため、パッケー
 ジ作者は、シェルのPATH変数の内容に依存したりせずに、適切なバイナリーが選ば
-れるようにすべきです。
+れるようにしてください。
 
 主たるinfoディレクトリーファイルは、infoファイルがインストールされたことを
 反映するために更新する必要があります。パッケージによっては、インストール過
@@ -2305,8 +2305,8 @@
 トールされるinfoファイルの名前にします。
 
 パッケージ作者は、パッケージの構築とインストールのプロセスが、適切なバージョ
-ンのmakeinfoおよびinstall-infoコマンドを使うようにするよう、注意を払うべき
-です。最近のソフトウェアパッケージに附属するMakefilesやconfigureスクリプト
+ンのmakeinfoおよびinstall-infoコマンドを使うようにするよう、注意を払ってください。
+最近のソフトウェアパッケージに附属するMakefilesやconfigureスクリプト
 のなかには、makeinfoおよびinstall-infoコマンドへのパス名を含めているものが
 あります。残念ながら、古いソフトウェアパッケージは、そのようにはしない傾向
 があります。問題となるのはこのケースで、パッケージ作者が手間をかける必要が
@@ -2321,7 +2321,7 @@
 
 パッケージが適切な挙動をしない(つまり、configureやbuildの際に環境変数
 MAKEINFOやINSTALL_INFOを参照しない) 場合は、以下のいずれか適切な方をおこな
-うべきです:
+うようにします:
  a) パッケージのファイルにパッチを当てて、configureやbuildの際に、makeinfo
     やinstall-infoがPATH中にあることを前提にするのではなく、環境変数
     MAKEINFOやINSTALL_INFOを使うようにする;
@@ -2367,9 +2367,9 @@
 大域変数PKG_SYSCONFBASE(とその他の変数)を、システム管理者が/etc/mk.confで設
 定すると、設定ファイルのインストール場所を定義することができます。このため、
 各パッケージはこの機能に対応する必要があります。この変数で定義される設定ファ
-イル用ディレクトリーには、本当に必要なファイルだけをインストールすべきであっ
-て、$PREFIX/shareに置いてもよいファイルはそちらにインストールすべきであるこ
-とに注意してください。
+イル用ディレクトリーには、本当に必要なファイルだけをインストールするようにし、
+$PREFIX/shareに置いてもよいファイルはそちらにインストールするよう
+注意してください。
 
 まず、利用可能な変数をお見せします(bsd.pkg.mkに、さらに詳しい情報があります)。
 PKG_SYSCONFDIRが、パッケージの設定ファイルが置かれる場所になります(これはフ
@@ -2385,7 +2385,7 @@
 
  3) PKG_SYSCONFVARは、個々のパッケージの設定を上書きする値を識別するための、
     特別な接尾辞です(次の項目参照)。デフォルトでは${PKGBASE}になりますが、
-    PKG_SYSCONFDIRを同じに揃えておくべき一連の関連パッケージに対しては、各
+    PKG_SYSCONFDIRを同じに揃えておくとよい一連の関連パッケージに対しては、各
     パッケージのMakefileで、PKG_SYSCONFVARを同じ値に設定することができます。
 
  4) PKG_SYSCONFDIR.${PKG_SYSCONFVAR}は、同じPKG_SYSCONFVARを持つパッケージ
@@ -2396,11 +2396,11 @@
     ${PKG_SYSCONFDIR.kde}を設定して、KDEの設定ファイルのインストール場所を
     定義できるようになります。
 
-プログラムの設定ディレクトリーは、configureの段階で定義すべきです。GNU
+プログラムの設定ディレクトリーは、configureの段階で定義します。GNU
 autoconfを使うパッケージでは、通常は--sysconfdirのパラメーターを使って定義
 することができますが、この方法は問題を起こすことがわかっています。このパス
 名をパッケージ側で変更する場合は、ファイルをディレクトリーに直接インストー
-ルするようにすべきではありません。そうするかわりに、ファイルを
+ルしないようにします。そうするかわりに、ファイルを
 share/examples/${PKGNAME}以下にインストールして、PLISTにそちらを登録できる
 ようにする必要があります。
 
@@ -2432,7 +2432,7 @@
  ========================================
 
 パッケージの目的がログインシェルの提供である場合は、PKG_SHELL変数を、
-このパッケージでインストールされるシェルの実行ファイルのフルパス名とすべきです。
+このパッケージでインストールされるシェルの実行ファイルのフルパス名とします。
 また、自動生成されるINSTALL/DEINSTALLスクリプトを使うために、
 パッケージのMakefileで、
 bsd.pkg.mkをインクルードする前に、USE_PKGINSTALLを"YES"に設定する必要もあります。
@@ -2451,7 +2451,7 @@
  ============================================
 
 パッケージに、そのパッケージ用のロケールのカタログが附属する場合は、
-変数USE_PKGLOCALEDIRを定義すべきです。
+変数USE_PKGLOCALEDIRを定義します。
 これにより、パッケージのMakefile雛型ファイルが必要に応じて修正され、
 適切なロケールディレクトリー(OSにより異なることがあります)を使うようになります。
 ${PKGLOCALEDIR}に関して詳しくは、5.1節も参照してください。
@@ -2477,7 +2477,7 @@
 
 環境によってはパッケージを構築しないよう指示するような理由がいくつかあります。
 パッケージが、ほとんどのプラットフォームで構築および実行できる場合は、
-NOT_FOR_PLATFORMとして例外を記述すべきです。
+NOT_FOR_PLATFORMとして例外を記述します。
 逆に、パッケージが一部のプラットフォームでしか構築および実行できない場合は、
 ONLY_FOR_PLATFORMを設定します。
 パッケージをとばすべき場合(たとえば、そのパッケージが提供する機能が、すでにシステムで提供されている場合)は、
@@ -2492,8 +2492,8 @@
  10.32 一旦インストールしたら削除すべきでないパッケージ
  ======================================================
 
-パッケージを一旦インストールしたら、削除できないようにするため、
-そのパッケージのMakefileでPKG_PRESERVE定義を設定すべきです。
+あるパッケージを、一旦インストールしたら削除できないようにするためには、
+そのパッケージのMakefileでPKG_PRESERVE定義を設定します。
 こうすると、そのpkgsrcから作られたバイナリーパッケージに、
 その旨が記録されます。
 "preserved"付きのパッケージは、
@@ -2502,7 +2502,7 @@
  10.33 perlスクリプトを含むパッケージ
  ====================================
 
-逐次実行されるperlスクリプトがパッケージに含まれる場合は、
+perlスクリプトがパッケージに含まれる場合は、
 インタープリターのパスが適切に設定されるようにするために、
 REPLACE_PERLを設定します。
 REPLACE_PERLの設定値は、調整の対象となるスクリプトをWRKSRCからの相対位置で列挙したものにします。
@@ -2585,10 +2585,10 @@
 になり、非常に便利です。
 
 また、あるパッケージに新しいバージョンがリリースされたというだけの理由で、
-CVSリポジトリー上のパッケージを更新するべきではないことを認識してください。
+CVSリポジトリー上のパッケージを更新しないほうがいいことを認識してください。
 私たちは、pkgsrcに含まれるパッケージに関して保守的であることを好みます。と
 いうのも、開発版やベータ版のパッケージは、pkgsrcが使われる場面のほとんどに
-対して、まったくふさわしくないからです。どのバージョンをpkgsrcに入れるべき
+対して、まったくふさわしくないからです。どのバージョンをpkgsrcに入れるのがよい
 か、分別をもって判断してください。新機能(テストされていない機能があるかもし
 れません)よりも安定性のほうが好ましいことを念頭に置いてください。
 
@@ -2945,8 +2945,8 @@
 必要なディスクスペース: 不明
 
 NetBSDのリリースバージョン向けのパッケージは、リリースバージョンの番号にあ
-わせたmajor.minorという形式の名前のディレクトリーにアップロードされるべきで
-す。"1.5.1"というバージョンのNetBSD向けのパッケージをアップロードするディレ
+わせたmajor.minorという形式の名前のディレクトリーにアップロードします。
+"1.5.1"というバージョンのNetBSD向けのパッケージをアップロードするディレ
 クトリーは、tinyバージョン番号を省いた"1.5"になります。LKMなど、OSバージョ
 ンに強く依存するパッケージについては、major.minor.tinyリリースディレクトリー
 を作って、そこに置くことができます。このようなパッケージには、バイナリーパッ