The pkgsrc guide NetBSD パッケージシステムに関するドキュメンテーション Alistair Crooks Hubert Feyrer The pkgsrc Developers Copyright ? 1994-2007 The NetBSD Foundation, Inc $NetBSD: pkgsrc.xml,v 1.26 2007/09/18 08:17:21 rillig Exp $ Abstract pkgsrc は、Unix 風のオペレーティングシステム向けの、集中管理型パッケージ管理シ ステムです。この手引きでは、 pkgsrc の利用者向けと開発者向けの情報を掲載してい ます。バイナリーおよびソースパッケージのインストール、バイナリーおよびソースパ ッケージの作成から、基盤についての高度な概観までを網羅しています。 ------------------------------------------------------------------------------- Table of Contents 1. pkgsrc とは何か 1.1. イントロダクション 1.1.1. なぜ pkgsrc なのか? 1.1.2. 対応プラットフォーム 1.2. 概要 1.3. 専門用語 1.3.1. pkgsrc に関わる人たち 1.4. 体裁 I. pkgsrc 利用者向けの手引き 2. どこからpkgsrcを得て、どうやって最新に保つか 2.1. pkgsrc を初めて入手する 2.1.1. tar ファイル 2.1.2. anonymous CVS 経由 2.2. pkgsrc を最新の状態に保つ 2.2.1. tar ファイルを使用 2.2.2. CVS 経由 3. NetBSD 以外のシステムで pkgsrc を使う 3.1. バイナリー配布 3.2. pkgsrc を使う準備をする 3.3. プラットフォーム別の覚書 3.3.1. Darwin (Mac OS X) 3.3.2. FreeBSD 3.3.3. Interix 3.3.4. IRIX 3.3.5. Linux 3.3.6. OpenBSD 3.3.7. Solaris 4. pkgsrc を使う 4.1. バイナリーパッケージを使う 4.1.1. バイナリーパッケージの配布場所 4.1.2. バイナリーパッケージをインストールする 4.1.3. パッケージをアンインストールする 4.1.4. インストールされているパッケージの情報を得る 4.1.5. インストール済パッケージの脆弱性チェック 4.1.6. インストール済パッケージのより新しいバージョンが pkgsrc にあ るかどうか調べる 4.1.7. その他の管理用機能 4.1.8. 警告 4.2. ソースからパッケージを構築する 4.2.1. 必要なもの 4.2.2. 配布ファイルの取得 4.2.3. 構築とインストール方法 5. pkgsrc を設定する 5.1. 全般的な設定 5.2. 構築の過程に影響を及ぼす変数 5.3. インストール過程に影響をおよぼす変数 5.4. コンパイラーの選択と設定 5.4.1. コンパイラーを選ぶ 5.4.2. コンパイラーへのフラグの追加 (CFLAGS) 5.4.3. リンカーへのフラグの追加 (LDFLAGS) 5.5. 開発者および上級者向けの設定 5.6. 構築オプションの選択 6. バイナリーパッケージを作る 6.1. 単数のバイナリーパッケージを構築する 6.2. バイナリーパッケージ作成用の設定 7. pkgsrc のバイナリーパッケージを全部作成する (バルクビルド) 7.1. まず考察、構築はその後 7.2. バルクビルドに必要なもの 7.3. 旧方式のバルクビルドを実行する 7.3.1. 設定 7.3.2. ほか、環境に関する考察 7.3.3. 操作 7.3.4. 何を実行するのか 7.3.5. 必要なディスク容量 7.3.6. chroot構築用の砂場を用意する 7.3.7. パッケージを部分的に構築する 7.3.8. バルクビルドの成果をアップロードする 7.4. pbulk 方式のバルクビルドを実行する 7.4.1. 事前準備 7.4.2. 設定 7.5. CD-ROM複数枚に収めたパッケージコレクションの作成 7.5.1. cdpackの使用例 8. インストールされたファイルのディレクトリー配置 8.1. ${LOCALBASE} 以下のファイルシステム配置 8.2. ${VARBASE} 以下のファイルシステム配置 9. よくある質問 9.1. pkgについて話しあうためのメーリングリストはありますか? 9.2. pkgviews のドキュメンテーションはどこにあるか? 9.3. パッケージ管理用ユーティリティー (pkgtools) 9.4. pkgsrc を root 以外で使う方法 9.5. distfile 取得時に、転送を再開する方法は? 9.6. pkgsrc の modular X.org をインストールあるいは使用する方法は? 9.7. 防火壁の内側からファイルを取得する方法 9.8. どうすればmake fetchでpassive FTPを使用することができますか? 9.9. 一度にすべてのdistfileを取得する方法 9.10. “Don't know how to make /usr/share/tmac/tmac.andoc”ってどういう こと? 9.11. “Could not find bsd.own.mk”ってどういうこと? 9.12. pkgsrcで'sudo'を使う 9.13. 設定ファイルの置き場所を変更する方法は? 9.14. 自動セキュリティーチェック 9.15. CFLAGS を無視するパッケージがあるのはなぜ? 9.16. パッケージが構築できません。どうすればいい? 9.17. “Makefile appears to contain unresolved cvs/rcs/??? merge conflicts”ってどういうこと? II. pkgsrc 開発者向けの手引き 10. 新しいパッケージを一から作る 10.1. ありがちな種類のパッケージ 10.1.1. Perl モジュール 10.1.2. KDE アプリケーション 10.1.3. Python モジュールおよびプログラム 10.2. 例 10.2.1. www/nvu パッケージはいかに pkgsrc に追加されたか 11. パッケージコンポーネント - ファイル、ディレクトリー、およびコンテンツ 11.1. Makefile 11.2. distinfo 11.3. patches/* 11.3.1. 個々のパッチファイルの構造 11.3.2. パッチファイルを作成する 11.3.3. パッチファイルの出どころ 11.3.4. パッチ作成の指針 11.3.5. 作者へのフィードバック 11.4. その他の必須のファイル 11.5. オプションのファイル 11.5.1. バイナリーパッケージに影響をおよぼすファイル 11.5.2. 構築の過程に影響をおよぼすファイル 11.5.3. 何の影響もおよぼさないファイル 11.6. work* 11.7. files/* 12. Makefile におけるプログラミング 12.1. 警告 12.2. Makefile 変数 12.2.1. 命名規約 12.3. コードの断片 12.3.1. リストに要素を追加する 12.3.2. 内部リストを外部リストに変換する 12.3.3. シェルコマンドに値を渡す 12.3.4. クォートの指針 12.3.5. BSD Make のバグの回避方法 13. PLIST 問題 13.1. RCS ID 13.2. PLIST の半自動生成 13.3. make print-PLIST の出力を細工する 13.4. PLIST における各種の置換 13.5. マニュアルページの圧縮 13.6. PLIST_SRC を使って PLIST のソースを変更する 13.7. プラットフォーム別に異なるPLIST 13.8. 複数のパッケージでディレクトリーを共有する 14. buildlink 方法論 14.1. パッケージを変換して buildlink3 を使うようにする 14.2. buildlink3.mk ファイルを書く 14.2.1. buildlink3.mk ファイルの分析 14.2.2. buildlink3.mk ファイルの BUILDLINK_API_DEPENDS.pkg を更新す る 14.3. builtin.mk ファイルを書く 14.3.1. builtin.mk ファイルの分析 14.3.2. ネイティブおよび pkgsrc のソフトウェアの選択に関する、大域 的な設定 15. pkginstall の枠組 15.1. インストール用のプレフィックス以外の場所にあるファイルとディレク トリー 15.1.1. ディレクトリーの操作 15.1.2. ファイルの操作 15.2. 設定ファイル 15.2.1. PKG_SYSCONFDIR はどのように設定されるか 15.2.2. ソフトウェアに設定ファイルの置き場所を教える 15.2.3. インストールの過程を修正する 15.2.4. 設定ファイルの処理をしないようにする 15.3. システム起動スクリプト 15.3.1. システム起動スクリプトの処理をしないようにする 15.4. システムユーザーとグループ 15.5. システムシェル 15.5.1. シェルの登録をしないようにする 15.6. フォント 15.6.1. フォントデータベースの自動更新をしないようにする 16. オプションの扱い 16.1. 標準の大域的なオプション 16.2. パッケージを変換して bsd.options.mk を使うようにする 16.3. オプション名 16.4. 依存パッケージのオプションを判別する 17. 構築の手順 17.1. 序 17.2. プログラムの場所 17.3. 構築の過程で使われるディレクトリー 17.4. 相の実行 17.5. fetch 相 17.5.1. 何を、どこから取得するか 17.5.2. ファイルの取得はどのようにおこなわれるか? 17.6. checksum 相 17.7. extract 相 17.8. patch 相 17.9. tools 相 17.10. wrapper 相 17.11. configure 相 17.12. build 相 17.13. test 相 17.14. install 相 17.15. package 相 17.16. 掃除をする 17.17. 他の役に立つターゲット 18. 構築や実行のために必要なツール 18.1. pkgsrc 構築用のツール 18.2. パッケージが必要とするツール 18.3. プラットフォーム附属のツール 18.4. ツールに関する質問 19. パッケージを動くようにする 19.1. 一般的な操作 19.1.1. パッケージの移植性 19.1.2. mk.conf から利用者が設定可能な変数を捕まえる方法 19.1.3. ユーザーとの対話 19.1.4. ライセンスの処理 19.1.5. 制限つきパッケージ 19.1.6. 依存性の処理 19.1.7. 他のパッケージとの衝突の処理 19.1.8. 構築することができない、あるいはすべきでないパッケージ 19.1.9. 一旦インストールしたら削除すべきでないパッケージ 19.1.10. セキュリティー問題を持つパッケージへの対処 19.1.11. 既存パッケージ修正時に、バージョンを上げるにはどうするか 19.1.12. パッケージのファイル中の各種テキストを置換する (SUBST の枠 組) 19.2. fetch 相での問題を修正する 19.2.1. distfileのダウンロードが単純にできないパッケージ 19.2.2. '古い'名前のまま更新されたdistfileの取り扱い 19.3. configure 相での問題を修正する 19.3.1. 共有ライブラリー - libtool 19.3.2. すでにlibtoolをサポートしているGNUパッケージでlibtoolを使う 19.3.3. GNU Autoconf/Automake 19.4. プログラミング言語 19.4.1. C, C++ および Fortran 19.4.2. Java 19.4.3. perl スクリプトを含むパッケージ 19.4.4. 他のプログラミング言語 19.5. build 相での問題を修正する 19.5.1. C および C++ のコードの条件つきコンパイル 19.5.2. コンパイラーのバグへの対処方法 19.5.3. undefined reference to “...” 19.5.4. メモリーが不足する 19.6. install 相での問題を修正する 19.6.1. 必要なディレクトリーを作成する 19.6.2. ドキュメンテーションのインストール場所 19.6.3. 最高得点ファイルをインストールする 19.6.4. パッケージを DESTDIR に対応させる 19.6.5. その他のインタープリターへのパスがハードコードされているパ ッケージ 19.6.6. perl モジュールをインストールするパッケージ 19.6.7. infoファイルをインストールするパッケージ 19.6.8. マニュアルページをインストールするパッケージ 19.6.9. GConf のデータファイルをインストールするパッケージ 19.6.10. scrollkeeper/rarian のデータファイルをインストールするパッ ケージ 19.6.11. X11 のフォントをインストールするパッケージ 19.6.12. GTK2 のモジュールをインストールするパッケージ 19.6.13. SGML または XML のデータをインストールするパッケージ 19.6.14. MIME データベースの拡張をインストールするパッケージ 19.6.15. intltool を使うパッケージ 19.6.16. 起動スクリプトをインストールするパッケージ 19.6.17. TeX モジュールをインストールするパッケージ 19.6.18. エミュレーションによるバイナリーの実行に対応したパッケージ 19.6.19. ハイカラーテーマのアイコンをインストールするパッケージ 19.6.20. デスクトップファイルをインストールするパッケージ 19.7. パッケージに問題があるという印をつける 20. デバッグ 21. 提出およびコミット 21.1. バイナリーパッケージの提出 21.2. ソースパッケージの提出 (NetBSD 開発者以外の方向け) 21.3. パッケージを追加・更新・削除する際の一般的な覚書 21.4. コミット: パッケージのCVSへのインポート 21.5. パッケージを新しいバージョンに更新する 21.6. pkgsrc のパッケージの名前を変更する 21.7. pkgsrcのパッケージを移動する 22. よくある質問 23. GNOME のパッケージングおよび移植 23.1. メタパッケージ 23.2. GNOME アプリケーションをパッケージングする 23.3. GNOME を新バージョンに更新する 23.4. 修正の指針 III. pkgsrc 基盤の内部 24. pkgsrc の基盤の設計 24.1. 変数定義の意図するもの 24.2. 問題を未然に防ぐ 24.3. 変数の評価 24.3.1. 読み込み時 24.3.2. 実行時 24.4. 変数の仕様を定める方法は? 24.5. Makefile の断片のインターフェースを設計する 24.5.1. 引数を伴うプロシージャー 24.5.2. 引数に応じたアクション 24.6. ファイルが読み込まれる順序 24.6.1. bsd.prefs.mk での順序 24.6.2. bsd.pkg.mk での順序 25. 退行テスト 25.1. 退行テストの枠組 25.2. 退行テストを実行する 25.3. 新しい退行テストを追加する 25.3.1. 上書き可能な関数 25.3.2. 補助関数 26. pkgsrc を移植する 26.1. pkgsrc を未対応のオペレーティングシステムに新たに移植する 26.2. 未対応のコンパイラーに新たに対応させる A. パッケージの簡単な例: bison A.1. ファイル A.1.1. Makefile A.1.2. DESCR A.1.3. PLIST A.1.4. pkglint でパッケージをチェックする A.2. 構築、インストール、パッケージングの手順 B. 構築のログ B.1. figletの構築 B.2. figlet のパッケージング C. pkgsrc FTP サーバーのディレクトリー配置 C.1. distfiles: ソースファイルの配布物 C.2. misc: 種々雑多なもの C.3. packages: バイナリーパッケージ C.4. reports: バルクビルドの結果報告 C.5. current, pkgsrc-20xxQy: ソースパッケージ D. the pkgsrc guide 編集の指針 D.1. make ターゲット D.2. 編集手順 List of Tables 1.1. pkgsrc が対応しているプラットフォーム 11.1. パッチ適用例 23.1. GNOME パッケージ用の PLIST の扱い Chapter 1. pkgsrc とは何か Table of Contents 1.1. イントロダクション 1.1.1. なぜ pkgsrc なのか? 1.1.2. 対応プラットフォーム 1.2. 概要 1.3. 専門用語 1.3.1. pkgsrc に関わる人たち 1.4. 体裁 1.1. イントロダクション Unix ベースのシステム向けの自由に使えるソフトウェアは数多くあり、それらはたいて いソースコード形式で提供されています。このようなソフトウェアを使うためには、あ らかじめ、ローカルシステム用の設定、コンパイルおよびインストールをしておく必要 がありますが、NetBSD パッケージコレクション (pkgsrc) はまさにこの作業をおこなっ てくれます。このほか、pkgsrc にはバイナリーパッケージを扱うための基本的なコマン ドがあるので、各利用者が時間をかけて自分でパッケージを構築する必要はありません 。 pkgsrc には現在、以下のものをはじめ数千個のパッケージがあります。 * www/apache - Apache web サーバー * www/firefox - Firefox web ブラウザー * meta-pkgs/gnome - GNOME デスクトップ環境 * meta-pkgs/kde3 - K デスクトップ環境 ……などなど。 pkgsrc には、各対応プラットフォームについて、 pthreads や X11 のようなプラット フォームによって異なる依存関係や、 IPv6 対応のような拡張機能の処理が組み込まれ ています。 1.1.1. なぜ pkgsrc なのか? pkgsrc が提供する重要な機能は、以下のようなものです * ソフトウェアのソースからの構築のほか、バイナリーパッケージの作成およびイン ストールが容易にできるようになります。ソースと最新のパッチをマスターサイト かミラーダウンロードサイトから取得し、チェックサムを検証してから、あなたの システムで構築をおこないます。バイナリーのみ配布されているソフトウェアも、 ネイティブプラットフォームと NetBSD でエミュレートされたプラットフォームの 双方で利用可能です。 * バイナリー、ライブラリー、マニュアルページ、その他の文書など、すべてのパッ ケージは首尾一貫したディレクトリーツリーにインストールされます。 * パッケージの依存関係は、パッケージ更新時も含め、自動的に解決されます。更新 の際には、さまざまなパッケージの設定ファイルが自動的に処理され、ローカルな 変更点は保持されます。 * NetBSD と同様、 pkgsrc は移植性を意図して設計されており、高い移植性を持つコ ードでできています。これにより、新しいプラットフォームへの移植は、きわめて 迅速な開発が可能です。この移植性はまた、 pkgsrc を全プラットフォームの間で 一貫したものにしています。 * 膨大な数のパッケージに対する、インストール先、受け入れ可能なソフトウェアラ イセンス、国際版の暗号が必要か、および構築時オプションは、すべて単一の設定 ファイルで管理されます。 * 完全なソース (ソフトウェアの配布ファイルは含みません) は、 BSD ライセンスの 下で自由に使用できますので、必要に応じて pkgsrc の拡張や改造ができます。そ のままでローカルパッケージやパッチに対応しているので、あなたの環境に合わせ て設定することができます。 pkgsrc では、以下の思想が基礎となっています。 * “正しいもののみが動くべき。” ? これは、パッケージにバグがある場合に、パッ ケージをただインストールして、それがうまく動くよう祈るよりも、バグを見つけ て、そのことを訴えるほうがよいということです。 pkgsrc には、そのようなバグ を見つけるために、静的な分析ツール (pkgtools/pkglint)、構築時の検査 (シェル スクリプトの移植性)や、インストール後の検査 (インストールされたファイル、共 有ライブラリーの参照、スクリプトインタープリター) といった、多数の検査が用 意されています。 * “動くものは、どこででも動くべき” ? NetBSD が多くのハードウェアアーキテク チャーに移植されているのと同様に、 pkgsrc は多くのオペレーティングシステム に移植されています。すべてのプラットフォームでパッケージが同じように動くよ うに注意が払われています。 1.1.2. 対応プラットフォーム pkgsrc には、これらのオペレーティングシステム用のソース配布およびバイナリー配布 の両形態があります。必要なソースまたはバイナリーを取ってくれば、すぐに pkgsrc で作業を始めることができます。 pkgsrc は FreeBSD の ports システムから派生したもので、はじめは NetBSD 専用とし て開発されていました。その後、 pkgsrc は大きく成長し、現在では以下のプラットフ ォームに対応しています。 Table 1.1. pkgsrc が対応しているプラットフォーム +-----------------------------------------------------------+ | プラットフォーム | 対応した日 | |---------------------------------------------+-------------| |NetBSD |1997 年 8 月 | |---------------------------------------------+-------------| |Solaris |1999 年 3 月 | |---------------------------------------------+-------------| |Linux |1999 年 6 月 | |---------------------------------------------+-------------| |Darwin (Mac OS X) |2001 年 10 月| |---------------------------------------------+-------------| |FreeBSD |2002 年 11 月| |---------------------------------------------+-------------| |OpenBSD |2002 年 11 月| |---------------------------------------------+-------------| |IRIX |2002 年 12 月| |---------------------------------------------+-------------| |BSD/OS |2003 年 12 月| |---------------------------------------------+-------------| |AIX |2003 年 12 月| |---------------------------------------------+-------------| |Interix (Microsoft Windows Services for Unix)|2004 年 3 月 | |---------------------------------------------+-------------| |DragonFlyBSD |2004 年 10 月| |---------------------------------------------+-------------| |OSF/1 |2004 年 11 月| |---------------------------------------------+-------------| |HP-UX |2007 年 4 月 | |---------------------------------------------+-------------| |Haiku |2010 年 9 月 | +-----------------------------------------------------------+ 1.2. 概要 このドキュメントは三部に別れています。第一部は pkgsrc 利用者向けの手引きで、パ ッケージコレクションの一つのパッケージを使う方法を、コンパイル済みのバイナリー パッケージのインストールと、自分自身でコピーしたNetBSDパッケージシステムから構 築する方法の両方で説明します。第二部の pkgsrc 開発者向けの手引きは、他のNetBSD ユーザーがその構築の詳細について知らなくても簡単にパッケージを構築できるように するために、パッケージを用意する方法を説明します。第三部の pkgsrc 基盤の内部は 、pkgsrc がどのように実装されているかを理解したい方のためのものです。 このドキュメントは、以下の各種形式で利用できます。 HTML, PDF, PS, TXT. 1.3. 専門用語 ここまでですでに“ポート(ports)”、“パッケージ(packages)”などについて何度も触 れています。ここで、このドキュメント中に使われている用語を説明します。 パッケージ(Package) ファイルのセットで、pkgsrc を使用したソフトウェアを構築するのに必要なことが 記述された構築手順書です。パッケージは、伝統的に /usr/pkgsrcの下に置かれま す。 NetBSDパッケージシステム “pkgsrc”の旧名です。これは NetBSD オペレーティングシステムの一部分ですが 、 NetBSD 以外のオペレーティングシステムでも NetBSD 同様に使えるようにする ことができます。パッケージの構築 (コンパイル)、インストール、および削除を扱 います。 distfile この用語は、ソフトウェアの作者が、彼の仕事を配布するために提供しているファ イルのことを指しています。NetBSDで構築するのに必要な全ての変更は、対応する パッケージに反映されます。通常distfileは、圧縮された tarアーカイブ形式です が、他の形式でも使用できます。distfileは通常は /usr/pkgsrc/distfilesの下に 保存されます。 ポート(Port) これはFreeBSDやOpenBSDの人たちが、私たちがパッケージ(package)と呼んでいるも のを表すために使われている用語です。NetBSDでは“ポート(port)”は、異なるア ーキテクチャーを参照する用語となります。 コンパイル済み(バイナリー)パッケージ pkgsrc を使ってdistfileより作成されたバイナリーのセットで、ひとつの.tgzファ イルに集められています。これはリコンパイルなしに同じマシンアーキテクチャー のマシンにインストールすることができます。パッケージは通常は/usr/pkgsrc/ packagesに生成され、それは ftp.NetBSD.orgにもアーカイブされています。 時々、これは、特にコンパイル済みのパッケージの文脈で、単に“パッケージ”と 表されることもあります。 プログラム 対応するパッケージが、distfileにあるファイルから作成した、インストールされ るべきソフトウェアのひとまとまりです。 1.3.1. pkgsrc に関わる人たち pkgsrc 利用者 pkgsrc 利用者とは、pkgsrc で提供されているパッケージを使う人たちです。ふつ うはシステム管理者のことです。パッケージを構成するソフトウェアを使う人たち (“末端利用者”ということがあります) については、 the pkgsrc guide では対象 としません。 pkgsrc 利用者には二通りあります: 一方は、構築済みバイナリーパッケージをイン ストールしたいだけの人たちです。もう一方は、pkgsrc のパッケージをソースから 構築する人たちで、こちらは、そのままインストールすることが目的の場合と、バ イナリーパッケージ自体を構築することが目的の場合があります。 pkgsrc 利用者 にとって必要なことはすべて、Part I, “pkgsrc 利用者向けの手引き”に書いてあ るはずです。 パッケージメンテナー パッケージメンテナーは、Part II, “pkgsrc 開発者向けの手引き”で説明されて いるようにパッケージを作成する人です。 基盤開発者 mk/ ディレクトリー以下にある各ファイルに携わる人たちです。 Part III, “ pkgsrc 基盤の内部”を通しで読む必要があるのは、この人たちだけのはずです (基 盤開発者以外の人が興味を持つこともあるでしょうが)。 1.4. 体裁 コマンドの実行例を示す場合、そのコマンドをrootで実行しなければならない/すること ができるか、“一般の”ユーザー権限で十分であるかを、シェルプロンプトで区別しま す。Cシェルかtcshを使っているものとして、rootのシェルプロンプトには #を、一般ユ ーザーのシェルプロンプトには%を使います。 Part I. pkgsrc 利用者向けの手引き Table of Contents 2. どこからpkgsrcを得て、どうやって最新に保つか 2.1. pkgsrc を初めて入手する 2.1.1. tar ファイル 2.1.2. anonymous CVS 経由 2.2. pkgsrc を最新の状態に保つ 2.2.1. tar ファイルを使用 2.2.2. CVS 経由 3. NetBSD 以外のシステムで pkgsrc を使う 3.1. バイナリー配布 3.2. pkgsrc を使う準備をする 3.3. プラットフォーム別の覚書 3.3.1. Darwin (Mac OS X) 3.3.2. FreeBSD 3.3.3. Interix 3.3.4. IRIX 3.3.5. Linux 3.3.6. OpenBSD 3.3.7. Solaris 4. pkgsrc を使う 4.1. バイナリーパッケージを使う 4.1.1. バイナリーパッケージの配布場所 4.1.2. バイナリーパッケージをインストールする 4.1.3. パッケージをアンインストールする 4.1.4. インストールされているパッケージの情報を得る 4.1.5. インストール済パッケージの脆弱性チェック 4.1.6. インストール済パッケージのより新しいバージョンが pkgsrc にあるか どうか調べる 4.1.7. その他の管理用機能 4.1.8. 警告 4.2. ソースからパッケージを構築する 4.2.1. 必要なもの 4.2.2. 配布ファイルの取得 4.2.3. 構築とインストール方法 5. pkgsrc を設定する 5.1. 全般的な設定 5.2. 構築の過程に影響を及ぼす変数 5.3. インストール過程に影響をおよぼす変数 5.4. コンパイラーの選択と設定 5.4.1. コンパイラーを選ぶ 5.4.2. コンパイラーへのフラグの追加 (CFLAGS) 5.4.3. リンカーへのフラグの追加 (LDFLAGS) 5.5. 開発者および上級者向けの設定 5.6. 構築オプションの選択 6. バイナリーパッケージを作る 6.1. 単数のバイナリーパッケージを構築する 6.2. バイナリーパッケージ作成用の設定 7. pkgsrc のバイナリーパッケージを全部作成する (バルクビルド) 7.1. まず考察、構築はその後 7.2. バルクビルドに必要なもの 7.3. 旧方式のバルクビルドを実行する 7.3.1. 設定 7.3.2. ほか、環境に関する考察 7.3.3. 操作 7.3.4. 何を実行するのか 7.3.5. 必要なディスク容量 7.3.6. chroot構築用の砂場を用意する 7.3.7. パッケージを部分的に構築する 7.3.8. バルクビルドの成果をアップロードする 7.4. pbulk 方式のバルクビルドを実行する 7.4.1. 事前準備 7.4.2. 設定 7.5. CD-ROM複数枚に収めたパッケージコレクションの作成 7.5.1. cdpackの使用例 8. インストールされたファイルのディレクトリー配置 8.1. ${LOCALBASE} 以下のファイルシステム配置 8.2. ${VARBASE} 以下のファイルシステム配置 9. よくある質問 9.1. pkgについて話しあうためのメーリングリストはありますか? 9.2. pkgviews のドキュメンテーションはどこにあるか? 9.3. パッケージ管理用ユーティリティー (pkgtools) 9.4. pkgsrc を root 以外で使う方法 9.5. distfile 取得時に、転送を再開する方法は? 9.6. pkgsrc の modular X.org をインストールあるいは使用する方法は? 9.7. 防火壁の内側からファイルを取得する方法 9.8. どうすればmake fetchでpassive FTPを使用することができますか? 9.9. 一度にすべてのdistfileを取得する方法 9.10. “Don't know how to make /usr/share/tmac/tmac.andoc”ってどういうこ と? 9.11. “Could not find bsd.own.mk”ってどういうこと? 9.12. pkgsrcで'sudo'を使う 9.13. 設定ファイルの置き場所を変更する方法は? 9.14. 自動セキュリティーチェック 9.15. CFLAGS を無視するパッケージがあるのはなぜ? 9.16. パッケージが構築できません。どうすればいい? 9.17. “Makefile appears to contain unresolved cvs/rcs/??? merge conflicts ”ってどういうこと? Chapter 2. どこからpkgsrcを得て、どうやって最新に保つか Table of Contents 2.1. pkgsrc を初めて入手する 2.1.1. tar ファイル 2.1.2. anonymous CVS 経由 2.2. pkgsrc を最新の状態に保つ 2.2.1. tar ファイルを使用 2.2.2. CVS 経由 ファイルをダウンロードして展開する前に、ファイルを展開する場所を決めておく必要 があります。 pkgsrc を root ユーザーとして使う場合、pkgsrc は通常は /usr/pkgsrc にインストールされます。ソースおよびバイナリーパッケージは、ファイルシステム中 のどこでも好きな場所にインストールしてかまいませんが、シェルその他のプログラム にとって特別な意味を持つスペースなどの文字は、パス名に含めてはいけません。アル ファベット、数字、下線とダッシュだけを使うのが安全な方法です。 2.1. pkgsrc を初めて入手する pkgsrc のファイルをダウンロードする前に、 current 枝と stable (安定版) 枝のどち らを使うのかを決めます。後者は、current 枝から四半期ごとに分岐するもので、セキ ュリティー上の更新に限って修正されます。 stable 枝の名前は、年と四半期を組み合 わせたもので、たとえば 2009Q1 となります。 次に、pkgsrc をどの方法でダウンロードするかを決めます。方法としては、tarファイ ル、 CVS経由があります。ここでは両方とも説明します。 2.1.1. tar ファイル pkgsrc のあらゆるファイルの一次配布元は ftp://ftp.NetBSD.org/pub/pkgsrc/ です。 目的別に多数のサブディレクトリーがありますが、それについては Appendix C, pkgsrc FTP サーバーのディレクトリー配置で詳しく説明しています。 current 枝の tar ファイルは、 current ディレクトリー内にあり、ファイル名は pkgsrc.tar.gz です。このファイルは、毎日、自動生成されます。 安定版の 2009Q1 枝の tar ファイルは、 pkgsrc-2009Q1 ディレクトリー内にあり、フ ァイル名は同じく pkgsrc-2009Q1.tar.gz です。 安定版 pkgsrc の tarball をダウンロードするには、以下のコマンドを実行します。 $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/pkgsrc-20xxQy/pkgsrc-20xxQy.tar.gz ここで、pkgsrc-20xxQy は、ダウンロードする安定版の枝名にします。たとえば、“ pkgsrc-2009Q1”になります。 ダウンロードしたら、以下のようにして展開します。 $ tar -xzf pkgsrc-20xxQy.tar.gz -C /usr こうすると、/usr/ に pkgsrc/ ディレクトリーが作られ、 /usr/pkgsrc/ 以下に全パッ ケージのソースが置かれます。 pkgsrc-current をダウンロードするには、以下のコマンドを実行します。 $ ftp ftp://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc.tar.gz 2.1.2. anonymous CVS 経由 pkgsrc の stable 枝名を指定して取得するためには、以下のコマンドを実行します。 $ cd /usr && cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -r pkgsrc-20xxQy -P pkgsrc ここで、pkgsrc-20xxQy は、チェックアウトする stable 枝名にします。たとえば“ pkgsrc-2009Q1”になります。 こうすると、/usr/ ディレクトリーに pkgsrc/ ディレクトリーが作られ、 /usr/pkgsrc / 以下に全パッケージのソースが置かれます。 pkgsrc current を取得するには、以下のコマンドを実行します。 $ cd /usr && cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc 利用可能な CVS ミラーサイト一覧から、もっとも速いものを選んで使ってください。 rsh のエラーメッセージが出た場合は、たとえば以下のようにして、環境変数 CVS_RSH を設定する必要があります。 $ cd /usr && env CVS_RSH=ssh cvs -q -z3 -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -P pkgsrc CVS_RSH=ssh の設定を今後も有効なままにする方法は、お使いのコマンドシェルのドキ ュメンテーションをご覧ください。 Bourne シェルの場合は、この設定を以下のとおり ユーザーの .profile に、またはより大域的に /etc/profile に書くことができます。 # set CVS remote shell command CVS_RSH=ssh export CVS_RSH CVS は、標準状態では、多くの人の望む挙動をしてくれません。しかし、以下の内容の .cvsrc というファイルをホームディレクトリーに置いておけば、標準での挙動を変える ことができます。このファイルを置いておけば、あなたの悩みや、余計なバグ報告もな くなるでしょうから、そうすることを強くおすすめします。このファイルに関する説明 は、 CVS のドキュメンテーションにあります。 # recommended CVS configuration file from the pkgsrc guide cvs -q -z3 checkout -P update -dP diff -upN rdiff -u release -d 2.2. pkgsrc を最新の状態に保つ pkgsrc を最新の状態に保つ方法としては、CVS をおすすめします (最初に tar ファイ ルを使ってインストールした場合でも、更新には CVS を使えます)。 CVS を使えば、 tar ファイルをあらためてダウンロードした場合にくらべ、帯域やハードディスクの負 荷を減らすことができます。 2.2.1. tar ファイルを使用 Warning tar ファイルを使って更新する場合は、まず、これまで使っていた pkgsrc ディレクト リーを完全に削除する必要があります。さもないと、それまでの間に pkgsrc から削除 されたファイルがローカルディスクに残ったままになり、不整合が生じてしまいます。 これまで使っていたファイルを消す場合、pkgsrc のファイルに独自に施した変更が、更 新後にすべて失われてしまいます。このため、CVS を使った更新を強くおすすめします 。 なお、distfile とバイナリーパッケージは、標準ではいずれも pkgsrc ツリー内に置か れますので、pkgsrc ツリーを更新する前に退避させておくことを忘れないでください。 DISTDIR と PACKAGES を設定して、標準のディレクトリーとは別の場所を pkgsrc が使 うような構成にすることもできます。詳細はChapter 5, pkgsrc を設定するをご覧くだ さい。 tar ファイルを使って pkgsrc を更新するためには、初回の入手時と同様に、tar ファ イルをダウンロードします。次に、pkgsrc ディレクトリーに独自の変更を何も加えてい ないことを確認します。 pkgsrc ディレクトリーを削除してから、新しい tar ファイル を展開します。これで完了です。 2.2.2. CVS 経由 CVS を使って pkgsrc を更新するためには、pkgsrc ディレクトリーへ移動して cvs を 実行します: $ cd /usr/pkgsrc && cvs update -dP rsh がエラーメッセージを出す場合は、前述の新規取得時と同様に、環境変数 CVS_RSH を設定する必要があります。たとえば以下のようにします。 $ cd /usr/pkgsrc && env CVS_RSH=ssh cvs up -dP 2.2.2.1. pkgsrc の別の枝に移る pkgsrc の更新時、CVS プログラムはそれまで使っていた枝をそのまま追いつづけます。 しかし、何らかの理由で stable 枝から current 枝に移りたい場合は、“update”キー ワードの後に“-A”オプションを追加して current に移ることができます。 current 枝から stable 枝に戻るには、“-rpkgsrc-2009Q3”オプションを追加します。 2.2.2.2. 私がおこなった変更は、更新時にどうなるか? pkgsrc の更新時、CVS プログラムは CVS リポジトリーに登録されたファイルだけに手 を加えます。このため、あなたが独自に作成したパッケージは、変更されずに残ります 。あなたが CVS の管理下にあるファイルを独自に修正している場合、 CVS による更新 時には、あなた独自の変更と他の人による (CVS リポジトリーに反映されている) 変更 を統合しようとします。詳細は、CVS のマニュアルの“update”の章をご覧ください。 Chapter 3. NetBSD 以外のシステムで pkgsrc を使う Table of Contents 3.1. バイナリー配布 3.2. pkgsrc を使う準備をする 3.3. プラットフォーム別の覚書 3.3.1. Darwin (Mac OS X) 3.3.2. FreeBSD 3.3.3. Interix 3.3.4. IRIX 3.3.5. Linux 3.3.6. OpenBSD 3.3.7. Solaris 3.1. バイナリー配布 Section 4.1, “バイナリーパッケージを使う”をご覧ください。 3.2. pkgsrc を使う準備をする ブートストラップキットは、以下のようにして簡単にソースからインストールすること ができます。 # env CVS_RSH=ssh cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout pkgsrc # cd pkgsrc/bootstrap # ./bootstrap bootstrap を実行する前に、上で例示した方法以外で pkgsrc を取得する方法について は、Chapter 2, どこからpkgsrcを得て、どうやって最新に保つかを参照してください。 上で例示した bootstrap コマンドでは、 prefix (プログラムのインストール先) をデ フォルトの /usr/pkg とし、パッケージデータベースのディレクトリー (pkgsrc 内部の 記録用) を /var/db/pkg とします。これらをコマンドライン引数で設定することもでき ます。 Note bootstrap は bmake ツールをインストールします。 pkgsrc で構築をおこなう際には、 この bmake を使ってください。たとえばこの手引きにおいて“make”は bmake に読み 替えてください。 3.3. プラットフォーム別の覚書 いくつかのプラットフォームについては、以下のことを知っておくとよいでしょう。 3.3.1. Darwin (Mac OS X) 対応は、 Darwin 5.x 以上に対しておこなわれています。始める前に、Apple Developer Connection から Mac OS X Developer Tools をダウンロードしてインストールする必要 があります。詳細は http://developer.apple.com/macosx/ をご覧ください。また、X11 Window System を使うパッケージを構築したい場合は、 X11 (Developer Tools に附属 するオプションパッケージ) をインストールしておくことも必要です。 3.3.2. FreeBSD 確認および対応は、 FreeBSD 4.7 および 5.0 に対しておこなわれています。これら以 外のバージョンでも動くかもしれません。 ブートストラップキットのインストールに際しては、 FreeBSD のユーザーランドのツー ルと衝突することがないように注意を払ってください。以下のような複数の事項があり ます。 1. FreeBSD の ports は、 /var/db/pkg 以下にパッケージデータベースを置きます。 このため、ブートストラップスクリプトの --pkgdbdir オプションで、別の場所 (たとえば /usr/pkgdb) を指定することをおすすめします。 2. FreeBSD ports のツールを使う予定がない場合は、混同を避けるために、それらを 移動してしまってもいいかもしれません。たとえば以下のようにします。 # cd /usr/sbin # mv pkg_add pkg_add.orig # mv pkg_create pkg_create.orig # mv pkg_delete pkg_delete.orig # mv pkg_info pkg_info.orig 3. ブートストラップスクリプトを使った際、 mk.conf ファイルの例は /etc/ mk.conf.example ファイルに置かれます。 3.3.3. Interix Interix は Windows NT カーネルの POSIX 準拠のサブシステムで、 Cygwin よりも密接 にカーネルと統合された Unix 風の環境を提供します。 Interix は Windows Services for Unix パッケージの一部であり、ライセンスされた Windows 2000, XP (XP Home は 含まず), 2003 のコピー用として、無料で使うことができます。SFU は、http:// www.microsoft.com/windows/sfu/ からダウンロードできます。 確認は、Services for Unix 3.5 に対しておこなわれています。 3.0 や 3.1 でも動作 するかもしれませんが、公式には対応していません。 (3.0/3.1 の主な違いは、 pthreads がないことですが、このほかにも libc に欠けているものがあるかもしれませ ん。) Services for Unix Applications (別名 SUA) は、Windows Server 2003 R2 (5.2), Windows Vista および Windows Server 2008 (6.0), Windows 7 および Windows Server 2008 R2 (6.1) に統合されている構成要素です。本稿執筆時点において、 SUA の Interix 6.0 (32 ビット) および 6.1 (64 ビット) サブシステムで確認がおこなわれて います。これら以外のバージョンでも動作するかもしれません。 Interix 5.x サブシス テムで、pkgsrc を使った確認はまだおこなわれていません。 3.3.3.1. Interix/SFU のインストールに際して pkgsrc を使うためには、Windows Services for Unix 3.5 の配布物のうち、最低限、以 下のパッケージをインストールする必要があります。 * Utilities -> Base Utilities * Interix GNU Components -> (all) * Remote Connectivity * Interix SDK Interix 上で pkgsrc を使う場合、Utilities 以下の "UNIX Perl" はインストールしな いでください。これは共有モジュールに対応していない Perl 5.6 で、 /usr/local に インストールされますが、混乱を起こすだけです。これのかわりに、 pkgsrc (またはバ イナリーパッケージ) の Perl 5.8 をインストールします。 Remote Connectivity 以下の "Windows Remote Shell Service" のインストールは必須 ではありませんが、inetd を動作させるために Remote Connectivity そのものはインス トールすることをおすすめします。 インストール中に、Interix のプログラムに対して setuid を有効にするかどうか、ま た、パス名の大文字と小文字を標準で区別するかどうかを尋ねられるかもしれません。 setuid は有効にするようにし、また大文字と小文字はかならず区別するようにします。 (大文字と小文字を区別しないと、 perl をはじめ多くのプログラムが構築できなくなり ます。) 註: 最近の Windows サービスパックでは、バイナリーを実行する方法を (データ実行防 止機能を使ったものに) 変更します。 pkgsrc その他の gcc でコンパイルされたバイナ リーを信頼して使うためには、 POSIX.EXE, PSXDLL.DLL, PSXRUN.EXE, PSXSS.EXE (899522 またはこれより新しいもの) を含んだホットフィックスをインストールする必 要があります。ホットフィックスは Microsoft からサポート窓口を通じて提供されてい ますが、 Debian Interix Port が、ほとんどの Interix ホットフィックスを個人的に 使えるように http://www.debian-interix.net/hotfixes/ に用意しています。 Interix を使えるようにするためには、上述のホットフィックスのほか、 Data Execution Prevention を完全に無効化する必要があるかもしれません。これが必要とな るのは、ある種の CPU を使っている場合だけです。上述のホットフィックスのいずれか ひとつをインストールした後にも gcc その他のアプリケーションが依然として繰り返し segfault する場合には、 Windows ブートドライブ上の適切な "boot.ini" 行に、以下 のオプションを追加することができます: /NoExecute=AlwaysOff (警告: これは DEP を 完全に無効化するものであり、 Administrators グループのユーザーとしてアプリケー ションをよく実行する場合には、セキュリティー上の危険となる可能性があります。) 3.3.3.2. Interix/SFU がインストール済みの場合はどうすればよいか SFU がすでにインストールされており、その設定を変更して pkgsrc が動作するように したい場合は、以下のことに気をつけてください。 * UNIX Perl をアンインストールするため、Add/Remove Programs を使い、Microsoft Windows Services for UNIX を選んで Change をクリックします。インストーラー で Add or Remove を選んでから Utilities->UNIX Perl のチェックを外します。 * ファイルシステムの大文字と小文字の区別を有効にするため、REGEDIT.EXE を実行 して以下のレジストリーキーを変更します。 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel DWORD 値 "obcaseinsensitive" を 0 に設定した後、リブートします。 * setuid バイナリーを有効にするため (これは必須ではありません)、REGEDIT.EXE を実行して以下のレジストリーキーを変更します。 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Services for UNIX DWORD 値 "EnableSetuidBinaries" を 1 に設定した後、リブートします。 3.3.3.3. pkgsrc を使ううえで重要な覚書 パッケージの管理者 (pkgsrc の "su" ユーザーと "pkg_add" を実行するユーザーのい ずれかまたは両方) は、ローカルの Administrators グループに所属している必要があ ります。bootstrap を実行するユーザーも同様です。これは、通常の pkgsrc が "root" を要求するのにくらべ、若干緩い条件です。 パッケージの管理者は umask を 002 に設定するようにします。そうしておかないと、 自動的に "make install" が文句をいうようになります。こう設定することで、 /var/ db/pkg 以下に書かれるディレクトリーに Administrators グループが確実に書き込み可 能とできます。 http://www.interopsystems.com/ にある人気のある Interix バイナリーパッケージは 、古いバージョンの pkgsrc の pkg_* ツールを使います。理想的には、これらは pkgsrc と混用しないほうがよいものです。これらを pkgsrc のパッケージと同時に使う 場合は、かならず、それぞれのバイナリーパッケージに応じて適切な pkg_* ツールを使 うようにしてください。 DOS 型のコンソールウィンドウ (csh および ksh のスタートアップショートカットから 起動されるものを含む) 用の TERM の設定は "interix" です。たいていのシステムには 、そのような termcap/terminfo エントリーがありませんが、ほとんどの場合、以下の ような .termcap エントリーを用意すれば十分です。 interix:kP=\E[S:kN=\E[T:kH=\E[U:dc@:DC@:tc=pcansi: 3.3.3.4. Interix プラットフォームの制約 Interix は、完全な Unix 風のプラットフォームのとっつきやすく柔軟な代替品として は十分なものですが、Interix を最大限に活用したい場合は、若干の制約があることを 知っておくとよいでしょう。 * X11: Interix には標準的な X11R6 クライアントライブラリー一式が附属しており、 X11 にもとづくアプリケーションを実行することができますが、 X サーバーは附属しま せん。X サーバーの選択肢としては、 StarNet X-Win32, Hummingbird Exceed (Interix 用に調整された Interop X Server というものを、Interop Systems が提 供しています) や、 Cygwin に含まれるフリーの X11 サーバーがあります。 * X11 アクセラレーション: Interix は、Win32 アプリケーションとは完全に別の NT サブシステム内で動いて いるため、現在のところ、アクセラレーションのための X11 プロトコルの各種拡張 (MIT-SHM や DGA など) には対応していません。ローカルの X サーバーを使った対 話的なアプリケーションのほとんどは、そこそこ速く動きますが、フルモーション ビデオなど画像に特化したアプリケーションを動かすには、思ったよりも速い CPU が必要になるかもしれません。 * オーディオ: Interix は、オーディオ出力にネイティブで対応していません。オーディオに対応 するため、pkgsrc では Interix 上で esound クライアントサーバー型オーディオ システムを使っています。他のほとんどのプラットフォームとは異なり、 audio/ esound パッケージには、 esd サーバーが含まれません。 Interix ホストを経由し てオーディオを出力するには、 emulators/cygwin_esound パッケージもあわせてイ ンストールする必要があります。 * CD/DVD, USB, SCSI: 現在のところ、Interix はデバイスへの直接のアクセスに対応していませんので、 CD/DVD ドライブ、USB デバイス、SCSI デバイスを、ファイルシステム経由以外の 方法で使うことはできません。このため、 Interix を使って、直接 CD/DVD を焼く ことなどはできません。 * テープドライブ: CD-ROM や SCSI デバイスと同様の制約があるため、 Interix ではテープドライブ に直接アクセスすることもできません。ただし、 Cygwin を介して使うことで (Cygwin の esound サーバーを介してオーディオを使えるように) テープドライブ にアクセスできるようにするための作業がおこなわれています。 3.3.3.5. Interix 上での pkgsrc に関する、既知の問題 一般的に、Windows システム上に "root" ユーザーを用意することは必須ではありませ ん。ユーザーがローカルの Administrators グループに属してさえいれば、それで十分 です。ただし、現在のところ、パッケージのなかには "root" という名前のユーザーが 特権ユーザーであることを前提にしているものがあります。そのようなパッケージのた めに、"root" という名前のユーザーを作ってもかまいませんが、ローカルの Administrators グループ (または、お使いの言語でこれに対応するもの) に属させるよ うにしてください。 pkg_add は、$PKG_DBDIR 内のディレクトリーを、モード 0775 ではなく 0755 で作成し ます。この問題を回避するため、当面は、ローカルの Administrator (または、お使い の言語でこれに対応するもの) としてパッケージをインストールするか、各パッケージ のインストール後に以下のコマンドを実行してください。 # chmod -R g+w $PKG_DBDIR 3.3.4. IRIX 機能する C コンパイラー、つまり、 gcc または SGI の MIPS および MIPSpro コンパ イラー (cc/c89) が必要です。 CC 環境変数を、使用するコンパイラーに応じて設定し てください。 MIPSpro コンパイラースイートのライセンスがない場合は、http:// freeware.sgi.com/ から gcc の tar 配布ファイルをダウンロードすることができます 。 IRIX 6.5.17 以上が必要です。このバージョンの IRIX で if_indextoname(3), if_nametoindex(3) などへの対応がおこなわれたからです。 現在のところ、pkgsrc は同時には一つの ABI にしか対応しません。つまり、古い 32 ビット ABI、新しい 32 ビット ABI、64 ビット ABI を切り替えることはできません。 最初に "abi=n32" を使って始めた場合は、すべてのパッケージがこれを使って構築され ることになります。 このため、環境変数または mk.conf の CFLAGS が衝突しないようにしてください。特に 、 n32 オブジェクトファイルに lib64 を、また、その逆の組合せを、リンクしないよ うにしてください。 /etc/compiler.defaults を確認してください。 pkgsrc ツリーの実体を別ホストから NFS を使ってマウントしている場合は、必ず WRKOBJDIR をローカルのディレクトリーに設定しておいてください。 IRIX のリンカー は、ネットワーク経由でマウントされたファイルシステム越しにリンクするときに問題 を起こすことが時々あるからです。 事前準備の過程では、imake(1) などのプログラムにすべて正しいオプションが設定され るはずですが、ローカルの設定に依存するオプションを設定したい場合があるかもしれ ません。詳細は、pkgsrc/mk/defaults/mk.conf をご覧ください。そしてもちろん、お使 いのコンパイラーのマニュアルページもご覧ください。 SGI の MIPSPro コンパイラーを使っている場合は、 mk.conf で PKGSRC_COMPILER= mipspro を設定してください。これを設定しないと、 pkgsrc は gcc を使っていることを仮定す るので、コンパイラーに不適切なフラグを渡すことがあります。なお、標準状態では、 bootstrap は適切な mk.conf.example を作成するはずです。 gcc と MIPSPro コンパイラーチェインの両方をインストールしているが、必ず MIPSPro を使うようにしたい場合は、PATH に gcc の場所 (ありがちなのは /usr/freeware/bin) を含めないでください。さらに (重要)、 '--preserve-path' フラグを bootstrap に渡 してください。 3.3.5. Linux Linux のなかには、libtermcap と libcurses (libncurses) のいずれかを必要とするも のがあります (たとえば Debian GNU/Linux など)。そのようなディストリビューション では libncurses-dev パッケージ (または相当品) をインストールすれば問題なくなる はずです。 pkgsrc は gcc (GNU Compiler Collection) と icc (Intel C++ Compiler) のどちらに も対応しています。gcc が標準で使われます。 icc は i386 上の icc 8.0 と 8.1 で確 認がおこなわれています。 icc を使って bootstrap をおこなうには、以下のようにします (icc は標準のディレク トリーにインストールされているものとします)。 env CC=/opt/intel_cc_80/bin/icc LDFLAGS=-static-libcxa \ ac_cv___attribute__=yes ./bootstrap Note icc 8.1 では、引数の -static-libcxa を `-i-static' にする必要があります。 icc は __attribute__ に対応していますが、GNU configure のテストではネストした関 数を使っており、 icc はネストした関数に対応していません。__attribute__ を # undef してしまうと、 Linux の多くのヘッダーファイルが __attribute__ なしでは正 しくコンパイルできず、壊れてしまうという副作用があります。このため、テストは、 コンパイラーが __attribute__ に対応しているとしたもので上書きする必要があります 。 bootstrap した後に、mk.conf で PKGSRC_COMPILER を設定します。 PKGSRC_COMPILER= icc icc がインストールされるディレクトリーは標準では /opt/intel_cc_80 であり、 pkgsrc でもこのディレクトリーを標準としています。これ以外のディレクトリーに icc をインストールしている場合は、mk.conf で ICCBASE を設定してください。 ICCBASE= /opt/icc pkgsrc は、icc が提供する実行時ライブラリーを静的リンクするので、作られたバイナ リーはその共有ライブラリーがインストールされていないシステムでも動かすことがで きます。 ただし、libtool は、C++ の共有ライブラリーをリンクして記録する時に実行された (ライブラリーごとに -Bstatic や -Bdynamic オプションの指定がまちまちな) ld(1) コマンドをもとにライブラリーの一覧を展開しますこのことから、libtool でリンクさ れた C++ の共有ライブラリーは、libtool が修正されない限り、 icc のライブラリー に対して実行時依存性を持った状態になります。 3.3.6. OpenBSD 確認および対応は、 OpenBSD 3.0 および 3.2 に対しておこなわれています。 ブートストラップキットのインストールに際しては、 OpenBSD のユーザーランドのツー ルと衝突することがないように注意を払ってください。以下のような複数の事項があり ます。 1. OpenBSD の ports は、 /var/db/pkg 以下にパッケージデータベースを置きます。 このため、ブートストラップスクリプトの --pkgdbdir オプションで、別の場所 (たとえば /usr/pkgdb) を指定することをおすすめします。 2. OpenBSD ports のツールを使う予定がない場合は、混同を避けるために、それらを 移動してしまってもいいかもしれません。たとえば以下のようにします。 # cd /usr/sbin # mv pkg_add pkg_add.orig # mv pkg_create pkg_create.orig # mv pkg_delete pkg_delete.orig # mv pkg_info pkg_info.orig 3. ブートストラップスクリプトを使った際、 mk.conf ファイルの例は /etc/ mk.conf.example ファイルに置かれます。 OpenBSD の make プログラムは mk.conf も使います。このファイル中の pkgsrc 特有の記述を以下のように括ることで、回 避することができます。 .ifdef BSD_PKG_MK # pkgsrc の記述。たとえば defaults/mk.conf の挿入など .else # OpenBSD の記述 .endif 3.3.7. Solaris 対応は x86 と sparc それぞれの Solaris 2.6 から 9 までに対しておこなわれていま す。機能する C コンパイラーが必要です。 gcc 2.95.3 および Sun WorkShop 5 の両者 で確認がおこなわれています。 Solaris 8 でのブートストラップ過程およびパッケージの構築では、以下の各パッケー ジが必要になります。 * SUNWsprot * SUNWarc * SUNWbtool * SUNWtoo * SUNWlibm なお、2006 年 6 月現在、Solaris 上では GNU binutils はサポートされていません。 どのコンパイラーを使うにせよ、コンパイラーツールと $prefix を、必ず PATH に含め てください。これは、/usr/ccs/{bin,lib} や、たとえば /usr/pkg/{bin,sbin} などで す。 3.3.7.1. gcc を使う場合 どのパッケージの構築にも同じ gcc だけを使うようにすると、話が簡単になります。 外部から導入した gcc を使うのはブートストラップの時だけにして、その後は gcc を lang/gcc から構築するかバイナリーパッケージをインストールして、ブートストラップ で使った gcc は削除することをおすすめします。 gcc のバイナリーパッケージは、http://www.sunfreeware.com/ から辿れます。 3.3.7.2. Sun WorkShop を使う場合 少なくとも、以下の各パッケージを (WorkShop 5.0 から) インストールしておく必要が あります。 * SPROcc - Sun WorkShop Compiler C 5.0 * SPROcpl - Sun WorkShop Compiler C++ 5.0 * SPROild - Sun WorkShop Incremental Linker * SPROlang - Sun WorkShop Compilers common components mk.conf で、以下の変数を設定します。 CC= cc CXX= CC CPP= cc -E CXXCPP= CC -E Note C プリプロセッサーを使って C のソースコード以外のものを処理するパッケージのなか には、この CPP の設定では問題が起きるものがあるかもしれません。 3.3.7.3. SunPro を使って 64 ビットバイナリーを構築する 64 ビットパッケージを構築する場合に必要なことは、 mk.conf ファイルに以下の行を 追加するだけです。 PKGSRC_COMPILER= sunpro ABI= 64 Note この設定は、SPARC アーキテクチャーについてのみ確認がおこなわれています。 Intel および AMD マシンでは、必要な作業がまだ残っています。 3.3.7.4. ありがちな問題 libtool を使っていると、時々、/bin/ksh がセグメンテーションフォールトを起こして クラッシュすることがあります。回避策は、たとえば shells/bash をインストールして 、以下の各行を mk.conf に追加するなどして、別のシェルを configure スクリプト用 に使うことです。 CONFIG_SHELL= ${LOCALBASE}/bin/bash WRAPPER_SHELL= ${LOCALBASE}/bin/bash こうしてから、devel/libtool-base パッケージを構築しなおします。 Chapter 4. pkgsrc を使う Table of Contents 4.1. バイナリーパッケージを使う 4.1.1. バイナリーパッケージの配布場所 4.1.2. バイナリーパッケージをインストールする 4.1.3. パッケージをアンインストールする 4.1.4. インストールされているパッケージの情報を得る 4.1.5. インストール済パッケージの脆弱性チェック 4.1.6. インストール済パッケージのより新しいバージョンが pkgsrc にあるかどう か調べる 4.1.7. その他の管理用機能 4.1.8. 警告 4.2. ソースからパッケージを構築する 4.2.1. 必要なもの 4.2.2. 配布ファイルの取得 4.2.3. 構築とインストール方法 基本的に、pkgsrc には二通りの使い方があります。一つ目の使い方は、パッケージ用の ツールだけをインストールして、他の人が用意したバイナリーパッケージを使うもので す。これは、pkgsrc のうち“pkg”に相当します。二つ目の使い方は、pkgsrc の“src ”もインストールするものです。こうすると、自分でパッケージを構築することができ ますし、他の人が用意したバイナリーパッケージを使うこともできます。 4.1. バイナリーパッケージを使う ftp.NetBSD.org サーバーとそのミラーサイトには、バイナリーパッケージを揃えて置い てあり、すぐにインストールして使える状態になっています。このバイナリーパッケー ジは、以下のような、標準のディレクトリーの設定を使って構築されています。 * LOCALBASE は /usr/pkg で、ここにほとんどのファイルがインストールされます。 * 設定ファイルは /usr/pkg/etc です。 * VARBASE は /var で、インストール後に変更することのあるファイルはここにイン ストールされます。 何らかの理由 (root 権限がないなど) でこの各ディレクトリーが使えない場合は、この バイナリーパッケージを使うことはできないので、パッケージ用ツールを自分で構築す る必要があります。これについてはSection 3.2, “pkgsrc を使う準備をする”に説明 があります。 4.1.1. バイナリーパッケージの配布場所 バイナリーパッケージをインストールするためには、まず、バイナリーパッケージがど こで入手できるか知っている必要があります。最初に調べる場所は、pkgsrc の主たる FTP サーバーの /pub/pkgsrc/packages ディレクトリーです。 このディレクトリーには、複数のプラットフォーム用のバイナリーパッケージがありま す。最初に、お使いのオペレーティングシステムのディレクトリーを選んでください。 (バージョン番号がついているディレクトリーは、歴史的な理由で残っているだけですの で、無視してください。) 次に、ハードウェアアーキテクチャーを選び、その次に、OS のバージョンと pkgsrc の“バージョン”の組合せを選びます。 多くの場合、このディレクトリーには、パッケージ管理ツールが入った bootstrap.tar.gz というファイルがあります。このファイルがない場合は、お使いのオ ペレーティングシステムにパッケージ管理ツールがもともとあるのでしょう。このファ イルをダウンロードして / ディレクトリーに展開します。展開すると、/usr/pkg (この 下には、バイナリーパッケージ管理用のツールがある) および /var/db/pkg (インスト ールされたパッケージのデータベース用) の各ディレクトリーが作られます。 4.1.2. バイナリーパッケージをインストールする 前節で説明したディレクトリーには、 All というサブディレクトリーがあり、当該プラ ットフォーム向けのバイナリーパッケージがすべて置かれています。ただし、FTP また は CDROM (利用しているメディアによって異なります) 経由での配布ができないパッケ ージは、除かれています。 パッケージを FTP または HTTP サーバーから直接インストールするには、 Bourne シェ ルと互換のシェルで、以下のコマンドを実行します (最初に su して root になってお くことを忘れずに)。 # PATH="/usr/pkg/sbin:$PATH" # PKG_PATH="ftp://ftp.NetBSD.org/pub/pkgsrc/packages/OPSYS/ARCH/VERSIONS/All" # export PATH PKG_PATH CDROM, DVD または NFS でマウントされた置き場所からインストールする場合などは、 URL のかわりに、ローカルのパスを使うこともできます。複数の置き場所からパッケー ジをインストールしたい場合は、それらをセミコロンで区切って PKG_PATH に設定する ことができます。 以上の準備ができれば、パッケージのインストールは非常に簡単です。 # pkg_add openoffice2 # pkg_add kde-3.5.7 # pkg_add ap2-php5-* なお、インストールしようとするパッケージを実行するために必要となるパッケージも 、すべて一緒にインストールされますが、この必要なパッケージも同じ置き場所に用意 されていると仮定されます (訳註: 必要なパッケージがすべて揃うように PKG_PATH を 設定する必要があるということ)。 パッケージをインストールすると、脆弱性のあるパッケージがインストールされること もありえます。このため、pkg_admin audit を定期的に (特に、パッケージを新たにイ ンストールした後には) 実行して、脆弱性の影響がある構成となっているかどうかを確 認するようにしてください。 パッケージをインストールした後に、PATHに /usr/pkg/bin と /usr/pkg/sbin が含まれ ている事を確認してください。これで、インストールされたプログラムを実際に使い始 めることができます。 4.1.3. パッケージをアンインストールする パッケージをアンインストールする方法は、そのパッケージを、ソースコードからイン ストールしたかバイナリーパッケージからインストールしたかにかかわらず同じです。 どちらの方法でインストールされたかは、pkg_delete コマンドは一切関知しません。パ ッケージの削除は、pkg_delete package-name を実行するだけでおこなうことができま す。パッケージ名はバージョン番号をつけてもつけなくてもかまいません。一連のパッ ケージをアンインストールするために、たとえば *emacs* のようにワイルドカードを使 うこともできます。この場合、ワイルドカードが pkg_delete に渡る前にシェルに展開 されないようにするため、ワイルドカードはかならずクォートするようにします。 -r オプションは非常に強力です。これを使うと、指定したパッケージに依存しているパ ッケージをすべて削除してから、指定したパッケージそのものを削除します。たとえば 、 # pkg_delete -r jpeg は、jpeg および jpeg を使うすべてのパッケージを削除します。これにより、 jpeg パ ッケージをアップグレードすることが可能になります。 4.1.4. インストールされているパッケージの情報を得る pkg_info は、インストールされているパッケージや、バイナリーパッケージのファイル に関する情報を表示します。 4.1.5. インストール済パッケージの脆弱性チェック NetBSD セキュリティーオフィサーとパッケージグループでは、 pkgsrc に含まれる (あ るいは含まれていた) パッケージの既知の脆弱性のリストを保守しています。このリス トは、 NetBSD FTP サイトの ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/ vulnerabilities から入手できます pkg_admin fetch-pkg-vulnerabilities を使うと、このリストを自動的にダウンロード し、システムにインストールされているパッケージすべてについてセキュリティー検証 をすることができます。 このセキュリティー検証は、ふたつの部分からできています。ひとつめの段階は pkg_admin fetch-pkg-vulnerabilities で、 NetBSD FTP サイトから脆弱性のリストを ダウンロードするものです。ふたつめは pkg_admin audit で、インストールされている パッケージに脆弱性がないかどうか検証するものです。脆弱性のあるパッケージがあっ た場合、次のように出力してくれます: Package samba-2.0.9 has a local-root-shell vulnerability, see http://www.samba.org/samba/whatsnew/macroexploit.html vulnerabilities ファイルを毎日ダウンロードして、常に最新の状態にしておきたいと いう方もいらっしゃることでしょう。 root ユーザーの crontab(5) エントリーを適切 に書いておけば、そういうこともできます。たとえば、 # vulnerabilities ファイルをダウンロード 0 3 * * * /usr/sbin/pkg_admin fetch-pkg-vulnerabilities >/dev/null 2>&1 というエントリーを書けば、毎日午前 3 時に vulnerability リストを更新することに なります。この例は一日一回ですが、もっと頻繁に更新することもできます。さらに、 パッケージの検証を daily security script でおこないたい方もいらっしゃるでしょう 。これは、以下のような行を /etc/security.local に書いておけば実現できます。 /usr/sbin/pkg_admin audit 4.1.6. インストール済パッケージのより新しいバージョンが pkgsrc にあるかどうか調 べる インストール済パッケージが最新かどうかを確認するには、 pkgtools/lintpkgsrc をイ ンストールして、 lintpkgsrc に“-i”を付けて実行します。たとえば以下のようにな ります。 % lintpkgsrc -i ... Version mismatch: 'tcsh' 6.09.00 vs 6.10.00 このようになった場合、パッケージを更新し、そのパッケージに依存しているパッケー ジをすべて再構築するために、 make update を使うことができます。 4.1.7. その他の管理用機能 pkg_admin は、パッケージシステムにおける、各種の管理用機能を実行します。 4.1.8. 警告 pkg_add(1) マニュアルページで警告されている、自分自身で作ったものでないバイナリ ーパッケージをインストールすることが孕む危険性、無思慮にこのようなファイルをイ ンストールすることにより、あなたのシステムにセキュリティーホールが生じる事につ いてよく注意してください。 もちろん、パッケージ、パッケージの構築用のコンパイラー、その他、呼び出されるす べてのツールのソースコードを完全に読んで理解したわけではない場合は、ソースから インストールしたパッケージにもすべて、同じ警告があてはまります。 4.2. ソースからパッケージを構築する pkgsrc を入手すると、 pkgsrc ディレクトリーには、カテゴリー別に整理されたパッケ ージ一式が含まれます。オンラインでパッケージの索引を見られますし、また、 pkgsrc ディレクトリーで make readme してローカルで README.html を作って、 www/lynx や www/firefox などの好みの web ブラウザーで見られるようにすることもできます。 パッケージのインストール先のプレフィックスは、デフォルトでは /usr/pkg です。こ れを変えたい場合は、 mk.conf で LOCALBASE を設定してください。一つのシステム内 で複数の LOCALBASE を定義して使い分けるようなことはしないでください (chroot 環 境内は除く)。 以下、本章では、パッケージがすでに pkgsrc に含まれていると仮定しています。もし 、そうでなければ、Part II, “pkgsrc 開発者向けの手引き”で、パッケージを新たに 作る方法をご覧ください。 4.2.1. 必要なもの ソースからパッケージを構築するためには、機能する C コンパイラーが必要です。 NetBSD の場合は、“comp”および“text”配布物一式をインストールしておく必要があ ります。X11関連のパッケージを構築する場合は、さらに“xbase”および“xcomp”配布 物一式も必要です。 4.2.2. 配布ファイルの取得 パッケージを構築するうえで最初にすることは、配布ファイル (未変更のソース) のダ ウンロードです。配布ファイルがまだダウンロードされていない場合、 pkgsrc は自動 的に配布ファイルを取得します。 distfiles ディレクトリーに必要なファイルがすでに存在していれば、インターネット に接続する必要はありません。 CD-ROMなどにdistfilesがある場合には、CD-ROMを / cdrom にmountし、 DISTDIR=/cdrom/pkgsrc/distfiles を mk.conf に加えて、使うことができます。 標準状態では、人気のあるパッケージを置いているサーバー (たとえば SourceForge.net のミラー) に過大な負荷をかけないようにするため、配布サイトのリ ストの順序はランダムに入れ換えられます。このため、別の distfile を取得する必要 が生ずるたびに、すべてのミラーからの取得を、新たな (ランダムな) 順序で試みます 。この機能は、MASTER_SORT_RANDOM=NO を設定して止めることができます (PKG_DEVELOPER が設定されている場合は、すでに無効化されています)。 主要な配布サイトをあなたのところに近いサイトで上書きすることができます。変数を ひとつかふたつ設定すると、マスターサイトにアクセスする順序を変えることができま す。 MASTER_SORT には、ドメインの接尾辞を空白で区切ったリストが含まれます。 MASTER_SORT_REGEX はこれより柔軟なもので、正規表現を空白で区切ったリストが含ま れます。これは MASTER_SORT より高い優先度を持ちます。 pkgsrc/mk/defaults/ mk.confの例を参照してください。これにより、帯域幅と時間が節約できるかもしれませ ん。 これらの設定は、シェルの環境変数でも変更できますし、その設定を今後も有効にした ければ、 mk.conf ファイルにその定義を書き加えておくこともできます。 パッケージが他のパッケージ(例えば meta-pkgs/kde3 など) に依存している場合、ダウ ンロードとコンパイルを交互に繰り返すことがあります。最初に必要なすべてのソース を確実にダウンロードするには、次のコマンドを使用します: % make fetch-list | sh このコマンドは必要なファイルを取ってきてdistfiles ディレクトリーに保存するため のシェルコマンドを出力、実行します。必要なファイルを手動でダウンロードするとい う方法もあります。 4.2.3. 構築とインストール方法 ソフトウェアがダウンロードされると、パッチが適用された上で、コンパイルされます 。それにかかる時間はあなたのコンピューターによりますし、そのソフトウェアが依存 している他のパッケージの数とそれらのコンパイルにかかる時間にもよります。 Note bootstrap または pkgsrc を NetBSD 以外のシステムで使う場合は、この手引きで例示 されている“make”ではなく pkgsrc の bmake コマンドを使ってください。 たとえば、パッケージの各構成要素を構築するには、シェルプロンプトで % cd misc/figlet % make とします。 次は新たにコンパイルされたプログラムを、実際にあなたのシステムにインストールし ます。インストールしようとしているパッケージのディレクトリーにいる間に % make install と入力してください。 パッケージをシステムにインストールするには root 権限が必要なことがあります。た だし、pkgsrc には必要な時のみ su する機能があり、実際のインストール時にのみ root になることができます。 そのソフトウェアは今まさにインストールされ、使用できるようにセットアップされた ことになります。もうこれ以上コンパイル後の作業ファイルは必要とされないので、 % make clean と入力し作業ディレクトリー内のファイルを削除してしまってもかまいません。もし、 プログラムをコンパイルするときに、依存関係により他のパッケージがコンパイル/イン ストールされたならば、それらも次のコマンドにより、きちんと削除することができま す。 % make clean-depends figlet ユーティリティーを例にあげると、Appendix B, 構築のログのように構築するこ とにより、システムにインストールすることができます。 プログラムはパッケージツリーのデフォルトルート- /usr/pkgにインストールされます 。もし、このディレクトリーが趣味にあわないのであれば、環境変数 LOCALBASE を設定 してください。この値はパッケージツリーのルートとして使用されます。例えば、/usr/ localを使う場合、 LOCALBASE=/usr/local と設定してください。なお、これにはパッケ ージ専用のディレクトリーを使い、他のプログラムと共有させないようにします(つまり 、 LOCALBASE=/usr などとしてはいけません)。また、LOCALBASEツリー内には、独自の ファイルやディレクトリー (src/, obj/, pkgsrc/ のようなもの)は一切追加しないよう にしてください。これは、パッケージシステムがインストールするプログラムなどのフ ァイルが、そこにインストールされているかもしれない別のファイルと衝突することが ないようにするためです。 いくつかのパッケージは、構築時にいくつかのコンフィギュレーションオプションを変 えるためにmk.confを参照します。デフォルトの設定項目については、 pkgsrc/mk/ defaults/mk.confをのぞいてみてください。LOCALBASE といった環境変数は、pkgsrc使 用時に毎回使えるようにmk.confで設定しておくことができます。 時々、パッケージの構築やインストールの際に、“水面下”で何が起きているかを見た いことがあります。これは、デバッグのためなのかもしれませんし、好奇心が高じたも のかもしれません。このような用途に使うための変数がいくつも用意されています。 1. make(1)コマンドを PKG_DEBUG_LEVEL=2付きで呼び出すと、大量の情報が表示される ようになります。たとえば、 make patch PKG_DEBUG_LEVEL=2 は、“patch”の段階および、そこに至るまでに呼び出されるコマンドをすべて表示 します。 2. 特定のmake(1)定義の値を知りたい場合は、 show-varターゲットとともに、 VARNAME定義を使います。たとえば、 make(1)変数 LOCALBASEの展開結果を表示する には、以下のようにします。 % make show-var VARNAME=LOCALBASE /usr/pkg % 自分で作った(次章参照)、手動でpkgsrc/packagesに置いた、またはリモートFTPサーバ ーに置かれたバイナリーパッケージをインストールしたい場合は、"bin-install"ターゲ ットを使うことができます。このターゲットは、 - もし可能ならば - pkg_add(1)を使 ってバイナリーパッケージをインストールするほか、make packageをおこないます。検 索先リモートFTPサーバーのリストは BINPKG_SITES変数に保持され、デフォルトは ftp.NetBSD.orgです。pkg_add(1)に与えるべきフラグはすべて、BIN_INSTALL_FLAGS変数 で保持することができます。詳細は pkgsrc/mk/defaults/mk.confをご覧ください。 最後に警告: 標準でないLOCALBASE の設定をしたシステムの場合は、各パッケージのイ ンストール前にこれらを設定するようにしてください。複数のディレクトリーを同じ目 的用に分散して使うことはできないからです。そのようなことをすると、pkgsrcはイン ストール済みのパッケージを正しく検出することができず、無惨に失敗することになる でしょう。また、コンパイル済バイナリーパッケージは、通常はデフォルトのLOCALBASE である /usr/pkgを使って構築されているので、標準でないLOCALBASEを使っている場合 は、とにかくコンパイル済バイナリーパッケージをインストールしてはいけません。 Chapter 5. pkgsrc を設定する Table of Contents 5.1. 全般的な設定 5.2. 構築の過程に影響を及ぼす変数 5.3. インストール過程に影響をおよぼす変数 5.4. コンパイラーの選択と設定 5.4.1. コンパイラーを選ぶ 5.4.2. コンパイラーへのフラグの追加 (CFLAGS) 5.4.3. リンカーへのフラグの追加 (LDFLAGS) 5.5. 開発者および上級者向けの設定 5.6. 構築オプションの選択 pkgsrc システム全体の設定は、ひとつのファイル (通常は mk.conf) でおこなわれます 。pkgsrc がこのファイルをどのディレクトリーから探すかは、インストールの時に決ま ります。NetBSD で、ベースシステムの make(1) を使う場合は、/etc/ ディレクトリー となります。これ以外の場合はすべて、 ${PREFIX}/etc/ が標準の場所となり、これは bootstrap プログラムに指示したバイナリーパッケージのインストール先に依存します 。 bootstrap の実行中に、設定ファイルの例が作成されます。このファイルを使うには、 ${PREFIX}/etc ディレクトリーを作って、その中にこのファイルをコピーする必要があ ります。 この設定ファイルの書式は、通常の BSD 形式の Makefile の書式です。pkgsrc 全体の 設定は、このファイルで変数を設定することでおこなわれます。なお、ここではあらゆ る種類の変数を定義することができ、また、特別なエラーの検査 (たとえば、綴りの誤 り) はおこなわれないので、設定が有効かどうか調べるには、いろいろ試す必要がある ということに注意してください。 5.1. 全般的な設定 本節では、pkgsrc の全パッケージに影響する変数をいくつか掲げます。ユーザーが設定 可能な変数の完全な一覧は、 mk/defaults/mk.conf にあり、各変数の目的もコメントで 説明されています。 * LOCALBASE: パッケージをどこにインストールするか。標準では /usr/pkg になりま す。異なる LOCALBASE をもつバイナリーパッケージを混在させないでください。 * CROSSBASE: “cross”カテゴリーのパッケージをどこにインストールするか。標準 では ${LOCALBASE}/cross になります。 * X11BASE: 当該システムで X11 がどこにインストールされているか。標準では /usr /X11R6 になります。 * DISTDIR: pkgsrc のパッケージ構築用にダウンロードしたままの状態のソース配布 物をどこに置くか。標準では ${PKGSRCDIR}/distfiles になります。 * PKG_DBDIR: インストールされたパッケージに関するデータベースをどこに置くか。 標準では /var/db/pkg になります。 * MASTER_SITE_OVERRIDE: 設定した場合、その値でパッケージの MASTER_SITES が上 書きされます。 * MASTER_SITE_BACKUP: 配布ファイルおよびパッチファイルが、ローカルにも、 $ {MASTER_SITES} や ${PATCH_SITES} にもなかった場合のための予備の場所 (複数 可)。標準では ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/${DIST_SUBDIR}/ と ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/${DIST_SUBDIR}/ になります。 * BINPKG_SITES: バイナリーパッケージの配布サイトのリストです。rel および arch は、それぞれ OS リリース (“2.0”など) およびアーキテクチャー (“mipsel”な ど) で置き換えられます。 * ACCEPTABLE_LICENSES: 受け入れ可能なライセンスのリストです。ライセンス名は、 大文字・小文字を区別します。このリストにないライセンスが適用されるパッケー ジを構築しようとするたびに、エラーメッセージが表示されます。簡便な変更でラ イセンスを受け入れるようにできる場合は、エラーメッセージでこの値の変更方法 の説明も表示されます。 5.2. 構築の過程に影響を及ぼす変数 XXX * PACKAGES: バイナリーパッケージ用のディレクトリーの最上層。標準では $ {PKGSRCDIR}/packages になります。 * WRKOBJDIR: 設定した場合、この値を最上層として、別に分離された作業ディレクト リーが作られて ${WRKDIR} (前述) からシンボリックリンクされます。これは、複 数のアーキテクチャー用のパッケージを構築する際に便利です。さらに、$ {PKGSRCDIR} を NFS マウントして、 ${WRKOBJDIR} は各アーキテクチャーのローカ ルに置くということができます。(なお、 PKGSRCDIR は利用者が設定するようなも のではないことを断っておきます ?これは pkgsrc ツリーのルートを参照する内部 的な定義です。ここでいう pkgsrc ツリーは、多くの文脈がありえます。) * LOCALPATCHES: pkgsrc に含まれていないローカルなパッチ用のディレクトリーです 。さらなる情報は、Section 11.3, “patches/*”をご覧ください。 * PKGMAKECONF: パッケージの BSD 形式の Makefile が使用する mk.conf ファイルの 場所です。この変数が設定されていない場合は、 /usr/src 以下の構築用の設定を 見ることのないようにするために、 MAKECONF が /dev/null に設定されます。 * DEPENDS_TARGET: 標準では、依存するパッケージはインストールされるだけで、バ イナリーパッケージの作成まではおこなわれません。この変数を package に設定し て、依存パッケージのインストール後にバイナリーパッケージを自動的に作成する ことができます。 5.3. インストール過程に影響をおよぼす変数 ほとんどのパッケージは、WRKDIR のサブディレクトリーへのインストールに対応してい ます。そのようにインストールをすれば、本番のファイルシステムに手を加えずにパッ ケージを構築することができます。 DESTDIR への対応には、以下の二通りの形態があり ます。 * 基本的な (basic) DESTDIR 対応。パッケージのインストールや、バイナリーパッケ ージ作成は、通常と同じく root で実行します。 * 完全な (full) DESTDIR 対応。完全な構築、インストール、バイナリーパッケージ 作成を、通常ユーザー権限でおこなうことができます。root 権限が必要なのは、パ ッケージを追加するときだけです。 現在では、標準状態で DESTDIR へ対応するようになっています。 USE_DESTDIR=no を設 定すれば以前のような DESTDIR を使わない挙動に戻すことができますが、この設定は廃 止予定ですので、パッケージを DESTDIR 対応にするほうが望ましいでしょう。 DESTDIR への対応によって、各種ターゲットの挙動が少し変わります。パッケージを構 築してからインストールする場合は、 package-install を使ってください。package お よび install の各ターゲットは、何もしてくれません。 package-install は、 DEPENDS_TARGET にすることができます。 bin-install は、インストール用に root の パスワードを尋ねてきますが、その後に失敗し、 package-install があらためてパスワ ードを尋ねてきます。 基本的な DESTDIR 対応を使う場合、make clean は root で実行する必要があります。 foo/bar パッケージに対して、 DESTDIR に完全に対応できているかどうか、以下のコマ ンドでテストすることができます。 $ id uid=1000(myusername) gid=100(users) groups=100(users),0(wheel) $ mkdir $HOME/packages $ cd $PKGSRCDIR/foo/bar DESTDIR に完全に対応しているか確認します。 root 権限は必要ないはずです。 $ make USE_DESTDIR=yes install root 権限なしでパッケージを作ってみます。 $ make USE_DESTDIR=yes PACKAGES=$HOME/packages package 以下のコマンドでは、 su(1) を使って root 権限を得られることが必要です。 $ make USE_DESTDIR=yes PACKAGES=$HOME/packages package-install あとは、通常のユーザーで以下のコマンドを実行します。 $ make clean 5.4. コンパイラーの選択と設定 5.4.1. コンパイラーを選ぶ pkgsrc は、標準では GCC を使ってパッケージを構築します。これは /etc/mk.conf で 以下の変数を設定して変えることができます。 PKGSRC_COMPILER: パッケージ構築時に使われる一連のコンパイラーを指定する値を並べたものです。 以下の値を使うことができます。 * distcc: 分散 C/C++ コンパイラー (連鎖可能) * ccache: コンパイラーキャッシュ (連鎖可能) * gcc: GNU C/C++ コンパイラー * mipspro: Silicon Graphics, Inc. MIPSpro (n32/n64) * mipspro: Silicon Graphics, Inc. MIPSpro (o32) * sunpro: Sun Microsystems, Inc. WorkShip/Forte/Sun ONE Studio 標準では“gcc”になります。 PKGSRC_COMPILER の設定には、適切なコンパイラー 本体とともに、 ccache と distcc のいずれかまたは両方を併用することができま す。たとえば“ccache gcc”のようにします。この変数の設定では、コンパイラー 本体を示す値を最後に置くようにします。なお、コンパイラー本体はただ一つだけ 掲げるようにします (たとえば、“sunpro gcc”などとすることはできません)。 GCC_REQD: パッケージの構築用として、最低限必要な GCC のバージョンを指定します。システ ム附属の GCC がこの条件を満たさない場合、pkgsrc はそのかわりに使うため、 GCC のパッケージを構築してインストールします。 5.4.2. コンパイラーへのフラグの追加 (CFLAGS) CFLAGS 変数を設定したい場合は、 = 演算子は使わずに、かならず += 演算子を使って ください。 CFLAGS+= -your -flags CFLAGS= のようにする (つまり、“+”を付けない) と、独自のフラグを追加する必要が あるパッケージで問題を起こすことがあります。 CPU に特化した最適化に関心がある場 合は、 devel/cpuflags パッケージを見ておくとよいでしょう。 5.4.3. リンカーへのフラグの追加 (LDFLAGS) configure および build の各段階において、リンカーにフラグを渡したい場合、二通り の方法を使うことができます。すなわち、 LDFLAGS または LIBS のいずれかを設定しま す。両者の違いは、LIBS はコマンドラインに付け加えられますが、 LDFLAGS はそれよ り早く現れます。 LDFLAGS はあらかじめ読み込まれ、 USE_IMAKE の設定や mk/ x11.buildlink3.mk のインクルードの有無に応じた ELF マシン向けの rpath の設定が 追加されます。 CFLAGS と同様に、この設定を上書きしたいわけでなければ、 += 演算 子を使います。 LDFLAGS+= -your -linkerflags 5.5. 開発者および上級者向けの設定 XXX * PKG_DEVELOPER: パッケージ開発者向けに、いくつかの正当性検査を実行します。 o パッチが曖昧さゼロで適用できることを確認する o check-shlibs を実行して、すべてのバイナリーパッケージが共有ライブラリー を見つけられることを確認する。 * PKG_DEBUG_LEVEL: パッケージの構築およびインストールの際に表示される、デバッ グ用出力の水準です。標準の値は 0 です。この場合、コマンドは (通常の、標準状 態で、静粛な操作で) 実行されるだけで、表示されません。値が 1 の場合、すべて のシェルコマンドを実行前に表示します。値が 2 の場合、すべてのシェルコマンド を実行前に表示するほか、実際に実行される経過を set -x により表示します。 5.6. 構築オプションの選択 パッケージのなかには、構築時にオプションがあるものがあります。通常は、数通りの 依存性からいずれかを選択、大きな依存性を伴うオプション対応の有効化、実験的な機 能の有効化などです。 パッケージがどんなオプションに対応しているか (対応している場合)、また、どのオプ ション同士が排他的かを調べるには、make show-options を実行します。結果は、たと えば以下のようになります。 The following options are supported by this package: ssl Enable SSL support. Exactly one of the following gecko options is required: firefox Use firefox as gecko rendering engine. mozilla Use mozilla as gecko rendering engine. At most one of the following database options may be selected: mysql Enable support for MySQL database. pgsql Enable support for PostgreSQL database. These options are enabled by default: firefox These options are currently enabled: mozilla ssl 以下の変数を mk.conf で定義して、パッケージに対してどのオプションを有効にするか を選んでおくことができます: PKG_DEFAULT_OPTIONS は、対応している全パッケージを 対象に、オプションを選択または無効化するために使うことができます。 PKG_OPTIONS. pkgbase は、特定のパッケージ pkgbase を対象に、オプションを選択または無効化する ために使うことができます。この両変数で列挙された各変数が選択され、“-”が先頭に ついた変数は無効化されます。いくつか例を示します。 $ grep "PKG.*OPTION" mk.conf PKG_DEFAULT_OPTIONS= -arts -dvdread -esound PKG_OPTIONS.kdebase= debug -sasl PKG_OPTIONS.apache= suexec ここで重要なことは、パッケージのメンテナーがこの方法を使って標準状態のオプショ ンを提示している場合、そのオプションを選択したくなければ明示的に削除する必要が あるということです。よくわからない場合は、make show-options を使ってオプション の設定状況を調べることができます。 以下の各設定は、以下に掲げた順に適用されます。このため、あるオプションは、それ が最後に選択または無効化された設定に従って選択または無効化されます。 1. パッケージのメンテナーが提示した、標準状態のオプション 2. 旧式の変数 (後述) の設定から導かれるオプション 3. PKG_DEFAULT_OPTIONS 4. PKG_OPTIONS.pkgbase 互いに排他的なオプション群からは、最後に選択されたオプションが使われ、それ以外 のオプションは自動的に無効化されます。オプション群のあるオプションが明示的に無 効化された場合は、その前に選択されたオプションがあれば、それが使われます。必須 のオプション群からどのオプションも選択されなかった場合は、エラーとなり、パッケ ージの構築は失敗します。 このオプションの枠組が導入される前は、構築オプションは mk.conf で各オプションご との変数 (たいていは USE_FOO という名前) を設定することで選択していました。利用 者が現在のオプションの枠組に容易に移行できるようにするため、このような旧式の変 数は、適切なオプションの設定 (PKG_OPTIONS.pkgbase) に自動的に変換されます。利用 者に対しては、 mk.conf を更新してオプションの枠組を直接使うよう促す警告が表示さ れます。旧式の変数への対応は、いずれ打ち切られる予定です。 Chapter 6. バイナリーパッケージを作る Table of Contents 6.1. 単数のバイナリーパッケージを構築する 6.2. バイナリーパッケージ作成用の設定 6.1. 単数のバイナリーパッケージを構築する パッケージを構築しインストールしたら、 pkg_add(1) を使って別のシステムにインス トールすることができるバイナリーパッケージを作ることができます。こうすると、複 数のホストで同じパッケージを構築するような、 CPU時間の無駄をなくすことができま す。また、あなたのバイナリーパッケージを配布して、他の人が簡単にインストールで きるようにすることもできます。 バイナリーパッケージを作るには、pkgsrc の適切なディレクトリーへ移動したうえで、 make package を実行します。 # cd misc/figlet # make package これにより、パッケージが構築、インストール(もし、まだ済んでいなければ)され、イ ンストールされたパッケージからバイナリーパッケージが構築されます。これはpkg_*ツ ールを使い操作できます。バイナリーパッケージは/usr/pkgsrc/packages 以下に、gzip されたtarファイルとして作成されます。上記のmisc/figletの例の続きは、Section B.2, “figlet のパッケージング”を参照して下さい。 このようなバイナリーパッケージを提出する方法については、このドキュメントの後の Chapter 21, 提出およびコミットを参照してください。 6.2. バイナリーパッケージ作成用の設定 Section 17.17, “他の役に立つターゲット”を参照してください。 Chapter 7. pkgsrc のバイナリーパッケージを全部作成する (バルクビルド) Table of Contents 7.1. まず考察、構築はその後 7.2. バルクビルドに必要なもの 7.3. 旧方式のバルクビルドを実行する 7.3.1. 設定 7.3.2. ほか、環境に関する考察 7.3.3. 操作 7.3.4. 何を実行するのか 7.3.5. 必要なディスク容量 7.3.6. chroot構築用の砂場を用意する 7.3.7. パッケージを部分的に構築する 7.3.8. バルクビルドの成果をアップロードする 7.4. pbulk 方式のバルクビルドを実行する 7.4.1. 事前準備 7.4.2. 設定 7.5. CD-ROM複数枚に収めたパッケージコレクションの作成 7.5.1. cdpackの使用例 同じパッケージが動くマシンが複数ある場合、それぞれのマシンでソースからパッケー ジを構築するのは、時間の無駄です。バイナリーパッケージ一式を作る方法が二通りあ ります。古いバルクビルドシステムと、新しい (2007 年からの) 分散バルクビルド (parallel bulk build, pbulk) システムです。本章では、構築したパッケージが有用な ものにできるよう、この二通りのバルクビルドの設定方法を説明します。 7.1. まず考察、構築はその後 バルクビルドを最後までおこなうには、数日、あるいは数週間かかることもあります。 このため、始める前に、その準備について考えたほうがよいでしょう。少なくとも、以 下の点に注意を払ってください。 * バイナリーパッケージを ftp.NetBSD.org にアップロードしたい場合、バイナリー パッケージに関する以下の条件を、かならず満たすようにします。 o ftp.NetBSD.org に置かれるパッケージは、 NetBSD 開発者が、信頼のおけるマ シン (つまり、あなたが root 権限を持っており、かつ、あなただけが root 権限を持つマシン) で構築したものである必要があります。 o ftp.NetBSD.org には、安定版の枝 (たとえば 2009Q1 など) から作成されたも のだけを置くようにします。これは、利用者が一見しただけで、置かれている パッケージがどれだけ古いものかわかるようにするためです。 o パッケージは root で構築する必要があります。パッケージのなかには、実行 時に set-uid バイナリーを必要とするものがあり、今のところ、そのようなパ ッケージを特権ユーザー以外で作成すると、うまく動作しないからです。 * バルクビルドによって、お使いのシステムが壊されることのないようにしてくださ い。バルクビルドの大半は、root 権限で動くので、少なくとも chroot 環境か、 (お使いのオペレーティングシステムに応じた) 何らかの制限環境で実行するように します。個々のパッケージが、ファイルを LOCALBASE 以外の場所にインストールし ようとしたり、 /etc にあるファイルを編集しようとしたりする事例が、いくつも あります。さらに、バルクビルドでは、その過程において、 /usr/pkg (あるいは LOCALBASE で設定された場所) にパッケージをインストールしたりアンインストー ルしたりするので、構築中は、どのパッケージも必要ない (アンインストールされ ても困らない) ようにしておいてください。 7.2. バルクビルドに必要なもの 完全なバルクビルドには、大量のディスク容量が必要です。ディスクスペースの一部は 読み取り専用でもかまいませんが、書き込みが必要なものもあります。ディスクスペー スの一部はリモートファイルシステム (NFS など) でもかまいませんが、ローカルとし たほうがよいものもあります。ディスクスペースの一部は一時ファイルシステムでもか まいませんが、突然リブートしても平気な (恒久的な) ファイルシステムが必要なもの もあります。 * 10 GB: distfile 用 (要読み書き、リモート可、一時可) * 10 GB: バイナリーパッケージ用 (要読み書き、リモート可、要恒久) * 400 MB: pkgsrc ツリー用 (読み取り専用可、リモート可、要恒久) * 5 GB: LOCALBASE 用 (要読み書き、ローカル推奨、pbulk では一時可、旧形式では 要恒久) * 5 GB: ログファイル用 (要読み書き、リモート可、要恒久ファイルシステム) * 5 GB: 一時ファイル用 (要読み書き、ローカル推奨、一時ファイルシステム可) 7.3. 旧方式のバルクビルドを実行する Note バルクビルドには、二つの方式があります。旧方式のバルクビルドと、新方式の“pbulk ”です。後者の方式をおすすめします。 7.3.1. 設定 7.3.1.1. build.conf build.conf ファイルは、バルクビルドの主たる設定ファイルです。pkgsrc ツリーを最 新に保つ方法、 distfile のダウンロード方法、パッケージの構築方法や、報告の作成 方法を設定することができます。註釈つきの設定例が pkgsrc/mk/bulk/ build.conf-example にあります。これを使うには、build.conf-example を build.conf にコピーし、このファイル中のコメントに従って編集します。 7.3.1.2. mk.conf mk.conf で以下の変数を設定するとよいでしょう。デフォルト設定についての詳細は pkgsrc/mk/defaults/mk.confを見てください。 ACCEPTABLE_LICENSESはローカルポリシ ーに適合するようにしておきます。この例では SKIP_LICENSE_CHECK=yes としており、 ライセンスの検査を一切おこないません。 PACKAGES?= ${_PKGSRCDIR}/packages/${MACHINE_ARCH} WRKOBJDIR?= /usr/tmp/pkgsrc # build here instead of in pkgsrc BSDSRCDIR= /usr/src BSDXSRCDIR= /usr/xsrc # for x11/xservers OBJHOSTNAME?= yes # use work.`hostname` FAILOVER_FETCH= yes # insist on the correct checksum PKG_DEVELOPER?= yes SKIP_LICENSE_CHECK= yes バルクビルド用として、特に有用なオプションが、 mk/bulk/bsd.bulk-pkg.mk の冒頭に いくつかあります。そのなかでも最も有用な部類のものを、ここで簡単に説明します。 * 遅いマシンを使っている場合は、 USE_BULK_BROKEN_CHECK を“no”に設定するとよ いでしょう。 * 読み出し専用の pkgsrc ツリーを使ってバルクビルドをする場合は、ログファイル が作られるディレクトリーとして BULKFILESDIR を設定する必要があります。そう しないと、 pkgsrc ディレクトリー内にログファイルが作られます。 * このほか、重要な変数として BULK_PREREQ があります。これは、他のパッケージを 構築する際には常に使える状態になっているべきパッケージを並べたリストです。 その他、いくつかのオプションが、 pkgsrc の基盤内に散在しています。 * ALLOW_VULNERABLE_PACKAGES は yes に設定するようにします。バルクビルドの目的 はバイナリーパッケージを作ることであり、脆弱性の有無は重要ではありません。 この変数を設定しておかないと、バルクビルドにおいて、脆弱性のあるパッケージ を構築しようとしなくなるため、構築でエラーがあっても検出できなくなってしま います。 * CHECK_FILES (pkgsrc/mk/check/check-files.mk) を“yes”に設定すると、インス トールされた一連のファイルが PLIST と一致することを確認することができます。 * CHECK_INTERPRETER (pkgsrc/mk/check/check-interpreter.mk) を“yes”に設定す ると、インストールされた“#!”で始まるスクリプトが、指定されたインタープリ ターを見つけられることを確認することができます。 * PKGSRC_RUN_TEST を“yes”に設定して、各パッケージのインストール前に自己診断 を実行することができます。なお、パッケージのなかには“良質の”乱数を大量に 使うものがあるので、バルクビルドを実行しているマシンが、完全なアイドル状態 にはならないようにする必要があります。さもないと、一部の診断プログラムが、 新しい乱数データが使えるようになるのを待つ間、ハングしているかのように見え るようになります。 7.3.1.3. pre-build.local バルクビルドでは、ビルド前の段階の最後に、サイト独自の作業を行なうよう設定する ことができます。/usr/pkgsrc/mk/bulkに pre-build.localファイルがあると、ビルド前 の段階の最後に、このファイルが(sh(1)スクリプトとして)実行されます。 pre-build.localの使い方の例としては、このファイルに echo "I do not have enough disk space to build this pig." \ > misc/openoffice/$BROKENF のような内容を書いておいて、3 GB近くのディスク容量が必要な個々のパッケージの構 築をしないようにする、というものがあります。 7.3.2. ほか、環境に関する考察 /usr/pkgはバルクビルド開始時に完全に削除されるので、ログインシェルが別の場所に あることを確認してください。ログインシェルを/usr/local/binに移して(それに合わせ て passwd ファイルも修正して)おくか、/etc/rc.localでpkg_add(1)を使って(再)イン ストールするようにしておきます。これでリブート後もログインできます(パッケージが 削除されてもシェルのプロセスは死なず、シェルを新たに起動できなくなるだけです)。 また、1.5より前のNetBSDを使っていたり、何らかの理由でpkgsrc版のsshを使いたい場 合は、rc.localでsshdが起動する前にsshをインストールするようにしておきます: (cd /usr/pkgsrc/security/ssh && make bulk-install) if [ -f /usr/pkg/etc/rc.d/sshd ]; then /usr/pkg/etc/rc.d/sshd fi こうしておかないと、バルクビルド終了後や、あるいはマシンがリブートやクラッシュ した場合にsshでログインできなくなります。警告しておきましたよ! :) 7.3.3. 操作 すでにインストールされているどのパッケージも必要ない状態にしてください。 Warning バルクビルドの過程で、すべてのパッケージ、設定ファイルと、さらに、 /var, /home その他の場所にあるファイルがいくつか削除されます。なので、システムに悪影響を与 えるおそれのある権限で、バルクビルドを実行しないでください。 その他、構築の妨げになりうるもの(/usr/localにインストールされているライブラリー など) もすべて削除しておいてください。root になって、以下のようにタイプします: # cd /usr/pkgsrc # sh mk/bulk/build 何らかの理由で前回の構築が完了していない場合(電源断、システムパニックなど) は、 以下を実行すると、その続きをすることができます: # sh mk/bulk/build restart バルクビルドが終わると、その要約がメールで届きます。また、build.conf ファイルの FTPで指定したディレクトリーに、構築ログがあります。 7.3.4. 何を実行するのか バルクビルドは三つの段階からなります: 1. ビルド前 スクリプトがpkgsrcツリーを(anon)cvsで更新します。そして、壊れている distfileをすべて一掃し、インストールされているパッケージをすべて削除します 。 2. バルクビルド これは基本的に、“make bulk-package”を、パッケージの構築順序を最適化してお こなうものです。他のパッケージに依存しないパッケージが最初に構築され、多く の依存関係を持つパッケージは後に構築されます。 3. ビルド後 報告を作成し、build.confで指定されたディレクトリーに broken.html という名前 で置きます。あわせて、この報告の簡略版が構築管理者にメールで送られます。 構築中、壊れているパッケージの一覧が/usr/pkgsrc/.broken (OBJMACHINE が設定され ている場合は .../.broken.${MACHINE}) に作られ、構築が壊れているものの個々の構築 ログは、各パッケージのディレクトリーに置かれます。これらのファイルは、壊れてい るパッケージを再度構築しようとするような無駄をなくすために、bulk-ターゲットが構 築が壊れていることを記録するのに使われます。また、壊れているパッケージを後でデ バッグするためにも使えます。 7.3.5. 必要なディスク容量 現在、 NetBSD 2.0/i386 ではおおむね以下の容量が必要です: * 10 GB - distfile (NFSでも可) * 8 GB - 全バイナリー一式 (NFSでも可) * 5 GB - コンパイル用の一時領域 (ローカルディスクを推奨) 各パッケージは、バイナリーパッケージ作成直後にアンインストールされた上、ソース も削除されます。このため、莫大なディスク容量は必要ありません。後になって、この パッケージがまた必要となった場合は、再度構築することなく pkg_add(1) でインスト ールされるので、無駄な再コンパイルの繰り返しは発生しません。 7.3.6. chroot構築用の砂場を用意する バルクビルドによってパッケージを全部消される(マシンがパッケージのコンパイル以外 に無用なものになってしまう)のが嫌な場合は、chroot環境下でパッケージをバルクビル ドすることもできます。 最初にすることは、chrootされた砂場を、たとえば/usr/sandboxに用意することです。 これは null マウントを使って、または手動でおこなうことができます。 pkgsrc/mk/bulk/mksandbox というシェルスクリプトがあり、 null マウントを使った砂 場の環境を用意してくれます。このスクリプトは、砂場の環境のルートに sandbox とい うスクリプトも作ります。これは、sandbox mount コマンドで null マウントをした状 態にしたり、 sandbox umount コマンドでアンマウントした状態にしたりすることがで きるものです。 砂場の環境を手動で用意するには、 NetBSDのインストール配布物をすべて展開するか、 /usr/src/etcで make distribution DESTDIR=/usr/sandboxを実行した後、以下のものを 用意して適切に設定された状態にします。 1. カーネル # cp /netbsd /usr/sandbox 2. /dev/* # cd /usr/sandbox/dev ; sh MAKEDEV all 3. /etc/resolv.conf (security/smtpdおよびメール用): # cp /etc/resolv.conf /usr/sandbox/etc 4. 動作する(!)ようなメールの設定 (hostname, sendmail.cf): # cp /etc/mail/sendmail.cf /usr/sandbox/etc/mail 5. /etc/localtime (security/smtpd用): # ln -sf /usr/share/zoneinfo/UTC /usr/sandbox/etc/localtime 6. /usr/src (たとえば sysutils/aperture 用のシステムソース): # ln -s ../disk1/cvs . # ln -s cvs/src-2.0 src 7. /var/db/pkgを作成する(デフォルトのインストールには含まれません): # mkdir /usr/sandbox/var/db/pkg 8. /usr/pkgを作成する(デフォルトのインストールには含まれません): # mkdir /usr/sandbox/usr/pkg 9. cvs を使って、/usr/sandbox/usr/pkgsrc 内にpkgsrcをチェックアウトする: # cd /usr/sandbox/usr # cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -d -P pkgsrc この pkgsrc ツリーを、開発用の pkgsrc ツリーにマウントしたりリンクしたりし てはいけません。そういうことをすると問題を起こしがちだからです。 10. /usr/sandbox/usr/pkgsrc/packages と .../distfiles が、適切な場所を指すよう にする。これらは NFS や nullfs でマウントしておくと便利かもしれません。 11. mk.conf を編集する。Section 7.3.1.2, “mk.conf”参照。 12. mk/bulk/build.confを必要に合わせて調整する。 chroot砂場の用意ができれば、以下の手順で構築を開始できます: # cd /usr/sandbox/usr/pkgsrc # sh mk/bulk/do-sandbox-build このコマンドは、砂場内に移動して、構築を開始するものです。構築が終わると、構築 の結果がメールで送信されます。できあがったバイナリーパッケージは、 /usr/sandbox /usr/pkgsrc/packages (の指す/マウントされた先/元)に置かれます。 7.3.7. パッケージを部分的に構築する pkgsrc/mk/bulk/build スクリプトは、 pkgsrc の全パッケージの一式の構築のほか、 pkgsrc に含まれるパッケージの部分集合の構築にも使うことができます。 mk.conf で SPECIFIC_PKGS を定義すると、 * SITE_SPECIFIC_PKGS * HOST_SPECIFIC_PKGS * GROUP_SPECIFIC_PKGS * USER_SPECIFIC_PKGS の各変数で構築対象のパッケージを定義できるようになります。構築対象として定義さ れたパッケージの依存関係によって必要となるパッケージも、バルクビルドのコードが 構築対象に追加します。 この使い方のひとつに、サイトで必要なバイナリーパッケージをすべて用意するために 、 SPECIFIC_PKGS を使ったバルクビルドを chroot 環境で定期的に実行するというもの があります。こうすれば、不要なパッケージまで構築するような余計な負荷はかかりま せん。 7.3.8. バルクビルドの成果をアップロードする 本節では、pkgsrc 開発者がバルクビルドで構築したバイナリーパッケージを ftp.NetBSD.org へアップロードする方法を説明します。 アップロードしようとしているバイナリーパッケージのチェックサムファイルを自動生 成したい場合は、 mk/bulk/build.conf で MKSUMS=yes を忘れずに設定してください。 チェックサムファイルに PGP 署名をしたい場合 (そうすることを強くおすすめします) は、 mk/bulk/build.conf で SIGN_AS=username@NetBSD.org を忘れずに設定してくださ い。こうしておくと、ファイルをアップロードする前には常に、そのファイルに署名す るため、 GPG パスワードの入力を促すようになります。 次に、mk/bulk/build.conf ファイルで RSYNC_DST が適切に設定された状態にします。 つまり、この変数値を以下のような形式に調節します。 RSYNC_DST=ftp.NetBSD.org:/pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload このなかの "20xxQy" (枝), "a.b.c" (OS のバージョン), "arch" を、適切な値にして ください。 ftp.NetBSD.org でのログイン名がローカルのログイン名と異なる場合は、 そのログイン名を直接指定します。たとえば、筆者のローカルアカウントは "feyrer" ですが、ログイン名は "hubertf" なので、以下のようにします。 RSYNC_DST=hubertf@ftp.NetBSD.org:/pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload ここでは、アップロードの最中はディレクトリーを公開しないようにするため、独立し た upload ディレクトリーにアップロードします。そうするために、ftp.NetBSD.org で 以下のコマンドを実行しておきます。 nbftp% mkdir -p -m 750 /pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy/upload バイナリーパッケージをアップロードする前に、以下のような ssh の認証が必要となり ます。以下の例は、砂場内における root アカウント用の一時的な鍵を使うようにする 方法です。 (同じ鍵を常時使うことはしないものとします)。 # chroot /usr/sandbox chroot-# rm $HOME/.ssh/id-dsa* chroot-# ssh-keygen -t rsa chroot-# cat $HOME/.ssh/id-rsa.pub ここで出力した id-rsa.pub の内容を、 ftp.NetBSD.org の ~/.ssh/authorized_keys ファイルに追加します。パッケージのアップロードが終わったら、この鍵は削除してく ださい。 次に、ssh でうまく接続できることを確認します。 chroot-# ssh ftp.NetBSD.org date ここでは、適宜 "-l yourNetBSDlogin" を使ってください。 すべて順調にいけば、砂場から抜けて、アップロードを始めることができます。 chroot-# exit # cd /usr/sandbox/usr/pkgsrc # sh mk/bulk/do-sandbox-upload アップロードにはそれなりに時間がかかるかもしれません。 FTP サーバーで ls(1) や du(1) して、アップロードの過程を見てください。アップロード用スクリプトは、制限 つきのパッケージはアップロードしないように処理してくれます。 アップロードが終わった後に、最初にすることは、ssh でアクセスして以下のようにす ることです。 nbftp% vi ~/.ssh/authorized_keys Gdd:x! アップロード用に事前に追加しておいた鍵はすべて削除してください。最後に、アップ ロードしたパッケージを upload ディレクトリーの外に出して、公開された状態にしま す。 nbftp% cd /pub/pkgsrc/packages/NetBSD/arch/a.b.c-20xxQy nbftp% mv upload/* . nbftp% rmdir upload nbftp% chgrp -R netbsd . nbftp% find . -type d | xargs chmod 775 7.4. pbulk 方式のバルクビルドを実行する pbulk 方式のバルクビルドの実行の概要は、以下のとおりです。 * 最初に、まっさらな pkgsrc ツリー内で pbulk 基盤を構築する。 * 次に、この pbulk 基盤を使って、まっさらの pkgsrc ディレクトリーから個々のパ ッケージを構築する。 7.4.1. 事前準備 最初に、pbulk 基盤を作るための pkgsrc 基盤を作る必要があります。プラットフォー ムが何であっても (NetBSD であっても)、専用のディレクトリーを用意してそこに対し て bootstrap をしてください。このディレクトリーは /usr/pbulk または $HOME/pbulk としましょう。bootstrap すると、バルクビルドに必要なツールがインストールされま す。 $ cd /usr/pkgsrc $ ./bootstrap/bootstrap --prefix=/usr/pbulk --varbase=/usr/pbulk/var --workdir=/tmp/pbulk-bootstrap $ rm -rf /tmp/pbulk-bootstrap これで、pbulk 基盤のための基本的な環境がインストールされましたが、いくつかのツ ールはまだありません。ここで、pkgsrc の設定ファイル /usr/pbulk/etc/mk.conf を pbulk 向けに編集しましょう。ここでの典型的な設定内容は以下のとおりです。 * PKG_DEVELOPER=yes, より多くの整合性確認をするため * WRKOBJDIR=/tmp/pbulk-outer, /usr/pkgsrc にいかなる変更も加わらないようにす るため * DISTDIR=/distfiles, ダウンロードされた distfile (pbluk 基盤および構築するパ ッケージ用) を、すべて、ただひとつのデイレクトリーに置くようにするため * ACCEPTABLE_LICENSES+=..., 普及しているフリー/オープンソースライセンスのうち 許容できるものを追加するため * SKIP_LICENSE_CHECK=yes, ライセンスの検査を省略するため これで、pbulk 基盤の残りの部分を構築する準備ができました。 $ cd pkgtools/pbulk $ /usr/pbulk/bin/bmake install $ rm -rf /tmp/pbulk-outer これで、pbulk 基盤が構築・インストールされました。この基盤を設定したうえで、さ らなる準備が必要です。そうした後に、実際のバルクビルドを始めることができるよう になります。 7.4.2. 設定 TODO; さらなる情報は pkgsrc/doc/HOWTO-pbulk をご覧ください。 TODO: つづきを書く 7.5. CD-ROM複数枚に収めたパッケージコレクションの作成 pkgsrcのバルクビルド完了後、できあがったバイナリーパッケージからCD-ROMを作って 、他のマシンへのインストール用に使うことができます。 pkgtools/cdpackパッケージ に、そのようなISO 9660イメージ作成用の簡単なツールがあります。cdpackは、依存関 係が一枚のCD内で完結するように、パッケージを複数枚のCD-ROMに編集してくれます。 7.5.1. cdpackの使用例 cdpackの完全なドキュメンテーションはcdpack(1)マニュアルページにあります。以下の 短い例では、バイナリーパッケージが/usr/pkgsrc/packages/Allに置いてあり、ISO 9660イメージ用の十分なディスク容量が/u2にあるものとします。 # mkdir /u2/images # pkg_add /usr/pkgsrc/packages/All/cdpack # cdpack /usr/pkgsrc/packages/All /u2/images 各CDに共通ファイル(COPYRIGHT, README, など)を含めたい場合は、そのファイルを含む ディレクトリーを作る必要があります。たとえば以下のようにします。 # mkdir /tmp/common # echo "This is a README" > /tmp/common/README # echo "Another file" > /tmp/common/COPYING # mkdir /tmp/common/bin # echo "#!/bin/sh" > /tmp/common/bin/myscript # echo "echo Hello world" >> /tmp/common/bin/myscript # chmod 755 /tmp/common/bin/myscript ここで、以下のようにしてイメージを作成します。 # cdpack -x /tmp/common /usr/pkgsrc/packages/All /u2/images こうすると、各イメージのルートディレクトリーにREADME, COPYINGおよび bin/ myscriptが含まれるようになります。 Chapter 8. インストールされたファイルのディレクトリー配置 Table of Contents 8.1. ${LOCALBASE} 以下のファイルシステム配置 8.2. ${VARBASE} 以下のファイルシステム配置 pkgsrc を使ってインストールされたファイルは、ベースシステムの /usr ディレクトリ ー以下と似た配置で体系化されていますが、細かい点がいくらか異なっています。これ は、pkgsrc がもともと FreeBSD から派生したものであり、FreeBSD のファイルシステ ム階層に準じていたからです。その後は NetBSD の影響を大きく受けています。ただし 、pkgsrc をどのオペレーティングシステムで使っているかにかかわらず、 pkgsrc の配 置は同じになると思っていただいて結構です。 pkgsrc 用のルートディレクトリーは、主に四つあり、いずれも bootstrap/bootstrap スクリプトで設定可能です。 pkgsrc を root としてインストールした場合の、標準の 場所は以下のとおりです。 LOCALBASE= /usr/pkg PKG_SYSCONFBASE= /usr/pkg/etc VARBASE= /var PKG_DBDIR= /var/db/pkg 非特権モード (pkgsrc を root 以外のユーザーとしてインストールした場合) での、標 準の場所は以下のとおりです。 LOCALBASE= ${HOME}/pkg PKG_SYSCONFBASE= ${HOME}/pkg/etc VARBASE= ${HOME}/pkg/var PKG_DBDIR= ${HOME}/pkg/var/db/pkg この四つのディレクトリーの使用目的とその内容は、以下で説明します。 * LOCALBASE は、ベースシステムの /usr ディレクトリーに対応します。ファイルが インストールされる場所として“主たる”ディレクトリーであり、 bin, include, lib, share, sbin などのよく知られたサブディレクトリーがあります。 * VARBASE は、ベースシステムの /var に対応します。一部のプログラム (特に、ゲ ームとネットワークデーモン) は、通常の操作時に、このディレクトリーへの書き 込み権限を持っている必要があります。 * PKG_SYSCONFDIR は、ベースシステムの /etc に対応します。 pkgsrc 自体の設定フ ァイル mk.conf のほか、個々のパッケージの設定ファイルを含みます。 8.1. ${LOCALBASE} 以下のファイルシステム配置 pkgsrc を通常にインストールした場合、${LOCALBASE} 以下には以下のディレクトリー が存在します。 bin エンドユーザーが直接使うことを前提とした、実行形式のプログラムを含みます。 emul 特に NetBSD 用の、他の各種オペレーティングシステムのエミュレーション層用の ファイルを含みます。 etc (${PKG_SYSCONFDIR} の通常の場所) 設定ファイルを含みます。 include C および C++ プログラミング言語用のヘッダーを含みます。 info 各種パッケージの GNU info ファイルを含みます。 lib 静的共有ライブラリーを含みます。 libdata インストール後に変更されることがないデータファイルを含みます。変更されるこ とのあるデータファイルは ${VARBASE} 以下に置かれます。 libexec 補助プログラムやネットワークデーモンなど、エンドユーザーが直接使うことを前 提としないプログラムを含みます。 libexec/cgi-bin web サーバーが CGI スクリプトとして実行することを前提としたプログラムを含み ます。 man (${PKGMANDIR} の通常の値) マニュアルページ形式の短いドキュメンテーションを含みます。 sbin スーパーユーザーだけが使うことを前提としたプログラムを含みます。 share インストール後に変更されることがないプラットフォーム独立のデータファイルを 含みます。 share/doc パッケージに附属するドキュメンテーションファイルを含みます。 share/examples パッケージに附属する例ファイルを含みます。設定ファイルの原本も、インストー ル時にここに保存されたうえで ${PKG_SYSCONFDIR} へコピーされます。 share/examples/rc.d rc.d スクリプトファイルの原本を含みます。 var (${VARBASE} の通常の場所) インストール後に変更されることのあるファイルを含みます。 8.2. ${VARBASE} 以下のファイルシステム配置 db/pkg (${PKG_DBDIR} の通常の場所) 現在インストールされているパッケージに関する情報を含みます。 games 最高得点ファイルを含みます。 log ログファイルを含みます。 run 現在実行されているデーモンに関する情報ファイルを含みます。 Chapter 9. よくある質問 Table of Contents 9.1. pkgについて話しあうためのメーリングリストはありますか? 9.2. pkgviews のドキュメンテーションはどこにあるか? 9.3. パッケージ管理用ユーティリティー (pkgtools) 9.4. pkgsrc を root 以外で使う方法 9.5. distfile 取得時に、転送を再開する方法は? 9.6. pkgsrc の modular X.org をインストールあるいは使用する方法は? 9.7. 防火壁の内側からファイルを取得する方法 9.8. どうすればmake fetchでpassive FTPを使用することができますか? 9.9. 一度にすべてのdistfileを取得する方法 9.10. “Don't know how to make /usr/share/tmac/tmac.andoc”ってどういうこと? 9.11. “Could not find bsd.own.mk”ってどういうこと? 9.12. pkgsrcで'sudo'を使う 9.13. 設定ファイルの置き場所を変更する方法は? 9.14. 自動セキュリティーチェック 9.15. CFLAGS を無視するパッケージがあるのはなぜ? 9.16. パッケージが構築できません。どうすればいい? 9.17. “Makefile appears to contain unresolved cvs/rcs/??? merge conflicts”っ てどういうこと? この節では、pkgsrc の特別な事柄に関する助言、技巧や要領のうち、前章までに適当な 掲載場所がなかったものを掲載しています。ここでは、pkgsrc 利用者向けの情報と pkgsrc 開発者向けの情報を、どちらも掲載します。 9.1. pkgについて話しあうためのメーリングリストはありますか? pkgsrc の利用者向けに、以下のようなメーリングリストがあります。 * pkgsrc-users: pkgsrc 関連の話題のほとんどをプラットフォームにかかわらず扱う 汎用目的のメーリングリストです。たとえば、pkgsrc の設定に関する助けの要請、 予期しない構築失敗、個々のパッケージの使用、インストールした pkgsrc の更新 、pkgsrc リリース枝に関する質問などです。ここには、一般的なお知らせや、 pkgsrc 利用者コミュニティーに影響のある変更 (たとえば、大規模な基盤の変更、 新機能、パッケージ削除など) の提案も投稿されることがあります。 * pkgsrc-bulk: pkgsrc のバルクビルドの結果が送付され、その議論がおこなわれる メーリングリストです。 * pkgsrc-changes: pkgsrc のすべての変更についての commit メッセージが流れるメ ーリングリストです。毎日、 24 時間分のすべての commit メッセージをまとめて 送る、ダイジェスト版もあります。 参加するためには以下のようにして下さい。 % echo subscribe listname | mail majordomo@NetBSD.org 以上の各メーリングリストのアーカイブは http://mail-index.NetBSD.org/ から辿れま す。 9.2. pkgviews のドキュメンテーションはどこにあるか? pkgviews は buildlink に密接に統合されています。 pkgviews の利用者向けの手引き は pkgsrc/mk/buildlink3/PKGVIEWS_UG にあります。 9.3. パッケージ管理用ユーティリティー (pkgtools) pkgsrc/pkgtools ディレクトリー以下には、 pkgsrc の利用者および開発者それぞれに とって便利なユーティリティーがいくつもあります。この節の目的は、このユーティリ ティーの存在と、どんな場合に有用かを知っていただくことだけであり、各パッケージ の附属ドキュメントを引き写すことではありません。 pkgsrc が使用するユーティリティー (必要に応じて自動的にインストールされます): * pkgtools/x11-links: buildlink が使用するシンボリックリンクです。 OS ツールの拡張 (必要に応じて自動的にインストールされます): * pkgtools/digest: 各種チェックサム(SHA1 など) を計算します。 * pkgtools/libnbcompat: pkgsrc ツール用の互換ライブラリーです。 * pkgtools/mtree: BSD 以外のシステムにはネイティブの mtree がないため、これが インストールされます。 * pkgtools/pkg_install: /usr/sbin/pkg_install を最新版に置き換えます。または 、 pkg_install のないオペレーティングシステム用です。 pkgsrc が使用するユーティリティー (自動ではインストールされません): * pkgtools/pkg_tarup: インストールされているパッケージをもとに、バイナリーパ ッケージを作成します。 make replace が古いパッケージを保存するのに使います 。 * pkgtools/dfdisk: distfile を複数の場所から fetch できる機能を pkgsrc に追加 します。現在のところ、以下の方法に対応しています: 複数の CD-ROM および FTP/ HTTP のネットワーク接続。 * pkgtools/xpkgwedge: X11 パッケージの場所を変えます (標準で有効となります)。 * devel/cpuflags: お使いの CPU とコンパイラー用にコードを最適化するためのコン パイラーのフラグを考えてくれます。 インストールしたパッケージの追跡や最新への追従用などのユーティリティー: * pkgtools/pkg_chk: インストールされているパッケージのバージョンが pkgsrc の 最新バージョンと異なるものを報告します。 * pkgtools/pkgdep: パッケージ更新計画の策定を支援するため、パッケージの依存関 係のグラフを作成します。 * pkgtools/pkgdepgraph: pkgtools/pkgdep の出力をもとに (graphviz を使って) 図 表を作成します。 * pkgtools/pkglint: pkglint(1) プログラムは pkgsrc の個々のパッケージに誤りが ないか検査します。 * pkgtools/lintpkgsrc: lintpkgsrc(1) プログラムは pkgsrc システム全体に対して 各種の検査をおこないます。 * pkgtools/pkgsurvey: インストール済みのパッケージを報告します。 個々のパッケージの保守や作成をする人のためのユーティリティー: * pkgtools/pkgdiff: パッケージ用のパッチの作成や保守を自動化します (pkgdiff, pkgvi, mkpatches, ... が含まれます)。 * pkgtools/rpm2pkg, pkgtools/url2pkg: pkgsrc への変換の補助ツールです。 * pkgtools/gensolpkg: pkgsrc を Solaris パッケージに変換します。 pkgsrc を保守する人のためのユーティリティー (あるいは、もっと地味な pkg ユーテ ィリティー) * pkgtools/pkg_comp: chroot 領域でパッケージを構築します。 * pkgtools/libkver: chroot 環境でのクロス構築用に、カーネルのバージョンを誤魔 化します。 9.4. pkgsrc を root 以外で使う方法 pkgsrc を root 以外のユーザーで使いたい場合は、いくつかの変数を設定すれば、その ような環境で pkgsrc が動くようにすることができます。最低限、UNPRIVILEGED を“ yes”に設定することが必要です。こうすると非特権モードに切り替わり、関連のある複 数の変数が設定されて、 root 以外のユーザーがパッケージをインストールできるよう になります。 標準状態の非特権モードでは不十分な場合は、他の変数を調節するとよいでしょう。た とえば、ユーザーやグループの自動検出により正しくない (あるいは使いたくない) 値 が検出される場合は、それぞれ、 UNPRIVILEGED_USER や UNPRIVILEGED_GROUP を設定す れば変更することができます。 なお、ブートストラップについては、bootstrap スクリプトに“--ignore-user-check” フラグを与えると、標準で使われるインストール先が ~/pkg 以下の複数のディレクトリ ーになるため、非 root 用の構成にしやすくなることを覚えておいてください。このデ ィレクトリーは、他のディレクトリーの配置が細かく調節可能であるのと同様に、スク リプトに“--prefix”フラグを与えて上書きすることができます。 9.5. distfile 取得時に、転送を再開する方法は? 標準では、pkgsrc の転送再開機能は有効になっていませんが、 mk.conf にオプション PKG_RESUME_TRANSFERS=YES を追加すれば、この機能を有効にすることができます。こう すると、fetch している最中に、不完全な distfile があった場合、pkgsrc はそのファ イルの残りの部分を取得しようとします。 また、 FETCH_CMD 変数を変更すれば、標準である ftp(1) 以外のプログラムを使うこと もできます。この変数値を ftp, fetch, wget または curl にすると、指定したプログ ラムを使うことができます。このほか、変数値を manual にすると、取得をしないよう にすることができます。変数値を custom にすると、システム標準の設定を使わないよ うになり、取得プログラムに対する依存性も追わないようになります。この場合は、 FETCH_CMD, FETCH_BEFORE_ARGS, FETCH_RESUME_ARGS, FETCH_OUTPUT_ARGS, FETCH_AFTER_ARGS の各変数を設定する必要があります。 たとえば、ダウンロードに wget を使いたい場合は、以下のような設定が必要です。 FETCH_USING= wget 9.6. pkgsrc の modular X.org をインストールあるいは使用する方法は? システム附属の X11 (/usr/X11R6, /usr/openwin, ...) ではなく pkgsrc の modular X.org を使いたい場合は、mk.conf に以下の行を追加する必要があります。 X11_TYPE=modular Note DragonFly オペレーティングシステムは、標準で、この pkgsrc の modular X.org の X11 の実装を使います。 9.7. 防火壁の内側からファイルを取得する方法 もし、あなたが防火壁の内側にいて、インターネットのホストに直接接続できない (つ まりNATを使っていない)場合、適切なプロキシーホストを指定することができます。こ れはURL形式の環境変数で指定します。例えば、Amdahlドメインにおいては、“ orpheus.amdahl.com”というマシンは防火壁のひとつで、プロキシーポート番号として 、 80番のポートを使用します。この場合、proxy環境変数は以下のようになります。 ftp_proxy=ftp://orpheus.amdahl.com:80/ http_proxy=http://orpheus.amdahl.com:80/ 9.8. どうすればmake fetchでpassive FTPを使用することができますか? distfileの取得にどのユーティリティーを使っているかによります。 bsd.pkg.mkは、以 下のリストのなかで利用可能なコマンドのうち、最初のものをFETCH_CMDに割り当てま す: * ${LOCALBASE}/bin/ftp * /usr/bin/ftp NetBSD のデフォルトのインストールでは、/usr/bin/ftpとなり、これは自動的に、最初 はパッシブ接続を試みます。そして、サーバーがパッシブ接続を拒否した場合は、アク ティブ接続に切り替わります。これ以外のツールの場合は、 mk.confに以下の設定を追 加してください。 PASSIVE_FETCH=1 これを設定すると、 /usr/bin/ftp はアクティブ転送への切り替えをおこなわなくなり ます。 9.9. 一度にすべてのdistfileを取得する方法 make fetchを実行できない職場や大学において、一回のバッチ処理で、すべての distfileをダウンロードしたいと思うことがあるかもしれません。ftp.NetBSD.org に distfile が置かれていますが、このディレクトリーをまるごとダウンロードするのは不 適切です。 現時点では、make fetch-listを /usr/pkgsrcまたはそのサブディレクトリーで実行し、 その結果のリストを職場や学校のマシンに持ってきて、使用してくださいとしかいえま せん。 NetBSD と互換な ftp(1) (tnftpなど)が使えない場合は、 URLを指定して取得が できるコマンドを FETCH_CMDに指定することを忘れないでください: 自宅で: % cd /usr/pkgsrc % make fetch-list FETCH_CMD=wget DISTDIR=/tmp/distfiles >/tmp/fetch.sh % scp /tmp/fetch.sh work:/tmp 職場で: % sh /tmp/fetch.sh 実行後、 /tmp/distfiles を tar で固めて自宅に持って帰ります。 NetBSD で動いているマシンがあって、すべてのdistfile (そのマシンのアーキテクチャ ー向けではないものも含む)を取得したい場合は、上述のmake fetch-listの方法を使う か、以下のようにしてdistfileを直接取得することができます。 % make mirror-distfiles NO_{SRC,BIN}_ON_{FTP,CDROM} も無視したい場合は、以下のようにしてすべてのものを 取得することができます。 % make fetch NO_SKIP=yes 9.10. “Don't know how to make /usr/share/tmac/tmac.andoc”ってどういうこと? pkgtools/pkg_installパッケージのコンパイル時に、makeが /usr/share/tmac/ tmac.andoc の作り方がわからないというエラーを出します。これは、そのマシンに NetBSD の基本配布物の“text”セット(nroffなど) がインストールされていないことを 意味しています。マニュアルページの整形ができるようにするため、“text”セットを インストールしてください。 このpkgtools/pkg_installパッケージの事例は、環境変数かmk.confのどちらかで NOMAN =YESを設定して回避することもできます。 9.11. “Could not find bsd.own.mk”ってどういうこと? NetBSD のインストール時にコンパイラー一式comp.tgz をインストールしなかったから です。comp.tgzを入手し、 /で展開してインストールしてください: # cd / # tar --unlink -zxvpf .../comp.tgz comp.tgzは NetBSD のどのリリースにも含まれていますので、あなたがインストールし たリリース (uname -rで調べられます) に合ったものを入手してください。 9.12. pkgsrcで'sudo'を使う パッケージのインストールをroot以外のユーザーで実行し、 root権限が必要なところで はpkgsrcの su(1) 機能を使う場合、必要なパッケージをインストールするたびに root のパスワードを打つのは面倒かもしれません。これを避けるために、パスワードを一定 時間保持してくれるsudoパッケージを使うことができます。 sudoを使うには、sudoを (バイナリーパッケージ、またはsecurity/sudoのいずれかから) インストールしてから 、mk.conf の、 LOCALBASE 変数の定義より後の部分に、以下の内容を書いておきます。 .if exists(${LOCALBASE}/bin/sudo) SU_CMD= ${LOCALBASE}/bin/sudo /bin/sh -c .endif 9.13. 設定ファイルの置き場所を変更する方法は? システム管理者は、設定ファイルがインストールされる場所を選ぶことができます。標 準の設定では、設定ファイルはすべて ${PREFIX}/etc またはそのサブディレクトリー以 下にインストールされます。設定ファイルのインストール先は、あなたの都合 (たとえ ば、 NFS でエクスポートされた読み込み専用の PREFIX で、パッケージの設定をマシン 毎にする必要がある場合) にあわせて調整することができます。 標準の設定を変えるために、(mk.conf で) PKG_SYSCONFBASE 変数を、好みの設定用ディ レクトリーを指すように変えることができます。一般的な設定例としては、/etc や / etc/pkg などがあります。 さらに、PKG_SYSCONFDIR.${PKG_SYSCONFVAR} 変数を設定することで、パッケージ毎に設 定用ディレクトリーを変更することができます。 PKG_SYSCONFVAR の値は、通常は変更 対象のパッケージ名に合わせたもの、つまり、PKGBASE の値にします。 なお、この設定を変更した後は、影響を受けるパッケージをすべて再構築し、再インス トールする必要があります。 9.14. 自動セキュリティーチェック サードパーティーのソフトウェアにはしばしばバグがあること、そして、バグのなかに はマシンをアタッカーの攻撃に対して脆弱な状態にするものもあることに、どうか注意 してください。そのような攻撃にさらされることを減らすために、NetBSD パッケージチ ームでは、pkgsrc化されたことのあるパッケージに関する既知の攻撃のデータベースを 保守しています。このデータベースを自動的にダウンロードして、システムにインスト ールされている全パッケージのセキュリティー監査をおこなうことができます。これを おこなうには、以下の二つのツール (pkgtools/pkg_install パッケージの一部としてイ ンストールされます) を使います。 1. pkg_admin fetch-pkg-vulnerabilities: セキュリティー脆弱性情報のリストのダウ ンロードを簡単にできるようにするものです。この脆弱性情報のリストは、 pkgsrc セキュリティーチームが最新の状態に保っており、 NetBSD ftpサーバーで配布され ています。 ftp://ftp.NetBSD.org/pkgsrc/distfiles/pkg-vulnerabilities 2. pkg_admin audit: マシンの監査を簡単にできるようにするもので、既知の各脆弱性 の確認をします。脆弱性のあるパッケージがインストールされていた場合、そのこ とを標準出力に出力します。この出力には、脆弱性の種類の説明と詳細情報のURLが 含まれます。 これらのツールを使うよう強くおすすめします。“pkg_install”をインストールした後 に、パッケージのメッセージを読んでください。このメッセージは pkg_info -D pkg_install を実行すれば表示できます。 このパッケージをインストールすると、pkgsrc は各パッケージの構築前にこのパッケー ジを使ってセキュリティーのチェックをするようになります。このチェックを制御する 方法についてはSection 5.2, “構築の過程に影響を及ぼす変数”をご覧ください。 9.15. CFLAGS を無視するパッケージがあるのはなぜ? mk.conf で CFLAGS 変数に独自の設定をした場合、設定されたフラグは環境変数によっ て ./configure スクリプトに渡されてから make(1) に渡されます。パッケージの作者 によっては、環境変数で渡された CFLAGS を、パッケージの Makefile で上書きして、 無視するようにしていることがあります。 現在のところ、この問題の解決策はありません。独自の CFLAGS を使うことがどうして も必要な場合は、パッケージのディレクトリーで make patch を実行してから、 Makefile と Makefile.in をすべて調べて、 CFLAGS を明示的に定義していないかを調 べてください。ふつうは、その部分を削除することができます。ただし、一部の“小賢 しい”プログラマーは、彼らが選んだ特定の CFLAGS の組合せのもとでしか動作しない ような、まずいコードを書いていることに注意してください。 9.16. パッケージが構築できません。どうすればいい? 1. 使っている pkgsrc ツリーの一貫性を確認します。この問題の原因としてありがち なのは、時間などを節約するために pkgsrc の一部だけを更新していたというもの です。 pkgsrc は小さなシステムの寄せ集めではなく、ひとつの大きなシステムで すので、 pkgsrc ツリー全体を更新しておかないと動かなくなるような変更が時々 おこなわれます。 2. CVS の衝突が起きていないことを確認します。 pkgsrc のファイルすべてについて 、“<<<<<<”や“>>>>>>”という文字列を検索します。 3. 古いパッケージが展開されていないことを確認します。これを確認するには、make clean clean-depends を実行します。 4. 以上の確認をおこなってもなお問題がある場合は、 pkgsrc-users メーリングリス トにメールを出してください。 9.17. “Makefile appears to contain unresolved cvs/rcs/??? merge conflicts”っ てどういうこと? あなたが pkgsrc のファイルに変更を加えており、かつ、他の誰かが CVS リポジトリー において同じファイルに変更を加えています。この変更がいずれもファイル内の同じ箇 所に対するものであるため、あなたが pkgsrc を更新したときに、変更が衝突したとい う印を cvs コマンドがファイルにつけたのです。この印があるために、ファイルが妥当 な Makefile ではなくなっています。 ファイルの内容を見てください。あなたが独自に加えた変更がもはや不要であれば、フ ァイルを削除してからそのディレクトリーで cvs -q update -dP を実行し、最新版のフ ァイルをダウンロードすることができます。 Part II. pkgsrc 開発者向けの手引き この部では、パッケージの作成や変更を扱います。新しいパッケージを作る“HOWTO”的 な手引きから始めます。その後の章は、 pkgsrc のリファレンスマニュアルに近いもの になっています。 Table of Contents 10. 新しいパッケージを一から作る 10.1. ありがちな種類のパッケージ 10.1.1. Perl モジュール 10.1.2. KDE アプリケーション 10.1.3. Python モジュールおよびプログラム 10.2. 例 10.2.1. www/nvu パッケージはいかに pkgsrc に追加されたか 11. パッケージコンポーネント - ファイル、ディレクトリー、およびコンテンツ 11.1. Makefile 11.2. distinfo 11.3. patches/* 11.3.1. 個々のパッチファイルの構造 11.3.2. パッチファイルを作成する 11.3.3. パッチファイルの出どころ 11.3.4. パッチ作成の指針 11.3.5. 作者へのフィードバック 11.4. その他の必須のファイル 11.5. オプションのファイル 11.5.1. バイナリーパッケージに影響をおよぼすファイル 11.5.2. 構築の過程に影響をおよぼすファイル 11.5.3. 何の影響もおよぼさないファイル 11.6. work* 11.7. files/* 12. Makefile におけるプログラミング 12.1. 警告 12.2. Makefile 変数 12.2.1. 命名規約 12.3. コードの断片 12.3.1. リストに要素を追加する 12.3.2. 内部リストを外部リストに変換する 12.3.3. シェルコマンドに値を渡す 12.3.4. クォートの指針 12.3.5. BSD Make のバグの回避方法 13. PLIST 問題 13.1. RCS ID 13.2. PLIST の半自動生成 13.3. make print-PLIST の出力を細工する 13.4. PLIST における各種の置換 13.5. マニュアルページの圧縮 13.6. PLIST_SRC を使って PLIST のソースを変更する 13.7. プラットフォーム別に異なるPLIST 13.8. 複数のパッケージでディレクトリーを共有する 14. buildlink 方法論 14.1. パッケージを変換して buildlink3 を使うようにする 14.2. buildlink3.mk ファイルを書く 14.2.1. buildlink3.mk ファイルの分析 14.2.2. buildlink3.mk ファイルの BUILDLINK_API_DEPENDS.pkg を更新する 14.3. builtin.mk ファイルを書く 14.3.1. builtin.mk ファイルの分析 14.3.2. ネイティブおよび pkgsrc のソフトウェアの選択に関する、大域的な 設定 15. pkginstall の枠組 15.1. インストール用のプレフィックス以外の場所にあるファイルとディレクトリ ー 15.1.1. ディレクトリーの操作 15.1.2. ファイルの操作 15.2. 設定ファイル 15.2.1. PKG_SYSCONFDIR はどのように設定されるか 15.2.2. ソフトウェアに設定ファイルの置き場所を教える 15.2.3. インストールの過程を修正する 15.2.4. 設定ファイルの処理をしないようにする 15.3. システム起動スクリプト 15.3.1. システム起動スクリプトの処理をしないようにする 15.4. システムユーザーとグループ 15.5. システムシェル 15.5.1. シェルの登録をしないようにする 15.6. フォント 15.6.1. フォントデータベースの自動更新をしないようにする 16. オプションの扱い 16.1. 標準の大域的なオプション 16.2. パッケージを変換して bsd.options.mk を使うようにする 16.3. オプション名 16.4. 依存パッケージのオプションを判別する 17. 構築の手順 17.1. 序 17.2. プログラムの場所 17.3. 構築の過程で使われるディレクトリー 17.4. 相の実行 17.5. fetch 相 17.5.1. 何を、どこから取得するか 17.5.2. ファイルの取得はどのようにおこなわれるか? 17.6. checksum 相 17.7. extract 相 17.8. patch 相 17.9. tools 相 17.10. wrapper 相 17.11. configure 相 17.12. build 相 17.13. test 相 17.14. install 相 17.15. package 相 17.16. 掃除をする 17.17. 他の役に立つターゲット 18. 構築や実行のために必要なツール 18.1. pkgsrc 構築用のツール 18.2. パッケージが必要とするツール 18.3. プラットフォーム附属のツール 18.4. ツールに関する質問 19. パッケージを動くようにする 19.1. 一般的な操作 19.1.1. パッケージの移植性 19.1.2. mk.conf から利用者が設定可能な変数を捕まえる方法 19.1.3. ユーザーとの対話 19.1.4. ライセンスの処理 19.1.5. 制限つきパッケージ 19.1.6. 依存性の処理 19.1.7. 他のパッケージとの衝突の処理 19.1.8. 構築することができない、あるいはすべきでないパッケージ 19.1.9. 一旦インストールしたら削除すべきでないパッケージ 19.1.10. セキュリティー問題を持つパッケージへの対処 19.1.11. 既存パッケージ修正時に、バージョンを上げるにはどうするか 19.1.12. パッケージのファイル中の各種テキストを置換する (SUBST の枠組) 19.2. fetch 相での問題を修正する 19.2.1. distfileのダウンロードが単純にできないパッケージ 19.2.2. '古い'名前のまま更新されたdistfileの取り扱い 19.3. configure 相での問題を修正する 19.3.1. 共有ライブラリー - libtool 19.3.2. すでにlibtoolをサポートしているGNUパッケージでlibtoolを使う 19.3.3. GNU Autoconf/Automake 19.4. プログラミング言語 19.4.1. C, C++ および Fortran 19.4.2. Java 19.4.3. perl スクリプトを含むパッケージ 19.4.4. 他のプログラミング言語 19.5. build 相での問題を修正する 19.5.1. C および C++ のコードの条件つきコンパイル 19.5.2. コンパイラーのバグへの対処方法 19.5.3. undefined reference to “...” 19.5.4. メモリーが不足する 19.6. install 相での問題を修正する 19.6.1. 必要なディレクトリーを作成する 19.6.2. ドキュメンテーションのインストール場所 19.6.3. 最高得点ファイルをインストールする 19.6.4. パッケージを DESTDIR に対応させる 19.6.5. その他のインタープリターへのパスがハードコードされているパッケ ージ 19.6.6. perl モジュールをインストールするパッケージ 19.6.7. infoファイルをインストールするパッケージ 19.6.8. マニュアルページをインストールするパッケージ 19.6.9. GConf のデータファイルをインストールするパッケージ 19.6.10. scrollkeeper/rarian のデータファイルをインストールするパッケー ジ 19.6.11. X11 のフォントをインストールするパッケージ 19.6.12. GTK2 のモジュールをインストールするパッケージ 19.6.13. SGML または XML のデータをインストールするパッケージ 19.6.14. MIME データベースの拡張をインストールするパッケージ 19.6.15. intltool を使うパッケージ 19.6.16. 起動スクリプトをインストールするパッケージ 19.6.17. TeX モジュールをインストールするパッケージ 19.6.18. エミュレーションによるバイナリーの実行に対応したパッケージ 19.6.19. ハイカラーテーマのアイコンをインストールするパッケージ 19.6.20. デスクトップファイルをインストールするパッケージ 19.7. パッケージに問題があるという印をつける 20. デバッグ 21. 提出およびコミット 21.1. バイナリーパッケージの提出 21.2. ソースパッケージの提出 (NetBSD 開発者以外の方向け) 21.3. パッケージを追加・更新・削除する際の一般的な覚書 21.4. コミット: パッケージのCVSへのインポート 21.5. パッケージを新しいバージョンに更新する 21.6. pkgsrc のパッケージの名前を変更する 21.7. pkgsrcのパッケージを移動する 22. よくある質問 23. GNOME のパッケージングおよび移植 23.1. メタパッケージ 23.2. GNOME アプリケーションをパッケージングする 23.3. GNOME を新バージョンに更新する 23.4. 修正の指針 Chapter 10. 新しいパッケージを一から作る Table of Contents 10.1. ありがちな種類のパッケージ 10.1.1. Perl モジュール 10.1.2. KDE アプリケーション 10.1.3. Python モジュールおよびプログラム 10.2. 例 10.2.1. www/nvu パッケージはいかに pkgsrc に追加されたか あなたが pkgsrc にまだ入っていないパッケージを見つけた場合、たいていはソースコ ードをどの URL からダウンロードできるかわかっているでしょう。この URL をもとに して、いくつかの段階を踏むだけでパッケージを作成することができます。 1. 最初に、pkgtools/url2pkg および pkgtools/pkglint の両パッケージをインストー ルします。 2. 次に、そのパッケージの属するカテゴリーとして、最上層のディレクトリーをひと つ選びます。既存のもののかわりに、専用のディレクトリー (local など) を作っ てもかまいません。このカテゴリーのディレクトリーの下に、パッケージ用にもう ひとつディレクトリーを作り、その中に移動します。 3. プログラム url2pkg を実行します。実行すると URL をたずねてきます。配布ファ イル (たいていは .tar.gz ファイルです)の URL を入力して、パッケージの基本的 な要素が自動的に作られてゆくようすを観察します。配布ファイルは自動的に展開 され、 Makefile の詳しい内容の一部を自動的に書いてくれますが、残りは手動で やる必要があるでしょう。 4. パッケージの依存性を判断するため、展開されたファイルを調べます。 README の ようなファイルに依存性について書かれているのが理想的ですが、実際はそうなっ ていないこともあります。それぞれの依存先について、それが pkgsrc のどこにあ るかを調べて、依存先のディレクトリーに buildlink3.mk というファイルがある場 合はそれを Makefile の最後の行の直前でインクルードします。依存先に buildlink3.mk がない場合は、このファイルをまず作ります。buildlink3.mk ファ イルは、依存先パッケージのインクルードファイルとライブラリーが確実に用意さ れるようにするためのものです。 単に、あるパッケージに含まれるバイナリーが必要なだけならば、依存するバージ ョンと pkgsrc における場所を指定する DEPENDS 行を Makefile に追加します。こ の行は 3 番目の段落に書くようにします。依存性がパッケージを構築するためだけ に必要で、使用するためには必要ない場合は、 DEPENDS ではなく BUILD_DEPENDS を使います。これにより、作成中のパッケージは以下のようになるでしょう。 [...] BUILD_DEPENDS+= lua>=5.0:../../lang/lua DEPENDS+= screen-[0-9]*:../../misc/screen DEPENDS+= screen>=4.0:../../misc/screen [...] .include "../../category/package/buildlink3.mk" .include "../../devel/glib2/buildlink3.mk" .include "../../mk/bsd.pkg.mk" 5. パッケージを“使い物”にするにはあと何をする必要があるかを確認するため、 pkglint を実行します。 pkglint のメッセージの意味がわからない場合は、追加説 明を出力してくれる pkglint --explain または pkglint -e を試してみてください 。 6. 多くの場合、パッケージはまだ構築できるようにはなっていません。もっともあり がちな場合については、次の節Section 10.1, “ありがちな種類のパッケージ”で 説明しています。この説明に従えば、おそらく先に進めるでしょう。 7. bmake clean を実行して、作業ディレクトリーから展開されたファイルを掃除しま す。作業ディレクトリーには、展開されたファイルのほかにも、キャッシュファイ ルその他のシステム情報が置かれており、これらが残っていると Makefile 編集後 に悪影響のあることがあります。 8. ここで、bmake を実行してパッケージを構築します。この段階では、さまざまな要 因により構築がうまくいかないことがありますので、Chapter 19, パッケージを動 くようにするを調べてください。 9. パッケージがうまく構築できた場合、次にすることは、パッケージのインストール です。bmake install を実行して、うまくいくようお祈りします。 10. ここに至るまで、パッケージがインストールしたファイルの一覧を内容にもつ PLIST ファイルの内容は、ほとんど空でした。bmake print-PLIST >PLIST を実行し て、おそらく正しいであろう一覧を作成します。作成したファイルを、お好きなテ キストエディターを使って、ファイルの一覧がそれらしいものになっているか確認 します。 11. 再度 pkglint を実行して、作成した PLIST に余計なものが含まれていないか調べ ます。 12. さきほど bmake install を実行した時に、インストールされたファイルのデータベ ースにこのパッケージが登録されましたが、ファイルの一覧は空のものが登録され ています。これを修正するため、 bmake deinstall を実行してから bmake install を再度実行します。これで、このパッケージは PLIST のファイルの一覧とともに登 録されます。 13. bmake package を実行して、インストールされたファイル一式からバイナリーパッ ケージを作成します。 10.1. ありがちな種類のパッケージ 10.1.1. Perl モジュール 簡単な Perl モジュールは、url2pkg を使って、依存性も含めて自動的に処理すること ができます。 10.1.2. KDE アプリケーション KDE アプリケーションは、かならず meta-pkgs/kde3/kde3.mk をインクルードしてくだ さい。これには、KDE パッケージでよくある設定が多数含まれています。 10.1.3. Python モジュールおよびプログラム Python のモジュールとプログラムは、あらかじめ用意された変数を使って、簡単にパッ ケージを作ることができます。 ほとんどの Python パッケージは、“distutils”または easy-setup (“eggs”) のい ずれかを使っています。ソフトウェアが“distutils”を使っている場合は、 pkgsrc が この枠組を使うようにするため、 PYDISTUTILSPKG 変数を“yes”に設定します。“ distutils”では、setup.py という名前のスクリプトを使いますが、“distutils”ドラ イバーが setup.py という名前でない場合は、 PYSETUP 変数をスクリプト名に設定しま す。 ソフトウェアが既定の Python バージョンに対応していない場合は、 PYTHON_VERSIONS_ACCEPTED 変数を、そのソフトウェアが動作する Python バージョンに 設定します。バージョンは新しいものから古いものの順に並べます。たとえば以下のよ うにします。 PYTHON_VERSIONS_ACCEPTED= 25 24 パッケージにするソフトウェアが Python モジュールである場合は、“../../lang/ python/extension.mk”をインクルードします。この場合は、パッケージのディレクトリ ー名を“py-software”という形式にし、 PKGNAME を“${PYPKGPREFIX}-${DISTNAME}” に設定します。たとえば以下のようにします。 DISTNAME= foopymodule-1.2.10 PKGNAME= ${PYPKGPREFIX}-${DISTNAME} パッケージにするソフトウェアがアプリケーションである場合は、“extension.mk”を インクルードする前に“../../lang/python/application.mk”もインクルードします。 パッケージにするソフトウェア (アプリケーションでもモジュールでも) が egg に対応 している場合、必要なことは、“../../lang/python/egg.mk”をインクルードすること だけです。 Python インタープリターへのパスを適切に設定するために、 REPLACE_PYTHON 変数を使 います。この変数に、パスの修正が必要なファイルのリストを設定します。たとえば以 下のようにします。 REPLACE_PYTHON= ${WRKSRC}/*.py 10.2. 例 10.2.1. www/nvu パッケージはいかに pkgsrc に追加されたか 10.2.1.1. 作り始めのパッケージ 私は pkgsrc/doc/TODO ファイルを見て、“nvu”パッケージが pkgsrc にまだ入ってい ないことに気づきました。 web 用に使うものと説明されているので、カテゴリーの選択 は明らかに“www”です。 $ mkdir www/nvu $ cd www/nvu web サイトによれば、ソースは tar ファイルの形で用意されているので、その URL を url2pkg プログラムに与えます。 $ url2pkg http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2 エディターが立ち上がりますので、DISTNAME の行の前に PKGNAME の行を追加します。 パッケージ名に“sources”という単語は含めないものだからです。さらに、 MAINTAINER, HOMEPAGE, COMMENT の各行を記載します。これにより、パッケージの Makefile は以下のようになります。 # $NetBSD$ # DISTNAME= nvu-1.0-sources PKGNAME= nvu-1.0 CATEGORIES= www MASTER_SITES= http://cvs.nvu.com/download/ EXTRACT_SUFX= .tar.bz2 MAINTAINER= rillig@NetBSD.org HOMEPAGE= http://cvs.nvu.com/ COMMENT= Web Authoring System # url2pkg-marker (please do not remove this line.) .include "../../mk/bsd.pkg.mk" ここで、エディターを終了し、 pkgsrc が大きなソースアーカイブをダウンロードする のを観察します。 url2pkg> Running "make makesum" ... => Required installed package digest>=20010302: digest-20060826 found => Fetching nvu-1.0-sources.tar.bz2 Requesting http://cvs.nvu.com/download/nvu-1.0-sources.tar.bz2 100% |*************************************| 28992 KB 150.77 KB/s00:00 ETA 29687976 bytes retrieved in 03:12 (150.77 KB/s) url2pkg> Running "make extract" ... => Required installed package digest>=20010302: digest-20060826 found => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2 => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2 work.bacc -> /tmp/roland/pkgsrc/www/nvu/work.bacc ===> Installing dependencies for nvu-1.0 ===> Overriding tools for nvu-1.0 ===> Extracting for nvu-1.0 url2pkg> Adjusting the Makefile. Remember to correct CATEGORIES, HOMEPAGE, COMMENT, and DESCR when you're done! Good luck! (See pkgsrc/doc/pkgsrc.txt for some more help :-) 10.2.1.2. パッケージを機能するようにするための多くの問題を修正する これで、パッケージが展開されたので、その内容を見ていきましょう。このパッケージ には README.txt がありますが、 mozilla に関することしか書かれていませんので、お そらく、パッケージの依存性を調べるための役には立たないでしょう。しかし、パッケ ージに GNU configure スクリプトがあるので、必要なものについて逐一文句を言ってく れることを期待しましょう。 $ bmake => Required installed package digest>=20010302: digest-20060826 found => Checksum SHA1 OK for nvu-1.0-sources.tar.bz2 => Checksum RMD160 OK for nvu-1.0-sources.tar.bz2 ===> Patching for nvu-1.0 ===> Creating toolchain wrappers for nvu-1.0 ===> Configuring for nvu-1.0 [...] configure: error: Perl 5.004 or higher is required. [...] WARNING: Please add USE_TOOLS+=perl to the package Makefile. [...] うまく文句を言ってくれました。そこで、パッケージの Makefile をエディターで開き 、USE_TOOLS 行がすでにあったので、そこに“perl”を追加します。これによりパッケ ージの依存性が変更されたこと、また、perl のラッパーが“tools”相で自動的にイン ストールされることから、パッケージの構築を最初からやり直すことが必要になりまし た。 $ bmake clean ===> Cleaning for nvu-1.0 $ bmake [...] *** /tmp/roland/pkgsrc/www/nvu/work.bacc/.tools/bin/make is not \ GNU Make. You will not be able to build Mozilla without GNU Make. [...] そこで、“gmake”を USE_TOOLS 行に追加して、もう一度 (最初から) やり直します。 [...] checking for GTK - version >= 1.2.0... no *** Could not run GTK test program, checking why... [...] 今度は別の依存性です。最初の問題は、「GTK のパッケージは pkgsrc のどこに隠され ているか?」です。 $ echo ../../*/gtk* [many packages ...] $ echo ../../*/gtk ../../x11/gtk $ echo ../../*/gtk2 ../../x11/gtk2 $ echo ../../*/gtk2/bui* ../../x11/gtk2/buildlink3.mk 最初の結果は、明らかに多すぎです。二つ目は、ただひとつの結果が出ており、非常に みごとです。しかし、ここには GNOME パッケージに関する罠があります。 GNOME 2 が リリースされる前から、pkgsrc にはすでに多数の GNOME 1 パッケージがありました。 そのような GNOME 1 パッケージをそのまま使い続けることができるようにするために、 GNOME 2 パッケージはそれらとは別のパッケージとして導入されており、通常はパッケ ージ名に“2”が付け加えられています。このため、gtk がこれに該当するかを確認した ところ、実際に該当していました。 GTK2 パッケージには buildlink3.mk があるので、依存性の追加は非常に簡単です。パ ッケージの Makefile の最後の行の直前に .include 行を追加します。これにより以下 のようになりました。 [...] .include "../../x11/gtk2/buildlink3.mk" .include "../../mk/bsd.pkg.mk 改めて bmake clean && bmake を実行すると、以下のようになりました。 [...] checking for gtk-config... /home/roland/pkg/bin/gtk-config checking for GTK - version >= 1.2.0... no *** Could not run GTK test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means GTK was incorrectly installed *** or that you have moved GTK since it was installed. In the latter case, you *** may want to edit the gtk-config script: /home/roland/pkg/bin/gtk-config configure: error: Test for GTK failed. [...] この事例では、“どのパッケージも GNOME 2 を好む”との仮定は誤りでした。上のエラ ーメッセージの最初のほうの行から、このパッケージは実際には GNOME 1 バージョンの GTK を必要としていることがわかります。もしこのパッケージが GTK2 を探していたな ら、gtk-config ではなく pkg-config を探していたでしょう。そこで、パッケージの Makefile 中の x11/gtk2 を x11/gtk に書き換えてから、またやり直します。 [...] cc -o xpidl.o -c -DOSTYPE=\"NetBSD3\" -DOSARCH=\"NetBSD\" -I../../../dist/include/xpcom -I../../../dist/include -I/tmp/roland/pkgsrc/www/nvu/work.bacc/mozilla/dist/include/nspr -I/usr/X11R6/include -fPIC -DPIC -I/home/roland/pkg/include -I/usr/include -I/usr/X11R6/include -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pedantic -O2 -I/home/roland/pkg/include -I/usr/include -Dunix -pthread -pipe -DDEBUG -D_DEBUG -DDEBUG_roland -DTRACING -g -I/home/roland/pkg/include/glib/glib-1.2 -I/home/roland/pkg/lib/glib/include -I/usr/pkg/include/orbit-1.0 -I/home/roland/pkg/include -I/usr/include -I/usr/X11R6/include -include ../../../mozilla-config.h -DMOZILLA_CLIENT -Wp,-MD,.deps/xpidl.pp xpidl.c In file included from xpidl.c:42: xpidl.h:53:24: libIDL/IDL.h: No such file or directory In file included from xpidl.c:42: xpidl.h:132: error: parse error before "IDL_ns" [...] パッケージの依存先が、まだ全部は見つかっていません。ここでの問題は「ヘッダーフ ァイル libIDL/IDL.h はどのパッケージが提供しているのか?」です。 $ echo ../../*/*idl* ../../devel/py-idle ../../wip/idled ../../x11/acidlaunch $ echo ../../*/*IDL* ../../net/libIDL 二つ目で見つかったものを試してみましょう。そこで、 ../../net/libIDL/ buildlink3.mk ファイルをインクルードしてから、またやり直します。しかし、エラー はさきほどと変わりません。コードをいくらか調べたすえ、パッケージの構築の過程が 壊れているせいで機能しないという結論に達しました。しかし、Mozilla のソースツリ ーは非常に巨大なので、修正する気にはなりません。そこで、パッケージの Makefile に以下の内容を追加して、またやり直します。 CPPFLAGS+= -I${BUILDLINK_PREFIX.libIDL}/include/libIDL-2.0 BUILDLINK_TRANSFORM+= -l:IDL:IDL-2 パッケージ側では libIDL.so というライブラリーを期待していますが、実際には libIDL-2.so だけが利用可能なので、下の行が必要です。これにより、コンパイラーの ラッパーにその場で書き換えをするよう伝えます。 次の問題は、FreeType インターフェースの最近の変更に関するものです。 www/ seamonkey のパッチファイルがこの問題に対処しているので、これを patches ディレク トリーにコピーします。そして、はじめからやり直し、パッチをきれいに適用できるよ う修正して、またやり直します。これで、すべてうまくいきました。 10.2.1.3. パッケージをインストールする $ bmake CHECK_FILES=no install [...] $ bmake print-PLIST >PLIST $ bmake deinstall $ bmake install Chapter 11. パッケージコンポーネント - ファイル、ディレクトリー、およびコンテン ツ Table of Contents 11.1. Makefile 11.2. distinfo 11.3. patches/* 11.3.1. 個々のパッチファイルの構造 11.3.2. パッチファイルを作成する 11.3.3. パッチファイルの出どころ 11.3.4. パッチ作成の指針 11.3.5. 作者へのフィードバック 11.4. その他の必須のファイル 11.5. オプションのファイル 11.5.1. バイナリーパッケージに影響をおよぼすファイル 11.5.2. 構築の過程に影響をおよぼすファイル 11.5.3. 何の影響もおよぼさないファイル 11.6. work* 11.7. files/* パッケージを用意する際にはいつも、以下のセクションで述べられている多くのファイ ルが存在します。 11.1. Makefile 構築、インストールおよびバイナリーパッケージの作成は、すべてパッケージの Makefileによりコントロールされます。 Makefile には、パッケージに関するさまざま な情報が記述されています。たとえば、パッケージをどこで取得するか、パッケージを どのように構成、構築、インストールするか、などです。 パッケージの Makefile は、当該パッケージについて記述した、複数の節からなってい ます。 最初の節には、以下に掲げる変数を書きます。これらは以下に掲げたままの順で並べる ようにします。このような変数の順序や節へのまとめ方は、ほとんど歴史的なものであ って、それ以上の意味はありません。 * DISTNAME は、当該パッケージの web サイトからダウンロードされる配布ファイル の基礎となる名前です。 * PKGNAME は、 pkgsrc が使うパッケージ名です。これは、 DISTNAME (標準での値) が pkgsrc におけるパッケージ名としてふさわしくない場合のみ書く必要がありま す。通常、これはディレクトリー名とバージョン番号を合わせたものになります。 この値は正規表現 ^[A-Za-z0-9][A-Za-z0-9-_.+]*$ にマッチする必要があります。 すなわち、使える文字は、アルファベット・数字・マイナス記号・下線・ピリオド ・プラス記号だけであり、また、最初の文字はアルファベットまたは数字である必 要があります。 * SVR4_PKGNAME は、 PKGNAME が SVR4 のシステムにおいて一意なものにならない場 合に、パッケージファイルを作成する際に使う名前です。標準では PKGNAME であり 、これの短縮は pkgtools/gensolpkg を使っておこなうことができます。 SVR4_PKGNAME を使うのは、SVR4 のシステムで PKGNAME から一意なパッケージ名が 得られない場合だけです。 SVR4_PKGNAME の長さの上限は 5 文字です。 * CATEGORIES は、当該パッケージにふさわしいカテゴリーのリストです。 pkgsrc の 最上層にあるディレクトリーから自由に選ぶことができます。 現在CATEGORIESの値として以下が使用できます。もし複数にまたがる場合、それら の値はスペースで分けられる必要があります: archivers cross geography meta-pkgs security audio databases graphics misc shells benchmarks devel ham multimedia sysutils biology editors inputmethod net textproc cad emulators lang news time chat finance mail parallel wm comms fonts math pkgtools www converters games mbone print x11 * MASTER_SITES, DYNAMIC_MASTER_SITES, DIST_SUBDIR, EXTRACT_SUFX, DISTFILES の 各変数については、 Section 17.5, “fetch 相”で詳しく論じます。 二つ目の節には、別途ダウンロードするパッチがある場合に、そのパッチに関する情報 を書きます。 * PATCHFILES: 配布されているパッチを含んでいる、追加ファイルのファイル名です 。標準の値はありません。pkgsrc はこのファイルを PATCH_SITES から探します。 ファイル名の末尾が .gz または .Z の場合は、パッチ適用前に自動的に伸長されま す。 * PATCH_SITES: 配布されているパッチファイル (上述の PATCHFILES を参照) がロー カルにない場合用の、主な配布場所です。 三つ目の節には、以下に掲げる変数を書きます。 * MAINTAINER は、当該パッケージの担当者であることを自覚しており、 send-pr(1) を使って報告された問題や質問の面倒をもっともよく見そうな人の電子メールアド レスです。他の開発者がパッケージに変更を加える際には、事前に MAINTAINER に 連絡してもかまいませんが、必ずしも連絡する必要はありません。新しいプログラ ムをパッケージ化する場合は、 MAINTAINER をあなた自身に設定してください。そ のパッケージを将来の更新に応じて保守することがどうしてもできない場合は、 < pkgsrc-users@NetBSD.org> に設定します。 * OWNER は、他の開発者に無断でパッケージを更新されたり変更されたりしたくない 場合に、 MAINTAINER のかわりに使うものです。パッケージの Makefile には、 MAINTAINER または OWNER のいずれか一方を含めるようにしますが、両方書いては いけません。 * HOMEPAGE は、当該パッケージについて、利用者がより詳しい情報を得られる URL です。 * COMMENT は、当該パッケージについての一行説明です (パッケージ名は含めません) 。 このほか、構築に影響のある変数としては、以下のものがあります。 * WRKSRC: 当該パッケージに関連する配布ファイルが置かれるディレクトリーです。 標準では ${WRKDIR}/${DISTNAME} になり、ほとんどのパッケージはこの標準状態の ままで動作します。 パッケージが専用のサブディレクトリー (たとえば、ほとんどのGNUソフトウェアは これを作ります) を作らずに、カレントディレクトリーに展開される場合、 WRKSRC =${WRKDIR} を設定します。 パッケージが DISTNAME と同名のサブディレクトリーは作らずに、別の名前のサブ ディレクトリーを作る場合は、 WRKSRC を設定して、 ${WRKDIR} 内の適切な名前を 指すようにします。たとえば WRKSRC=${WRKDIR}/${DISTNAME}/unix のようにします 。さらに別の例としては lang/tcl と x11/tk を見てください。 pkgsrc が作成する作業用ディレクトリーの名前には、 WRKDIR_BASENAME 変数が使 われます。この値は、標準では work です。同じ pkgsrc ツリーを複数の異なる種 類のバイナリーパッケージの構築用に使いたい場合は、必要に応じて、この変数の 値を変えることができます。 WRKDIR_BASENAME の設定をありがちな方法でおこなう ために、二つの変数をそれぞれ使うことができます。 mk.conf で OBJHOSTNAME が 定義されると、ホスト名の最初の部分がディレクトリー名に付け加えられます。 OBJMACHINE が定義されると、 work.i386 や work.sparc のように、プラットフォ ーム名が付け加えられます。 以下の事柄に気を配ってください。 * もしパッケージによりマニュアルページが圧縮された形式でインストールされる場 合、MANCOMPRESSEDを追加してください。パッケージが BSD 形式の makefile を使 っており、MANZ の設定に従う場合には、 MANCOMPRESSED_IF_MANZ を使います。 * すべてのファイルの/usr/localを“${PREFIX}”に変更してください。(後述のパッ チを参照) * もし、パッケージがinfoファイルをインストールするのであれば、Section 19.6.7, “infoファイルをインストールするパッケージ”を参照してください。 11.2. distinfo distinfo ファイルには、パッケージが必要とする各 distfile のメッセージダイジェス トあるいはチェックサムが格納されます。作者が配布した元のファイルに対して、この メッセージダイジェストが一致することを確認しています。これをもとに、インターネ ットから取得したdistfileが転送中にファイルが壊れたり、悪意によりセキュリティー ホールを入れられたファイルに変更されていたりしていないことを確認します。最近、 ダイジェストアルゴリズムの弱さについての噂があるため、すべての distfile は、フ ァイルサイズに加えて、 SHA1 と RMD160 の両方のメッセージダイジェストを使って守 られています。 patches ディレクトリーに入っているすべてのパッチ (Section 11.3, “patches/*”参 照) のチェックサムも、この distinfoファイルに格納されます。 distinfo ファイルを作り直すには、 make makedistinfo または make mdi コマンドを 使います。 パッケージのなかには、プラットフォームによってdistfileの組が異なるものがありま す(たとえば lang/openjdk7)。この情報は単一のdistinfoファイルに書かれるので、こ のようなパッケージの更新時には、distfileの情報が失われないように注意を払ってく ださい。 11.3. patches/* 多くのパッケージは、pkgsrc で対応している各種プラットフォーム上で、まだ無修正で は動きません。このため、そのようなパッケージを動くようにするために、多数の独自 のパッチファイルが必要です。このパッチファイルは、 patches/ ディレクトリーにあ ります。 patch 相では、WRKSRC 以下にファイルが展開された後に、展開されたファイルに対して 、このパッチファイルがアルファベット順で適用されます。 11.3.1. 個々のパッチファイルの構造 問題を避けるため、patch-*ファイルは diff -buフォーマットとし、かつ、曖昧さなし で適用できるようにします。(曖昧さがあっても強制的にパッチを適用させるため、 PATCH_FUZZ_FACTOR=-F2を設定することができます)。さらに、各パッチファイルは一つ のファイルに対する修正だけを含むようにし、また、一つのファイルを複数のパッチフ ァイルによって修正するようなことはしないようにします。こうすることで、将来の変 更が簡単になります。 各パッチファイルは、以下のような構造となっています: 最初の行にはパッチそのもの の RCS Id があります。2 行目は、見栄えをよくするため、空にします。これより後に は、そのパッチによる各変更についてのコメントを書きます。これには標準的な事例が いくつもあります。 * 一般に知られている脆弱性に対するパッチには、その脆弱性の ID (CAN, CVE) を記 すようにします。 * ソースコードを変更するパッチには、そのパッチを必要とするプラットフォームや その他の環境 (たとえばコンパイラー) を記すようにします。 あらゆる事例において、そのアプリケーションのコードを理解している開発者がパッチ を利用できるようにするため、パッチにはコメントを書くようにします。上流の開発者 に対しては特に注意が必要です。たいていの場合、私たちの将来の作業を減らすために 、上流の開発者にパッチを採用してもらいたいからです。 11.3.2. パッチファイルを作成する 一つ重要なこととして、NetBSD CVSツリーにチェックインした後に問題を引き起こすの で、パッチファイルにRCS IDを含ませないように注意してください。この問題を避ける ため、 pkgtools/pkgdiff パッケージの pkgdiff コマンドを使ってください。 さらに自動化するため、同パッケージのmkpatchesを使ってパッチ一式を作ることをおす すめします。あなたがやらねばならないことは、ファイルの編集前に cp -p filename filename.origのようにするか、あるいはさらに簡単に、同パッケージの pkgviを使って 、元のファイルをfilename.origの名前でバックアップしておくだけです。この方法でパ ッケージをアップグレードした場合、patchdiffを使って、新しいパッチと既存のパッチ を簡単に比較することができます。 patches 以下のファイルは新しいファイルに置き換 えられますので、変更点が適切かどうかをしっかり確認してください。 パッケージを作り終えたとき、忘れずにmake makepatchsumコマンドでパッチファイルの チェックサムを生成するようにしてください。Section 11.2, “distinfo”を参照して ください。 (たとえば、マニュアルページのインストール先を pkgsrc の流儀に合わせて変えるとい ったものではなく) distfile の問題を正すパッチを追加した場合は、そのパッチをバグ 報告としてメンテナーに送ってください。こうすることで、pkgsrc を使っていない利用 者も幸せになれますし、通常は、将来のバージョンでパッチを削除することができるよ うになります。 パッチファイルのファイル名は、通常は patch-path_to_file__with__underscores.c と いう形式です。多くのパッケージでは、以前使われていた patch-[a-z][a-z] という形 式をまだ使っていますが、パッチを新たに作る場合は、ファイル名を含んだ形式にして ください。pkgtools/pkgdiff に含まれている mkpatches は、パッチファイルのファイ ル名を自動で処理します。 11.3.3. パッチファイルの出どころ pkgsrc の複数のパッケージが同じ distfile を使っているなどの理由で、複数のパッケ ージの間でパッチを共有したい場合は、 PATCHDIR をパッチファイルのある場所へのパ スに設定します。たとえば以下のようにします。 PATCHDIR= ${.CURDIR}/../xemacs/patches 作者その他のメンテナーが配布しているパッチファイルは、 PATCHFILES に列挙するこ とができます。 置いておきたいパッチがあるがpkgsrcにcommitすべきものではない場合、それを pkgsrc ツリーの外の $LOCALPATCHES ディレクトリーに置いておくことができます。このディレ クトリーツリーはpkgsrcと同様の“category/package”の構造を持つようにし、パッチ を各パッケージのディレクトリー(すなわち$LOCALPATCHES/$PKGPATH)に置くようになっ ています。たとえば、 pkgsrc/graphics/pngに私的なパッチを適用するようにしたい場 合は、そのパッチを $LOCALPATCHES/graphics/png/mypatchに置きます。このディレクト リーにあるファイルはすべてパッチファイルとして扱われ、 pkgsrcのパッチが適用され た後に、このパッチが適用されます。 11.3.4. パッチ作成の指針 コードの移植性に関する問題を修正する場合は、プリプロセッサーの細工を使ってオペ レーティングシステムやプラットフォームを判別するようなことはしてはいけません。 そのような方法では、各 OS 固有性の詳細が適切に抽象化できないため、他のオペレー ティングシステムに対する移植性を損なってしまいます。 一般的な決めごとは、アプリケーションを構築しているオペレーティングシステムその ものを検査するのではなく、必要としている特有の機能を検査する、というものです。 たとえば、kqueue は NetBSD において利用可能であると仮定して __NetBSD__ マクロを kqueue 対応の条件として使う、ということはせずに、kqueue 自体を検出するようにす るのです。そしてこれは、一般的には configure スクリプトにパッチを適用することに なります。ある OS が他の OS (たとえば kqueue を実装した Linux) のインターフェー スを採用してはいけない理由はまったくありませんが、前述のようにオペレーティング システムそのものを検査してしまうと、そのような状況に対応することができません。 もちろん、機能を検査することは、一般的に、開発者側の負担が多くなります。しかし 、機能を検査するようにすれば、その結果はきれいな変更となり、他の多くのプラット フォームで動作させられる可能性があります。また、本家のソースに統合される可能性 が高くなることはいうまでもありません。正しくない限り動かないの哲学を忘れないで ください。 典型的な例としては、以下のようなものがあります。 Table 11.1. パッチ適用例 +-------------------------------------------------------------------------------------------+ | 場所 | 誤 | 正 | |---------+--------------------------+------------------------------------------------------| |configure|case ${target_os} in | | |スクリプ |netbsd*) have_kvm=yes ;; |AC_CHECK_LIB(kvm, kvm_open, have_kvm=yes, have_kvm=no)| |ト |*) have_kvm=no ;; | | | |esac | | |---------+--------------------------+------------------------------------------------------| |C ソース |#if defined(__NetBSD__) |#if defined(HAVE_SYS_EVENT_H) | |ファイル |# include |# include | | |#endif |#endif | |---------+--------------------------+------------------------------------------------------| | |int |int | | |monitor_file(...) |monitor_file(...) | | |{ |{ | | |#if defined(__NetBSD__) |#if defined(HAVE_KQUEUE) | |C ソース | int fd = kqueue();| int fd = kqueue(); | |ファイル | ... | ... | | |#else |#else | | | ... | ... | | |#endif |#endif | | |} |} | +-------------------------------------------------------------------------------------------+ さらなる情報は、Making packager-friendly software の記事 (第 1 部、第 2 部) を お読みください。この記事では、ソフトウェアをパッケージ化しやすくする方法につい て、複数の点での詳細をまとめています。ここで述べられている提案は、いずれも、私 たちが pkgsrc の作業をした経験から集められたものですので、パッチの作成に際して も役に立つかもしれません。 11.3.5. 作者へのフィードバック 常に、常に、常に、パッケージに施したあらゆる移植性に関する修正や改良点を、本家 の開発者に還元するようにしてください。彼らに移植性についての注意を喚起して、将 来のバージョンが無修正で NetBSD で構築できるようにするためには、そうするしかな いのです。また、将来のバージョンの配布ファイルの利用者は、フィードバックされた 修正をパッケージのコードから直接利用することができるようになります。 フィードバックをする方法は、一般的には、パッチをきれいに書き直し (pkgsrc で追加 されたパッチは、時にはクイックハックであることがあるからです)、フィードバック先 のプロジェクト用の適切な追跡システムに対してバグ報告をし、変更が受け入れられる よう本家の作者とともに作業する、というものです。フィードバックをすることで、 pkgsrc のパッケージを単純なものとし、さほど労力を割かずに将来の変更ができるよう にするということが、特に重要です。 フィードバックをしたら、上流のバグレポートの URL をパッチのコメントに追加してく ださい。 フリーソフトウェアの理念をサポートして下さい。 11.4. その他の必須のファイル DESCR ソフトウェアについての複数行の説明。このファイルには適切なクレジットを含め ておいてください。他人があなたのユーモアのセンス(あるいは変わった綴り) を理 解してくれない事、そしてここに書かれたものすべてを他人が読むであろうという 事を念頭においておいてください。 PLIST このファイルは、システムにインストールされるファイルを管理します:すべてのバ イナリー、マニュアルページ、その他。ディレクトリーの作成、削除、インサート された(inserted)ファイルの位置を管理するための、他のディレクティブもこのフ ァイルに記述されます。詳細はChapter 13, PLIST 問題を参照してください。 11.5. オプションのファイル 11.5.1. バイナリーパッケージに影響をおよぼすファイル INSTALL このシェルスクリプトはpkg_add(1)によって二度起動されます。最初は、パッケー ジが展開された後、ファイルが移動される前に、二度目はインストールするファイ ルが移動された後。このファイルは、 PLIST内の@execコマンドでは不可能な特別な 処理のために使うことができます。より詳細な情報はpkg_add(1)と pkg_create(1) を参照してください。Section 15.1, “インストール用のプレフィックス以外の場 所にあるファイルとディレクトリー”もあわせて参照してください。 DEINSTALL このスクリプトは、ファイルが削除される前後に実行されます。このスクリプトの 責任は、パッケージのインストレーションにかかわる雑多なものをきれいにするこ とです。なぜなら、pkg_deleteは、オリジナルのディストリビューションで作成さ れたファイルをどのように削除するかをすべて知っておかなければならないからで す。より詳細な情報はpkg_delete(1)と pkg_create(1)を参照してください。 MESSAGE パッケージのインストール後にこのファイルの内容が表示されます。完全にフリー ではないソフトウェアについての法的な通知や、 apache, PHP などのモジュールの インストール後の設定ファイルの更新に関するヒント等に役立ちます。パッケージ のMakefileで MESSAGE_SUBSTを使うことで、変数を簡単に変えられることに注意し てください: MESSAGE_SUBST+= SOMEVAR="somevalue" とすると、MESSAGE中の "${SOMEVAR}" は、“somevalue”に置換されます。標準で は、置換は PKGNAME, PKGBASE, PREFIX, LOCALBASE, X11PREFIX, X11BASE, PKG_SYSCONFDIR, ROOT_GROUP, ROOT_USER に対しておこなわれます。 MESSAGE_SRC 変数を設定すると、置換の対象のファイルを変えたり追加したりする ことができます。この変数は、MESSAGE (このファイルが存在する場合) です。 ALTERNATIVES FIXME: alternatives の枠組に関するドキュメンテーションは、ありません。 11.5.2. 構築の過程に影響をおよぼすファイル Makefile.common このファイルには、Makefile に書くことができることを好きなように含めることが できますが、このファイルの目的は複数のパッケージから利用することです。この ファイルを利用するパッケージがあらかじめわかっている場合に限り、使うように します。それ以外の場合には、*.mk ファイルを書いて、その役割をあらわすファイ ル名をつけたほうがよいことが多いでしょう。 buildlink3.mk このファイルには、buildlink3 の枠組 (Chapter 14, buildlink 方法論参照) のた めの依存性情報が含まれます。 hacks.mk このファイルには、コンパイラーのバグや、それに類する事象への回避策が含まれ ます。このファイルは pkgsrc の基盤が自動的にインクルードしますので、インク ルードのための .include 行は必要ありません。 options.mk このファイルには、利用者が選択可能なパッケージ固有のオプション (Chapter 16, オプションの扱い参照) のためのコードが含まれます。パッケージにオプションが 一つか二つしかない場合は、このコードを Makefile 内に直接書いてもかまいませ ん。 11.5.3. 何の影響もおよぼさないファイル README* このファイルは、パッケージの作成に対して何の影響もおよぼさず、パッケージ開 発者向けの情報を記しただけのものです。 TODO このファイルには、パッケージを改良するためにおこなう必要があることが含まれ ます。 11.6. work* makeとタイプした時に、配布ファイルが WRKDIR で示されたディレクトリーに展開され ます。 make clean を実行すれば、これらを削除することができます。このディレクト リーは、ソースの展開のほか、さまざまなタイムスタンプファイルを作っておくために も使用されます。これらも、clean によって完全に削除されます。標準では ${.CURDIR} /work (OBJMACHINE が設定されている場合は ${.CURDIR}/work.${MACHINE_ARCH}) です 。 11.7. files/* また、もしあなたがコンフィギュレーションまたは構築するより前に、パッケージ中に 何かファイルを置きたいならば、それらのファイルをfilesディレクトリーに置くことが できますし、“pre-configure”ターゲットで、 ${CP}コマンドによりコピーすることが できます。あるいは、/dev/nullに対するそのファイルの単純なdiffをとり、パッチメカ ニズムを使用して、そのファイルを生成することもできます。 files ディレクトリーにファイルを置く方法で、他のパッケージとファイルを共有した い場合は、 FILESDIR 変数を、他のパッケージの files ディレクトリーを指すように設 定します。たとえば以下のようにします。 FILESDIR=${.CURDIR}/../xemacs/files Chapter 12. Makefile におけるプログラミング Table of Contents 12.1. 警告 12.2. Makefile 変数 12.2.1. 命名規約 12.3. コードの断片 12.3.1. リストに要素を追加する 12.3.2. 内部リストを外部リストに変換する 12.3.3. シェルコマンドに値を渡す 12.3.4. クォートの指針 12.3.5. BSD Make のバグの回避方法 pkgsrc は、多くの Makefile の断片からなっており、この各断片が、pkgsrc システム の各部分を明確に形成しています。 pkgsrc のような大規模なシステムのプログラミン グ言語として make(1) システムを使う場合、コードを適切かつわかりやすい状態に保つ ために、いくらかの規律が必要です。 Makefile プログラミングの基本的な構成要素は、変数 (実はマクロ) とシェルコマンド です。シェルコマンドは、awk(1) プログラムのような複雑なものになることもあります 。各シェルコマンドを意図どおりに動かすため、変数を使うときは、すべての変数を適 切にクォートすることが必要です。 本章では、Makefile で頻出するいくつかのパターンと、それらに伴う落とし穴を説明し ます。 12.1. 警告 * ルールのターゲットとしてファイルを作る場合、常に、データをまず一時ファイル に書き込んでから、最後にファイル名を変えるようにしてください。そうしておか ないと、ファイルの生成の途中にエラーが起きた場合、利用者が make(1) を 2 回 目に実行したときに、前回のファイルが存在したままとなり、ファイルが正しく再 生成されません。たとえば、 wrong: @echo "line 1" > ${.TARGET} @echo "line 2" >> ${.TARGET} @false correct: @echo "line 1" > ${.TARGET}.tmp @echo "line 2" >> ${.TARGET}.tmp @false @mv ${.TARGET}.tmp ${.TARGET} make wrong を 2 回実行したときに、 1 回目の実行でエラーメッセージが出ますが 、ファイル wrong は作られた状態になります。一方、make correct を実行すると 、エラーメッセージが 2 回出るという、期待どおりの動作となります。 エラーの場合には make(1) が ${.TARGET} を削除することがあるということをご存 知かもしれませんが、この削除は、たとえば ^C を押すなど、割り込みがあった場 合にのみおこなわれます。コマンドのどれかが (上の例の false(1) のように) 失 敗した場合には、削除はおこなわれません。 12.2. Makefile 変数 Makefile 変数は文字列を値として持ち、文字列は 5 種類の演算子 ``='', ``+='', ``? ='', ``:='', ``!='' を使って操作することができます。演算子については make(1) マ ニュアルページに説明があります。 Makefile の変数が解釈される際、ハッシュ文字 ``#'' とバックスラッシュ文字 ``\'' は特別扱いされます。バックスラッシュに改行が続く場合、当該バックスラッシュの直 前にあるあらゆる空白・当該バックスラッシュ・改行・改行の直後にあるあらゆる空白 は、ひとつのスペースに置き換えられます。バックスラッシュ文字とその直後に続くハ ッシュ文字は、ひとつのハッシュ文字に置き換えられます。以上の場合以外は、バック スラッシュはそのまま渡されます。変数への代入の際は、ハッシュ文字 (その前にバッ クスラッシュがないもの) はコメントの開始となり、そこから論理行の最後までがコメ ントとなります。 註: このようなアルゴリズムで解釈されるせいで、バックスラッシュ一文字を値として 持つ変数を作るには、 ``!='' 演算子を使う方法しかありません。たとえば以下のよう にします: BACKSLASH!=echo "\\". 以上は、変数の定義に関する説明です。このほか、変数に関してできることは、変数を 評価することです。変数が評価されるのは、変数が ``:='' または ``!='' 演算子の右 辺にある場合と、変数がシェルコマンドの一部となっている場合 (コマンドが実行され る直前に評価される) です。これら以外の場合、 make(1) は遅延評価をおこないます。 つまり、変数は他の処理がすべてすんだ後に評価されます。このほか、マニュアルペー ジに記載されている「修飾子」も、変数を評価します。 修飾子のなかには、文字列を語に分割してから、分割した語に対して操作をするものが あります。それ以外の修飾子は、文字列全体に対して操作をします。文字列が語に分割 される場合、その分割は、 sh(1) の解釈と同様の方式でおこなわれます。 例外のない規則はありません? .for ループはシェルのクォートの規約には従わず、空白 の並びで分離します。 変数には、取り扱い方が異なる複数の種類の変数があります。文字列 (strings) と、二 種類のリストです。 * 文字列 (strings) には、任意の文字を含めることができます。とはいえ、使うのは 印字可能文字だけにしておくのがよいでしょう。例としては PREFIX や COMMENT が あります。 * 内部リスト (internal lists) は、シェルコマンドに決して渡されることのないリ ストです。内部リストの要素は空白で区切られます。このため、要素自体に空白を 含めることはできません。空白以外の文字はすべて使うことができます。内部リス トは .for ループ内で使うことができます。例としては DEPENDS や BUILD_DEPENDS があります。 * 外部リスト (external lists) は、シェルコマンドに渡すことのできるリストです 。外部リストの要素には、空白を含む任意の文字を含めることができます。このこ とが理由で、外部リストは .for ループ内では使うことができません。例としては DISTFILES や MASTER_SITES があります。 12.2.1. 命名規約 * 下線で始まる変数名はすべて、 pkgsrc の基盤が使うために予約されています。そ のような変数名はパッケージの Makefile では使ってはいけません。 * .for ループでは、反復変数の変数名は小文字にします。 * リスト変数はすべて、PKG_OPTIONS や DISTFILES のように、「複数形」の名前にし ます。 12.3. コードの断片 本節では、読者がコードを書く際に使うことになるコードの断片をいくつか説明します 。適当なコードがここに載っていない場合は、あなたのコードをテストして、ここに追 加してください。 12.3.1. リストに要素を追加する STRING= foo * bar `date` INT_LIST= # empty ANOTHER_INT_LIST= apache-[0-9]*:../../www/apache EXT_LIST= # empty ANOTHER_EXT_LIST= a=b c=d INT_LIST+= ${STRING} # 1 INT_LIST+= ${ANOTHER_INT_LIST} # 2 EXT_LIST+= ${STRING:Q} # 3 EXT_LIST+= ${ANOTHER_EXT_LIST} # 4 文字列を外部リストに追加する場合 (例 3) は、その文字列をクォートする必要があり ます。それ以外の場合は、クォートを追加してはいけません。内部リストと外部リスト は、その各要素がどちらのリストでも適切に処理されることが確実な場合をのぞき、統 合してはいけません。 12.3.2. 内部リストを外部リストに変換する EXT_LIST= # empty .for i in ${INT_LIST} EXT_LIST+= ${i:Q}"" .endfor このコードは、内部リスト INT_LIST を外部リスト EXT_LIST に変換します。内部リス トの要素はクォートされていないので、変換に際してはクォートする必要があります。 "" を追加する理由は後述します。 12.3.3. シェルコマンドに値を渡す 時には、任意の文字列を出力したいことがあるかもしれません。不具合を起こす方法は たくさんありますが、どんな複雑なものも扱えるような方法は少ししかありません。 STRING= foo bar < > * `date` $$HOME ' " EXT_LIST= string=${STRING:Q} x=second\ item all: echo ${STRING} # 1 echo "${STRING}" # 2 echo "${STRING:Q}" # 3 echo ${STRING:Q} # 4 echo x${STRING:Q} | sed 1s,.,, # 5 printf "%s\\n" ${STRING:Q}"" # 6 env ${EXT_LIST} /bin/sh -c 'echo "$$string"; echo "$$x"' 例 1 は、シェルで構文エラーを起こします。各文字がそのままコピーされるだけだから です。 例 2 も構文エラーを起こします。また、${STRING} の末尾の " 文字を除いた場合は、 date(1) が実行されてしまいます。また、$HOME シェル変数も評価されるでしょう。 例 3 は、echo(1) コマンドの実装によって、各空白文字の前にバックスラッシュが出力 されたり、されなかったりします。 例 4 は、最初の文字がダッシュでない文字列はすべて適切に処理します。文字列の最初 の文字がダッシュの場合、結果がどうなるかは echo(1) コマンドの実装に依存します。 入力される文字列の最初の文字がダッシュにならないことを保証できる限りは、この形 式は適切です。 例 5 は、たとえ文字列がダッシュで始まっていたとしても、適切に処理します。 例 6 も、あらゆる文字列を適切に処理できますし、それ自体に問題のあるパイプを使わ ないので、より軽い方法です。 EXT_LIST はクォートする必要はありません。なぜなら、リストに要素を追加した時に、 すでにクォートされているからです。 内部リストはシェルに渡されないものなので、例示はありません。 12.3.4. クォートの指針 変数が不適切にクォートされたソースは、多くありえます。本節では、よく知られてい る例をいくつか掲げます。 * リストの値を使うときは常に、値の冒頭や末尾にある空白がどうなるかを考えてく ださい。リストが整形式のシェルの式である場合、それぞれの語から冒頭や末尾の 空白を取り除くために、 :M* 修飾子を使うことができます。 :M 演算子は、最初に その引数をシェルの規約に従って分割してから、シェルのグロブ式 * にマッチする 語 (つまり全部) すべてからなるリストを新たに作ります。これが必要となる状況 は、CPPFLAGS のような変数を CONFIGURE_ARGS に追加する場合です。 configure スクリプトが別の configure スクリプトから呼び出される場合、呼び出された側の スクリプトは変数から冒頭と末尾の空白を取り除き、それを別の configure スクリ プトに渡します。しかし、この両 configure スクリプトは、(子の) CPPFLAGS 変数 が親の CPPFLAGS と同じものであると見込んでいます。これが、CPPFLAGS の値を適 切に切り取ったものを渡したほうがよい理由です。そして、以下に掲げるのは、そ の方法です。 CPPFLAGS= # empty CPPFLAGS+= -Wundef -DPREFIX=\"${PREFIX:Q}\" CPPFLAGS+= ${MY_CPPFLAGS} CONFIGURE_ARGS+= CPPFLAGS=${CPPFLAGS:M*:Q} all: echo x${CPPFLAGS:Q}x # 前後に空白がつく echo x${CONFIGURE_ARGS}x # 適切に切り取られる * 上の例にはバグがひとつあります: ${PREFIX} は適切にクォートされたシェルの式 ですが、シェルの後には C コンパイラーがあり、こちらでも適切に (今度は C の 文法で) クォートされている必要があります。このため、上で例示したものは、$ {PREFIX} の値にバックスラッシュや二重引用符が含まれていない場合に限って、正 しいものになります。これらの文字を含めたい場合、 C の文字列リテラルとして扱 われる値をすべてクォートするために、もう一つの層を追加する必要があります。 :Q 演算子はシェル用のクォートしかできないので、 C コンパイラー用のクォート には使えません。 * 値が空になりうる場合は、 :Q 演算子が妙な結果を出すことがあります。以下に 2 種類のまったく異なる事例を掲げますが、どちらも同じ細工をすることで解決でき ます。 EMPTY= # empty empty_test: for i in a ${EMPTY:Q} c; do \ echo "$$i"; \ done for_test: .for i in a:\ a:\test.txt echo ${i:Q} echo "foo" .endfor 一つ目の例では、3 行が表示されると思うかもしれませんが、そのうちの 2 行しか 表示されません。これは、 ${EMPTY:Q} が空の文字列に展開され、シェルからは見 えなくなるからです。回避策は、 ${EMPTY:Q}"" と書くことです。このパターンは 、 ${TEST} -z ${VAR:Q} や ${TEST} -f ${FNAME:Q} のように、しばしば見られま す (いずれも、間違いです)。 二つ目の例では、表示されるのは 4 行ではなく 3 行です。最初に表示される行は a:\ echo foo のようになります。これは、値 a:\ のバックスラッシュを make(1) が継続行として処理し、2 行目が 1 行目の echo(1) コマンドの引数になってしま うためです。これを防ぐには、${i:Q}"" と書きます。 12.3.5. BSD Make のバグの回避方法 pkgsrc の bmake プログラムは、以下のような代入を適切に処理することができません 。 _othervar_ が ``-'' 文字を含んでいる場合、以下のコードを実行すると、閉じ中括 弧のひとつが ${VAR} に含まれてしまいます。 VAR:= ${VAR:N${_othervar_:C/-//}} もっと複雑なコードの断片と回避策については、 regress/make-quoting パッケージの テストケース bug1 をご覧ください。 Chapter 13. PLIST 問題 Table of Contents 13.1. RCS ID 13.2. PLIST の半自動生成 13.3. make print-PLIST の出力を細工する 13.4. PLIST における各種の置換 13.5. マニュアルページの圧縮 13.6. PLIST_SRC を使って PLIST のソースを変更する 13.7. プラットフォーム別に異なるPLIST 13.8. 複数のパッケージでディレクトリーを共有する PLIST ファイルは、パッケージの“packing list” (梱包明細) です。すなわち、パッ ケージを構成するファイルの一覧 (インストール先である ${PREFIX} ディレクトリーか らの相対位置) と、それに加えて、いくつかの追加情報 (完全な一覧は pkg_create(1) マニュアルページを参照) が載っています。この章では、PLISTファイル (複数の場合も あります、以下を参照してください)を扱う場合に注意が必要な、いくつかの特別な問題 について述べます。 13.1. RCS ID あなたが書いたすべてのPLISTファイルの先頭行にRCS IDが追加されていることを確認し てください。 @comment $NetBSD$ 13.2. PLIST の半自動生成 make print-PLISTコマンドを使って、パッケージの展開後に新しくできた全ファイルに マッチするPLISTを出力することができます。このターゲットに関するさらなる情報は、 Section 17.17, “他の役に立つターゲット”をご覧ください。 13.3. make print-PLIST の出力を細工する *-dirs パッケージをSection 13.8, “複数のパッケージでディレクトリーを共有する” で説明したように使った場合、make print-PLIST で、実際の @dirrm 行のかわりに @comment が出力されることにお気づきかもしれません。ここでディレクトリーやファイ ルを指定して、実際に近い結果を出力させることもできます。これはパッケージの更新 の際に非常に役立ちます。 PRINT_PLIST_AWK 変数を、 print-PLIST の出力をフィルターする AWK のパターンと動 作の一式に設定します。 AWK スクリプト塊を好きなように追加することができますが、 適切にクォートするよう注意してください。 たとえば、PLIST の結果から libdata/foo ディレクトリー内のファイルをすべて消すに は、以下のようにします。 PRINT_PLIST_AWK+= /^libdata\/foo/ { next; } また、特定の (共有) ディレクトリーを参照している @dirrm 行を @comment に変換す るには、以下のようにします。 PRINT_PLIST_AWK+= /^@dirrm share\/specific/ { print "@comment " $$0; next; } 13.4. PLIST における各種の置換 パッケージがシステムにインストールされる際に、 PLIST 内のいくつもの変数が自動的 に置換されます。置換される変数には、以下のようなものがあります。 ${MACHINE_ARCH}, ${MACHINE_GNU_ARCH} emacs、およびperlのようないくつかのパッケージは、それらが構築されたアーキテ クチャーに関する情報を、インストールするファイルのパス名に埋め込みます。こ のようなケースに対応するため、実際に使われる前に、PLISTに前処理がおこなわれ ます。そして、シンボル“${MACHINE_ARCH}”は、uname -pの出力でおきかえられま す。 ${MACHINE_GNU_ARCH}がPLISTのどこかにうめこまれている場合も同様の事がお こなわれます。これは、GNU autoconfで作成された configureスクリプトを持つパ ッケージで使われます。 昔の話 “$ARCH”シンボルはuname -mの出力によって置きかえられていました。しかし、も はやサポートされていませんし、削除されています。 ${OPSYS}, ${LOWER_OPSYS}, ${OS_VERSION} いくつかのパッケージでは、OS名とバージョンをいくつかのパス名に埋め込みます 。このような場合、PLISTで以下の各変数を使用してください。 * ${OPSYS} - “uname -s”の出力 * ${LOWER_OPSYS} - 共通名の小文字表記(例: “solaris”) * ${OS_VERSION} - “uname -r” デフォルトで置換される値の全一覧は、 bsd.pkg.mk を参照してください (あわせて、 PLIST_SUBST を調べてください)。 上述以外の変数を置換したい場合は、 MESSAGE_SUBST (Section 11.5, “オプションの ファイル”参照) と同様に、以下のようにして、変数とその展開方法を定義することが できます。 PLIST_SUBST+= SOMEVAR="somevalue" こうすると、PLIST 内のすべての“${SOMEVAR}”が“somevalue”で置き換えられます。 PLIST_VARS 変数を使うと、条件に応じて PLIST の項目を追加することができます。 PLIST_VARS+=foo のように値を追加して、これに対応する PLIST.foo 変数を yes に設 定します。このように設定すると、PLIST にある“${PLIST.foo}”が“""”に置換され るようになります (設定していない場合は“"@comment "”に置換されます)。たとえば 、Makefile では以下のようにします。 PLIST_VARS+= foo .if condition PLIST.foo= yes .else こうしたうえで、PLIST では以下のようにします。 @comment $NetBSD$ bin/bar man/man1/bar.1 ${PLIST.foo}bin/foo ${PLIST.foo}man/man1/foo.1 ${PLIST.foo}share/bar/foo.data ${PLIST.foo}@dirrm share/bar 13.5. マニュアルページの圧縮 もし、(bsd.own.mkに)MANZが設定されていれば、マニュアルページは圧縮形式でインス トールされます。そうでなければ展開された形式でインストールされます。 PLISTファ イルでこれをサポートするために、MANZと MANCOMPRESSEDの設定の有無に従い、“.gz” サフィックスがマニュアルページに自動的に追加、削除されます。このPLISTファイルに 対する変更は、PLIST自身にたいしてでなく、それがコピーされる時におこなわれます。 13.6. PLIST_SRC を使って PLIST のソースを変更する ひとつ以上のファイルを、バイナリーパッケージを構築するためにPLISTのソースとして 使用する時は、それらのファイル名を変数PLIST_SRCに設定してください。これらのファ イルは、後でcat(1)によって連結されます。連結の順番は重要です。 PLIST_SRC は、標 準では ${PKGDIR}/PLIST になります。 13.7. プラットフォーム別に異なるPLIST パッケージのなかには、インストールするファイルの組合せを、対象のオペレーティン グシステムによって変えるものがあります。このような差異は、以下のファイルを使っ て自動的に処理することができます。 * PLIST.common * PLIST.${OPSYS} * PLIST.${MACHINE_ARCH} * PLIST.${OPSYS}-${MACHINE_ARCH} * PLIST.common_end 13.8. 複数のパッケージでディレクトリーを共有する “共有ディレクトリー”とは、複数の (かつ関連のない) パッケージがファイルをイン ストールするディレクトリーのことです。以前は、共有ディレクトリーは、条件に応じ た削除のために PLIST に特殊な細工をするか、集権的な処理用パッケージを用意する必 要があったので、問題を起こすことがありました。 現在の pkgsrc では、話は単純になっています。各パッケージは、必要に応じて、ディ レクトリーを作成してファイルをインストールします。 pkg_delete は、パッケージの アンインストール後、空のディレクトリーが残っていればすべて削除します。 パッケージの動作のために空のディレクトリーが必要な場合は、インストール時に通常 と同じようにディレクトリーを作成するようにし、さらに PLIST に以下のような項目を 追加します。 @pkgdir path/to/empty/directory Chapter 14. buildlink 方法論 Table of Contents 14.1. パッケージを変換して buildlink3 を使うようにする 14.2. buildlink3.mk ファイルを書く 14.2.1. buildlink3.mk ファイルの分析 14.2.2. buildlink3.mk ファイルの BUILDLINK_API_DEPENDS.pkg を更新する 14.3. builtin.mk ファイルを書く 14.3.1. builtin.mk ファイルの分析 14.3.2. ネイティブおよび pkgsrc のソフトウェアの選択に関する、大域的な設定 buildlink は pkgsrc における枠組のひとつで、パッケージのコンフィギュレーション (configure) および構築 (build) の過程で、どのヘッダーやライブラリーが使われるか を制御するものです。これは以下の二つの手順によって実現されます。 1. BUILDLINK_DIR (標準では、 WRKDIR のサブディレクトリー) 内に、依存するヘッダ ーやライブラリーを指すシンボリックリンクを作ります。 2. 通常のコンパイラーツールを置き換えるラッパースクリプトを生成します。これは 、-I${LOCALBASE}/include および -L${LOCALBASE}/lib を、 BUILDLINK_DIR への 参照に変換します。また、オペレーティングシステムによっては、このラッパース クリプトは、ネイティブのコンパイラーが GCC に見えるようにし、 GCC を要求す るパッケージを修正することなく、ネイティブのコンパイラーで構築できるように します。 こうすることで、パッケージ構築環境を正規化して、他にどのようなソフトウェアがイ ンストールされているかにかかわらず、パッケージを一貫して構築できるようにします 。なお、通常のシステムヘッダーおよびライブラリーのパス、たとえば /usr/include, /usr/lib などは、すでに探索されていることに注意してください -- buildlink3 は、 パッケージの構築を、システム非標準のソフトウェアから独立させるために設計された ものなのです。 14.1. パッケージを変換して buildlink3 を使うようにする パッケージが buildlink3 の枠組を使うようにする変換の過程 (“bl3ifying” - buildlink3 化) は、かなり単純です。以下のことに注意してください。 1. 構築の際には、常に、 toolchain 本体ではなくラッパースクリプトが呼ばれるよう にしてください。パッケージによっては巧妙なものがあるので、ラッパーが呼ばれ たかどうかを確実に調べる方法は、 ${WRKDIR}/.work.log を確認することだけです 。 2. たとえば Java VM やスタンドアローンのシェルでは、パッケージの Makefile で PREFIX を上書きしないでください。${BUILDLINK_DIR} からシンボリックリンクす るためのコードは、“pkg_info -qp pkgname”からの相対位置にあるファイルを探 すからです。 3. パッケージの依存性として追加されるのは、パッケージの Makefile に列挙した buildlink3.mk ファイルだけであることを忘れないでください。 あるパッケージのライブラリーやヘッダーに対する依存性が必要な場合は、 DEPENDS+= foo>=1.1.0:../../category/foo を、以下のものに置き換えます。 .include "../../category/foo/buildlink3.mk" 通常は、buildlink3.mk ファイルで必要な依存性を定義します。 buildlink3.mk ファイ ルを使う際に、より新しいバージョンへの依存性が必要な場合は、そのことを Makefile で定義することができます。たとえば以下のようにします。 BUILDLINK_API_DEPENDS.foo+= foo>=1.1.0 .include "../../category/foo/buildlink3.mk" pkgsrc/mk 以下には、特別なパッケージを扱うための buildlink3.mk ファイルがいくつ かあります。 * bdb.buildlink3.mk は、 BDB_ACCEPTED および BDB_DEFAULT の値にもとづき、ネイ ティブまたは pkgsrc の Berkeley DB の実装のどちらかを選択します。 * curses.buildlink3.mk: システムに Curses も NCurses も附属しない場合に、 devel/ncurses パッケージをインストールしてくれます。 * krb5.buildlink3.mk は、 KRB5_ACCEPTED の値を使って、 Kerberos 5 の実装を必 要とするパッケージを Heimdal または MIT-krb5 のどちらに依存させるかを選択し ます。 * motif.buildlink3.mk は、システム附属の Motif がインストールされているかを確 認し、ない場合は、x11/lesstif または x11/openmotif への依存性を追加します。 利用者は、MOTIF_TYPE を“dt”, “lesstif”または“openmotif”に設定して、ど の版の Motif を使うかを選択することができます。 * oss.buildlink3.mk は、 Open Sound System (OSS) API を使うパッケージが使うこ とがある変数をいくつか定義します。 * pgsql.buildlink3.mk は、 Postgres 8.0, 8.1 または 8.2 のうち、インストール されているものを受け入れます。さらなる情報は、このファイルの内容をご覧くだ さい。 * pthread.buildlink3.mk は、 PTHREAD_OPTS の値を使うとともに、ネイティブの pthread があるか確認し、ない場合は、必要に応じて devel/pth への依存性を追加 します。 * xaw.buildlink3.mk は、 XAW_TYPE の値を使って、具体的にどの Athena widget ラ イブラリーを使うかを選択します。 それぞれの buildlink3.mk ファイルのコメントに、適切な使い方に関するより詳しい説 明があります。 14.2. buildlink3.mk ファイルを書く パッケージの buildlink3.mk ファイルは、そのパッケージに附属するヘッダーファイル やライブラリーをコンパイルしたりリンクしたりする必要があることを示すために、 Makefile からインクルードされます。 buildlink3.mk ファイルは、適切な種類の依存 関係を追加したり、さらに必要となるヘッダーやライブラリーを使うために別の buildlink3.mk をインクルードしたりするために必要な情報を、いつでも提供できるよ うに作ります。 編集するための元となる buildlink3.mk ファイルを作るには、Rene Hexel の pkgtools /createbuildlink パッケージを使うことを強くおすすめします。ほとんどのパッケージ に対しては、以下のコマンドを使うと、buildlink3.mk ファイルのよい出発点となるも のを作ってくれます。 % cd pkgsrc/category/pkgdir % createbuildlink >buildlink3.mk 14.2.1. buildlink3.mk ファイルの分析 以下に掲げるのは、 pkgsrc/graphics/tiff における buildlink3.mk の実例です。 # $NetBSD: buildlink3.mk,v 1.16 2009/03/20 19:24:45 joerg Exp $ BUILDLINK_TREE+= tiff .if !defined(TIFF_BUILDLINK3_MK) TIFF_BUILDLINK3_MK:= BUILDLINK_API_DEPENDS.tiff+= tiff>=3.6.1 BUILDLINK_ABI_DEPENDS.tiff+= tiff>=3.7.2nb1 BUILDLINK_PKGSRCDIR.tiff?= ../../graphics/tiff .include "../../devel/zlib/buildlink3.mk" .include "../../graphics/jpeg/buildlink3.mk" .endif # TIFF_BUILDLINK3_MK BUILDLINK_TREE+= -tiff ヘッダーとフッターで、 BUILDLINK_TREE の値を操作しています。この変数は、パッケ ージの依存関係を辿るために、すべての buildlink3.mk ファイルの間で、共通に使われ ます。 本体の節では、多重のインクルードを防いだうえで、 pkg への依存性をどのように追加 するかを制御しています。いくつもの重要な変数がこの節で設定されます。 * BUILDLINK_API_DEPENDS.pkg は、インストールされるパッケージに対して、実際に 記録される依存性です。この変数の既存のリストを残したまま追加するために、か ならず += を使って設定します。この変数の設定値は、パッケージの API が現行の ものになった以降の最初 (最古) のバージョンにします。 * BUILDLINK_PKGSRCDIR.pkg は、pkgsrc における pkg のディレクトリーです。 * BUILDLINK_DEPMETHOD.pkg (上の例には出てきません) は、 pkg への依存性として BUILD_DEPENDS と DEPENDS のどちらを使うかを制御します。 BUILDLINK_DEPMETHOD.pkg を“build”にすれば、構築時の依存性となります。この 変数を設定しなかった場合は、完全な依存性となります。 * BUILDLINK_INCDIRS.pkg および BUILDLINK_LIBDIRS.pkg (上の例には出てきません) は、ヘッダーおよびライブラリーの検索パスに追加するための、 $ {BUILDLINK_PREFIX.pkg} のサブディレクトリーです。設定しなかった場合は、それ ぞれ“include”および“lib”となります。 * BUILDLINK_CPPFLAGS.pkg (上の例には出てきません) は、CPPFLAGS に追加するため のプリプロセッサー用のフラグで、このフラグは configure および build の段階 に渡されます。“-I”オプションは使わずに、上述の BUILDLINK_INCDIRS.pkg を使 って処理するようにしてください。 以下の各変数はすべて、二つ目の (多重のインクルードを防いでいる) 節において、任 意に定義されるものであり、どのパッケージのファイルを ${BUILDLINK_DIR} からシン ボリックリンクするか、および、シンボリックリンクによってファイル名をどのように 変換するか、を制御します。 * BUILDLINK_FILES.pkg (上の例には出てきません) は、 ${BUILDLINK_DIR} からシン ボリックリンクされるリンク先の、 ${BUILDLINK_PREFIX.pkg} からの相対位置のシ ェルのグロブパターンです。たとえば include/*.h のようになります。 * BUILDLINK_FILES_CMD.pkg (上の例には出てきません) は、 ${BUILDLINK_PREFIX. pkg}. からの相対位置でのファイルのリストを標準出力に出力する、シェルのパイ プラインです。これにより出力されるファイルは、 ${BUILDLINK_DIR} からシンボ リックリンクされます。指定しなかった場合、 pkg の +CONTENTS を $ {BUILDLINK_CONTENTS_FILTER.pkg} でフィルターした結果が出力されるようになり ます。 * BUILDLINK_CONTENTS_FILTER.pkg (上の例には出てきません) は、+CONTENTS を入力 にとり、 ${BUILDLINK_PREFIX.pkg} からの相対位置でのファイルのリストを標準出 力に出力するフィルターコマンドです。指定しなかった場合、overwrite パッケー ジでは、 BUILDLINK_CONTENTS_FILTER.pkg はパッケージの +CONTENTS から include および lib ディレクトリーの内容を出力し、 pkgviews パッケージでは、 lib ディレクトリーにある libtool アーカイブをすべて出力します。 * BUILDLINK_FNAME_TRANSFORM.pkg (上の例には出てきません) は、元ファイル名から 宛先ファイル名への変換用の sed の引数のリストです。たとえば -e "s|/curses.h |/ncurses.h|g" のようになります。 この節では、 pkg のライブラリー依存性として必要な buildlink3.mk をすべてインク ルードすることができます。ここで buildlink3.mk ファイルをインクルードすると、 pkg の buildlink3.mk ファイルがインクルードされる場合はいつも、これらへの依存性 のためのヘッダーやライブラリーも、 ${BUILDLINK_DIR} からシンボリックリンクされ ることになります。依存性が追加されるのは、 buildlink3.mk ファイルを直接インクル ードした場合だけです。 14.2.2. buildlink3.mk ファイルの BUILDLINK_API_DEPENDS.pkg を更新する パッケージを更新した際に BUILDLINK_API_DEPENDS.pkg に列挙されている依存性のバー ジョンを上げる必要があるのは、その更新で API やヘッダーファイルへのインターフェ ースが変わった場合です。 このような場合は、 BUILDLINK_API_DEPENDS.pkg を調節して、最低限、新しいパッケー ジのバージョンを要するようにします。場合によっては、新しいバージョンに依存する パッケージの PKGREVISION を上げる必要があることがあります。また、依存しているパ ッケージに buildlink3.mk ファイルがある場合は、 BUILDLINK_API_DEPENDS.pkg も調 節します。これは、pkgsrc が適切なパッケージの依存性を求めるようにして、ソースか らの構築時に古いパッケージに依存したりしないようにするために、必要なことです。 BUILDLINK_ABI_DEPENDS.pkg を上げるのは、バイナリーインターフェースや、インスト ールされている共有ライブラリーのいずれかの soname (ライブラリーのバージョンのメ ジャー番号) が変わった場合です。これは、これらを使うバイナリーパッケージが、適 切なパッケージの依存性を求めるようにして、必要な共有ライブラリーをもたない古い パッケージに依存したりしないようにするために、必要なことです。 BUILDLINK_ABI_DEPENDS および ABI_DEPENDS の定義を含めた、他のパッケージへの依存 性について、さらなる情報は、 Section 19.1.6, “依存性の処理”をご覧ください。 なお、必要もないのにパッケージを削除したり再構築したりするようなことのないよう 、 BUILDLINK_API_DEPENDS.pkg や BUILDLINK_ABI_DEPENDS.pkg の調節は、事前に熟考 するようにしてください。多くの場合、新しいバージョンのパッケージは、従前の依存 性のままでも問題なく動作します。 また、 BUILDLINK_ABI_DEPENDS.pkg は、 BUILDLINK_API_DEPENDS.pkg と同じ値となる 場合には設定する必要はありません。 14.3. builtin.mk ファイルを書く pkgsrc のパッケージのなかには、ベースシステムにも存在するようなヘッダーやライブ ラリーをインストールするものがあります。そのようなパッケージでは、 buildlink3.mk ファイルとは別に、 builtin.mk ファイルも含めておきます。このファ イルでは、ベースシステム附属のソフトウェアと pkgsrc のソフトウェアのどちらを使 うのが適切かを判断するために必要な確認をおこないます。 pkg 用の builtin.mk ファイルで必要なのは、以下のことだけです。 1. インクルードされた後に USE_BUILTIN.pkg を“yes”または“no”のどちらかに設 定すること。 2. builtin.mk ファイルがインクルードされる前から定義されている USE_BUILTIN.pkg を、一切上書きしないこと。 3. 複数のインクルードができるように書くこと。これは非常に重要なことであり、 Makefile のコーディングに対する配慮となります。 14.3.1. builtin.mk ファイルの分析 以下に掲げるのは、builtin.mk ファイルの推奨テンプレートです。 .if !defined(IS_BUILTIN.foo) # # IS_BUILTIN.foo is set to "yes" or "no" depending on whether "foo" # genuinely exists in the system or not. # IS_BUILTIN.foo?= no # BUILTIN_PKG.foo should be set here if "foo" is built-in and its package # version can be determined. # . if !empty(IS_BUILTIN.foo:M[yY][eE][sS]) BUILTIN_PKG.foo?= foo-1.0 . endif .endif # IS_BUILTIN.foo .if !defined(USE_BUILTIN.foo) USE_BUILTIN.foo?= ${IS_BUILTIN.foo} . if defined(BUILTIN_PKG.foo) . for _depend_ in ${BUILDLINK_API_DEPENDS.foo} . if !empty(USE_BUILTIN.foo:M[yY][eE][sS]) USE_BUILTIN.foo!= \ ${PKG_ADMIN} pmatch '${_depend_}' ${BUILTIN_PKG.foo} \ && ${ECHO} "yes" || ${ECHO} "no" . endif . endfor . endif .endif # USE_BUILTIN.foo CHECK_BUILTIN.foo?= no .if !empty(CHECK_BUILTIN.foo:M[nN][oO]) # # Here we place code that depends on whether USE_BUILTIN.foo is set to # "yes" or "no". # .endif # CHECK_BUILTIN.foo 最初の節では、pkg がベースシステムに実際に存在するかどうかに応じて、 IS_BUILTIN.pkg を設定しています。これは、ベースシステムに pkg 相当の機能のソフ トウェアが存在するかどうかではありません。この変数を“yes”にするのは、このパッ ケージそのものがベースシステムの一部として附属する場合だけです。この変数は、 builtin.mk ファイルの内部でのみ使われます。 二つ目の節では、pkg がベースシステムに存在する場合 (つまり IS_BUILTIN.pkg が“ yes”の場合)、 BUILTIN_PKG.pkg をそのバージョンに設定しています。この変数は、 builtin.mk ファイルの内部でのみ使われます。 三つ目の節では、 USE_BUILTIN.pkg を設定しており、これはすべての builtin.mk ファ イルで必須です。この節のコードは、ベースシステム附属のソフトウェアが、 BUILDLINK_API_DEPENDS.pkg で列挙されている依存性を満たすのに十分かどうかを判別 する必要があります。この判別は、たいていは、 BUILTIN_PKG.pkg を、 BUILDLINK_API_DEPENDS.pkg の各依存性と比較することでおこなわれます。 USE_BUILTIN.pkg は、builtin.mk ファイルの終わりまでに、適切な値に設定する必要が あります。なお、たとえ IS_BUILTIN.pkg が“no”であっても、 USE_BUILTIN.pkg は“ yes”にすることができます。なぜなら、ベースシステム附属のソフトウェアが依存パッ ケージに十分似ており、代替可能であるという判断もできるからです。 最後の節は CHECK_BUILTIN.pkg に守られており、前の節で設定された USE_BUILTIN.pkg の値を使うコードをインクルードします。たいていの場合、ここでインクルードするの は、たとえば依存性への制約の追加や、${BUILDLINK_DIR} からシンボリックリンクされ るファイルのリストの (BUILDLINK_FILES.pkg を使った) 追加などです。 14.3.2. ネイティブおよび pkgsrc のソフトウェアの選択に関する、大域的な設定 パッケージの構築時に、依存性を満たすソフトウェアとして組み込み (ネイティブ) の ものを使うか pkgsrc のものを使うかを、大域的な設定に応じて切替えることができま す。この制御は、PREFER_PKGSRC および PREFER_NATIVE を設定することでおこないます 。この両変数は、“yes”, “no”またはパッケージのリストを値として持ちます。 PREFER_PKGSRC は pkgsrc 版のソフトウェアを使うことを、 PREFER_NATIVE で組み込み 版を使うことを、それぞれ指示します。この設定は、対象パッケージではどちらを使う のがもっとも適当かに応じて、 PREFER_PKGSRC か PREFER_NATIVE のいずれかで指定し ます。あるパッケージがどちらにも設定されていない場合、または両方で設定されてい る場合は、 PREFER_PKGSRC が PREFER_NATIVE より優先します。たとえば、 NetBSD シ ステムの最も基本的な要素を除き、すべて pkgsrc 版のソフトウェアを使うこととする 場合、以下のように設定することができます。 PREFER_PKGSRC= yes PREFER_NATIVE= getopt skey tcp_wrappers あるパッケージを PREFER_NATIVE のリストに加えるには、そのパッケージに builtin.mk ファイルがある必要があります。このファイルがない場合は、リストに加え ても単に無視されます。 Chapter 15. pkginstall の枠組 Table of Contents 15.1. インストール用のプレフィックス以外の場所にあるファイルとディレクトリー 15.1.1. ディレクトリーの操作 15.1.2. ファイルの操作 15.2. 設定ファイル 15.2.1. PKG_SYSCONFDIR はどのように設定されるか 15.2.2. ソフトウェアに設定ファイルの置き場所を教える 15.2.3. インストールの過程を修正する 15.2.4. 設定ファイルの処理をしないようにする 15.3. システム起動スクリプト 15.3.1. システム起動スクリプトの処理をしないようにする 15.4. システムユーザーとグループ 15.5. システムシェル 15.5.1. シェルの登録をしないようにする 15.6. フォント 15.6.1. フォントデータベースの自動更新をしないようにする 本章では、pkginstall の枠組について説明します。主な機能は以下のとおりです。 * pkgsrc が扱うツリー (LOCALBASE) 以外の場所のディレクトリーやファイルの、汎 用的なインストールおよび操作。 * インストール時における、設定ファイルの自動処理 (パッケージが正しく設計され ていればですが)。 * システム起動スクリプトの作成およびインストール。 * システムユーザーおよびグループの登録。 * システムシェルの登録。 * フォントデータベースの自動更新。 以下の各節では、上述の各機能について詳しく見てゆきます。 本章で説明する機能の多くは、パッケージのインストール後のターゲット (post-install) を使うだけで簡単に実現できるのではないか、とお思いになるかもしれ ませんが、それは正しくありません。このターゲットのコードは、パッケージをソース から構築した場合しか実行されないからです。バイナリーパッケージを使う場合は、(コ ード自体が利用できないので) このターゲットのコードでは何もできません。したがっ て、上述の各機能は、 pkginstall が自動生成するインストール用スクリプトでしか実 現できないのです。 15.1. インストール用のプレフィックス以外の場所にあるファイルとディレクトリー すでにご存知のとおり、PLIST ファイルには、パッケージに属するファイルとディレク トリーの一覧が書かれています。この一覧では、インストール用のプレフィックス ($ {PREFIX}) からの相対位置を使うため、このディレクトリー以外の場所にあるファイル を書くことはできません (絶対パス名は使えません)。この制約がある一方で、パッケー ジによってはそのような場所、たとえば ${VARBASE} や ${PKG_SYSCONFDIR} 以下にファ イルをインストールする必要があります。これをおこなう唯一の方法は、インストール 時にインストール用のスクリプトを使ってインストール対象のファイルを作成すること です。 汎用のインストール用スクリプトは、任意のコードを含めることのできるシェルスクリ プトです。実行するスクリプトを並べたリストを INSTALL_FILE 変数で与えます。この 変数の値は標準では INSTALL です。パッケージの削除用としても、同様の変数がありま す (DEINSTALL_FILE: 標準の値は DEINSTALL)。これらのスクリプトでは任意のコマンド を実行できるので、ファイルシステム中のどこであってもファイルの作成や管理をする ことができます。 以上のような汎用のインストール用スクリプトを使うことはおすすめしませんが、特殊 な事例では必要となることがあります。これらを使うべきでない理由のひとつは、イン ストール用スクリプト内に不必要なコードや単純に誤ったコードが入っていないことに ついて、利用者がパッケージ作成者を信頼する必要があるということです。また、以前 は、同じ機能のために同様のコードがたくさん使われており、それらに共通するエラー を修正する場合は、同様のコードをすべて探して変更する必要がありました。 pkginstall の枠組では、これとは異なる標準化された方法を提供します。パッケージの Makefile で設定された変数にもとづき、インストール対象のファイルやディレクトリー を操作するための汎用のスクリプトを提供します。以下、本節では、この用途で使う変 数を説明します。 15.1.1. ディレクトリーの操作 以下の変数は、ファイルシステムの任意の場所へディレクトリーを作成するために、設 定することができます。 * MAKE_DIRS と OWN_DIRS は、インストール用スクリプトが作成したり、削除を試み たりする対象のディレクトリーのリストを値として持ちます。両変数の違いは、後 者はアンインストール時に (空でなかったために) 削除できなかった各ディレクト リーを削除するよう管理者に対してうながしますが、前者はそうしないことです。 * MAKE_DIRS_PERMS と OWN_DIRS_PERMS は、インストール用スクリプトが作成したり 、削除しようとしたりする対象のディレクトリーについて記述したタプルのリスト を値として持ちます。各タプルは、ディレクトリー名、所有者、所有グループと、 数字で表したモードの値をスペースで区切ったものからなります。たとえば以下の ようになります。 MAKE_DIRS_PERMS+= ${VARBASE}/foo/private ${ROOT_USER} ${ROOT_GROUP} 0700 両変数の違いは、PERMS のつかない変数の違いとまったく同じです。 15.1.2. ファイルの操作 インストール用プレフィックス以外の場所に空でないファイルを作ることは、やりにく いことです。なぜなら PLIST は全ファイルをインストール用プレフィックス内にあるも のとして扱うからです。この問題に対する唯一の解決策は、インストールの際に、ファ イルをいったん既知の場所 (つまり、インストール用プレフィックス内) に展開し、そ れを本来の場所にコピーすることです (pkginstall が生成するインストール用スクリプ トがおこないます)。以下、インストール用プレフィックス以外の場所のファイルを自動 的かつ首尾一貫して扱うために使える変数について説明しますが、ここではプレフィッ クス内にいったん展開したファイルのことを原本ファイル (master file) ということに します。 * CONF_FILES と REQD_FILES は、原本ファイルとコピー先ファイルの組のリスト を値として持ちます。インストール時に、コピー先ファイルが存在しなかった場合 に限って、原本ファイルがコピー先ファイルにコピーされます。アンインストール 時は、コピー先ファイルがインストールにおいて変更されていなければ、コピー先 ファイルが削除されます。 両変数の違いは、後者はアンインストール時に (空でなかったために) 削除できな かった各ファイルを削除するよう管理者に対してうながしますが、前者はそうしな いことです。 * CONF_FILES_PERMS と REQD_FILES_PERMS は、原本ファイルとコピー先ファイル について記述したタプルのリストを値として持ちます。各タプルは、ファイル名の ほか、両ファイルの所有者、所有グループと、数字で表したパーミッションを、こ の順番で指定します。たとえば以下のようになります。 REQD_FILES_PERMS+= ${PREFIX}/share/somefile ${VARBASE}/somefile ${ROOT_USER} ${ROOT_GROUP} 0700 両変数の違いは、PERMS のつかない変数の違いとまったく同じです。 15.2. 設定ファイル (個々のパッケージの) 設定ファイルは、パッケージに固有のディレクトリー PKG_SYSCONFDIR にインストールされ、また、インストール時には特別扱いが必要である (ほとんどのことは、pkginstall で自動化されています) という点で、特別です。主に 心がける必要があることは、設定ファイルであるとされたファイルは、インストール時 に、そのファイルがもともと存在しなかった場合に限って、正しい場所 (PKG_SYSCONFDIR 以下のどこか) に自動的にコピーされるということです。同様にして 、設定ファイルにローカルな変更が加わっている場合には、アンインストール時に削除 されません。こうすることで、管理者が独自に変更をおこなっても、その変更が失われ ることがないようにしています。 15.2.1. PKG_SYSCONFDIR はどのように設定されるか 前述のとおり、PKG_SYSCONFDIR 変数は設定ファイルのインストール先を指定します。こ の変数の値は、以下の各変数をもとに設定されます。 * PKG_SYSCONFBASE: 設定ディレクトリーのルートです。指定しなかった場合は $ {PREFIX}/etc となりますが、利用者は好みの場所 (たとえば、 /etc, /etc/pkg な ど) を指すよう上書きすることもできます。パッケージがこの変数を直接使うこと はできません。 * PKG_SYSCONFSUBDIR: PKG_SYSCONFBASE のサブディレクトリーで、構築されたパッケ ージ用の設定ファイルはこの下に置かれます。この変数は、パッケージの Makefile で定義された場合にのみ意味を持ちます (つまり、利用者がカスタマイズすること はできません)。 例としては、Apache のパッケージ www/apache2 をご覧ください。Apache では、設 定ファイルを PKG_SYSCONFBASE のサブディレクトリー httpd/ に置いています。こ の変数は、パッケージの Makefile で設定します。 * PKG_SYSCONFVAR: このパッケージの設定ディレクトリー (PKG_SYSCONFBASE と異な る場合) を保持する変数の名前を指定します。指定しなかった場合は、PKGBASE の 値となります。また、常に PKG_SYSCONFDIR が前につきます。 * PKG_SYSCONFDIR.${PKG_SYSCONFVAR}: PKG_SYSCONFVAR で区別されるパッケージの設 定ファイルをどのディレクトリーに置くかを保持します。 以上の各変数をもとに、pkginstall は PKG_SYSCONFDIR の値を決めます。パッケージが 設定ディレクトリーを参照するには、この PKG_SYSCONFDIR 変数だけを使うことができ ます。この値の設定に使われるアルゴリズムは、基本的には以下のとおりです。 1. PKG_SYSCONFDIR.${PKG_SYSCONFVAR} が設定されている場合は、この値が使われます 。 2. 前項の変数は定義されていないが、 PKG_SYSCONFSUBDIR がパッケージの Makefile で設定されている場合は、 ${PKG_SYSCONFBASE}/${PKG_SYSCONFSUBDIR} が使われま す。 3. 以上の場合以外は、 ${PKG_SYSCONFBASE} に設定されます。 なお、${PKG_SYSCONFDIR} は自動的に OWN_DIRS に追加されることを断っておきます。 この意味については、Section 15.1.1, “ディレクトリーの操作”をご覧ください。た だし、${PKG_SYSCONFDIR} のサブディレクトリーは追加されませんので、 OWN_DIRS ま たは MAKE_DIRS を使って作成する必要があります。 15.2.2. ソフトウェアに設定ファイルの置き場所を教える pkgsrc (とユーザーも) が、設定ファイルを既知の場所に置くことを前提としている場 合は、設定ファイルをインストールする場所を各パッケージに教えてやる必要がありま す。場合によっては、パッケージの Makefile を修正する必要があります。この修正は 、運がよければ、コンフィギュレーションスクリプトに渡すフラグを追加する程度です みます。これは、GNU Autoconf が生成したファイルの場合が該当します。 CONFIGURE_ARGS+= --sysconfdir=${PKG_SYSCONFDIR} なお、ここで指定しているのは、パッケージが設定ファイルを探す必要のある場所であ って、設定ファイルのもともとのインストール先ではありません (困った事に、両者は はっきり区別できませんが)。 15.2.3. インストールの過程を修正する 前述のとおり、pkginstall は設定ファイルを自動的に処理します。つまり、パッケージ 本体側では、 ${PKG_SYSCONFDIR} の内容を直接いじってはいけないことになります。ま ずいことに、多くのソフトウェアのインストール用スクリプトは、そのまま実行すると 、このディレクトリーの内容に手を加えてしまいます。では、この問題を適切に直すに はどうすればいいのでしょうか? パッケージに対して、すべての設定ファイルを examples 階層 share/examples/$ {PKGBASE}/ 以下にインストールするように (ふつうは、手でパッチを当てて) 指示する 必要があります。こうすると、 PLIST はこれらを登録します。また、管理者はインスト ールされたままの設定ファイルを常に使うことができます。 必要な設定ファイルを適切な場所 (つまり、examples 階層の下) に置けば、 pkginstall の枠組は、このファイルを、パッケージのインストール時に $ {PKG_SYSCONFDIR} 以下のファイルを更新するための原本として使うことができます。こ れをおこなうために、 CONF_FILES および CONF_FILES_PERMS の各変数が使われます。 この各変数の書式と使い方は、 Section 15.1.2, “ファイルの操作”でご確認ください 。 mail/mutt パッケージから抜粋した例を以下に掲げます。 EGDIR= ${PREFIX}/share/doc/mutt/samples CONF_FILES= ${EGDIR}/Muttrc ${PKG_SYSCONFDIR}/Muttrc なお、EGDIR 変数は当該パッケージに特有のものであって、それ以外では意味を持たな いことに注意してください。 15.2.4. 設定ファイルの処理をしないようにする 設定ファイルの自動コピーは、パッケージをインストールする前に環境変数 PKG_CONFIG を設定しておけば、おこなうかどうかを切替えることができます。 15.3. システム起動スクリプト システムの起動スクリプトは、OS ごとに決まった場所にインストールする必要があり、 その場所はたいていインストール用のプレフィックス以外の場所にある、という点で、 特別なファイルです。したがって、Section 15.1, “インストール用のプレフィックス 以外の場所にあるファイルとディレクトリー”で説明したのと同じ方法を適用して、同 じ解決法を使うことができます。ただし、 pkginstall では起動スクリプトの処理専用 の仕組みを用意しています。 システムの起動スクリプトが附属するパッケージでは、以下のことをおこなう必要があ ります。 1. スクリプトに .sh サフィックスを付け加えて、 ${FILESDIR} 内に置きます。例と しては、 files ディレクトリーに cupsd.sh がある print/cups パッケージをご覧 ください。 2. スクリプト名から拡張子を抜いたものを RCD_SCRIPTS 変数に追加して、pkginstall がこのスクリプトを処理するようにします。前出の例では以下のようになります。 RCD_SCRIPTS+= cupsd 以上のことをおこなえば、pkginstall は各スクリプトに対して、以下の手順を自動的に おこないます。 1. files ディレクトリー以下の各ファイルに対して、 FILES_SUBST 変数で示されてい る置換をすべて適用します。 2. スクリプトを、files ディレクトリーから examples 階層 ${PREFIX}/share/ examples/rc.d/ にコピーします。なお、この原本ファイルは、PLIST に明示的に登 録する必要があります。 3. 起動スクリプトを examples 階層からシステム全体の起動スクリプト用ディレクト リーにコピーするためのコードを、インストール用スクリプトに追加します。 15.3.1. システム起動スクリプトの処理をしないようにする 設定ファイルの自動コピーは、パッケージをインストールする前に環境変数 PKG_RCD_SCRIPTS を設定しておけば、おこなうかどうかを切替えることができます。な お、起動スクリプトは常に examples 階層 ${PREFIX}/share/examples/rc.d/ にコピー されますが、これはこの変数値の影響を受けません。 15.4. システムユーザーとグループ パッケージのインストール時に、特別なユーザーやグループを作成する必要がある場合 、 pkginstall の枠組を使って作成することができます。 PKG_USERS 変数にユーザーのエントリーを追加すると、ユーザーを作ることができます 。各エントリーは、以下のような書式となります。 user:group ユーザーごとに変数を設定して、ユーザーの属性をさらに詳しく指定することができま す。 PKG_UID.user は、ユーザーの数字の UID です。 PKG_GECOS.user は、ユーザーの 説明またはコメントです。 PKG_HOME.user は、ユーザーのホームディレクトリーで、指 定しなかった場合は /nonexistent となります。 PKG_SHELL.user は、ユーザーのシェ ルで、指定しなかった場合は /sbin/nologin となります。 同様にして、PKG_GROUPS 変数にグループのエントリーを追加すると、グループを作るこ とができます。こちらの書式は以下のようになります。 group PKG_GID.group を定義すると、グループの数字の GID を設定することができます。 もっと前の段階でユーザーやグループを作る必要がある場合は、どの相の直後にユーザ ーやグループを作るかを表すために、 USERGROUP_PHASE を configure または build に 設定することができます。こうした場合は、作られるユーザーやグループの数字の UID や GID は、自動的に最終的なインストール用スクリプトにハードコードされます。 15.5. システムシェル パッケージがシステムシェルをインストールする場合は、管理者の手間を減らせるよう 、インストールしたシェルをシェルデータベース /etc/shells に登録するようにします 。この登録は、どのシステム上でもバイナリーパッケージが機能するようにするため、 インストール用スクリプトでおこなう必要があります。pkginstall では、このことを簡 単に実現できる方法を用意しています。 パッケージがシェルインタープリターを提供する場合は、 PKG_SHELL 変数を、そのシェ ルの絶対ファイル名に設定する必要があります。こうすると、インストール用スクリプ トに、シェル登録処理用のフックを追加します。 shells/zsh から抜粋した例を以下に 掲げますので、ご覧ください。 PKG_SHELL= ${PREFIX}/bin/zsh 15.5.1. シェルの登録をしないようにする シェルインタープリターの自動登録は、管理者が PKG_REGISTER_SHELLS 環境変数を NO に設定すれば、無効化することができます。 15.6. フォント X11 フォントをインストールするパッケージでは、各フォントディレクトリー内のフォ ントの索引であるデータベースファイルを更新することが必要になります。この更新は 、pkginstall の枠組内で簡単におこなうことができます。 パッケージが X11 フォントをインストールする時には、フォントをインストールするデ ィレクトリーを、 FONTS_DIRS.type 変数に列挙する必要があります。この type は、“ ttf”, “type1”, “x11”のいずれかです。こうすると、指定した各ディレクトリーの フォントデータベースファイルを更新するコマンドを実行するフックが、インストール 用スクリプトに追加されます。利便のため、このディレクトリーのパスが相対パスで指 定した場合は、パッケージのインストール用プレフィックスからの相対位置として扱わ れるようになっています。fonts/dbz-ttf から抜粋した例を以下に掲げますので、ご覧 ください。 FONTS_DIRS.ttf= ${PREFIX}/lib/X11/fonts/TTF 15.6.1. フォントデータベースの自動更新をしないようにする フォントデータベースの自動更新は、管理者が PKG_UPDATE_FONTS_DB 環境変数を NO に 設定すれば、無効化することができます。 Chapter 16. オプションの扱い Table of Contents 16.1. 標準の大域的なオプション 16.2. パッケージを変換して bsd.options.mk を使うようにする 16.3. オプション名 16.4. 依存パッケージのオプションを判別する 多くのパッケージは、対応する機能の組合せを変えて構築することができます。 bsd.options.mk は pkgsrc における枠組のひとつで、このようなオプションに応じて異 なるパッケージ構築方法の判断を、汎用的に処理するものです。この枠組のなかで、利 用者は、どのようなオプションの組合せを組み込んでパッケージを構築するかを厳密に 指定したり、大域的な標準状態のオプションの組合せを適用したりすることができます 。 パッケージの振舞を、オプションの枠組を使って制御したい状況は、大きく分けて二つ あります。ひとつは、プログラム自体の構築は常におこなうものの、そのなかのある機 能を有効にするかしないかです (他のパッケージに依存させるかさせないかによって制 御することがよくあります)。もうひとつは、別のプログラムを、そのパッケージの一部 として追加するかしないかです。後者は、一般的には、オプションの枠組を使わずに、 パッケージを分割したほうがいいでしょう。パッケージを分割すれば、バイナリーパッ ケージを別々に追加できるようになるからです。たとえば、foo パッケージには最小限 の (それがないと foo パッケージに何の意味もなくなるような) 依存性を持たせておい たうえで、別の foo-gfoo パッケージに GTK のフロントエンドプログラム gfoo を入れ ておくのです。この方法は、foo パッケージに gfoo を追加する gtk オプションを用意 する方法より、すぐれています。なぜなら、オプションの枠組を使ってしまうと、この オプションが標準で有効な場合は、バイナリーパッケージの利用者は gfoo 抜き版の foo を使えず、また、標準で有効ではない場合は、バイナリーパッケージの利用者は gfoo を使えないからです。パッケージを分割すれば、バイナリーパッケージの利用者は 、 GTK 抜き版の goo をインストールすることも、後から gfoo をインストールする (GTK はそのときになってから取り寄せる) こともできます。また、ソースの利用者にと っても、 foo パッケージの再構築の必要がなくなるという利点があります。 依存性が大きく変化するようなプラグインは、通常は、オプションではなく分割したほ うがよいでしょう。 パッケージを分割すると、保守の手間が増えることがよくあります。そのパッケージの 本家が分割に対応していない場合は特にそうです。分割するかオプションにするかは、 たくさんのパッケージの細切れや、依存パッケージの大きさや、作業量に対して、利用 者がどう思うであろうか、という見地に立って判断するようにします。 さらに考慮が必要なことは、ライセンスです。フリーではない部品や、フリーでないも の (特にプラグイン) に依存する部品は、分割可能な限り分割するのがよいでしょう。 16.1. 標準の大域的なオプション 標準の大域的なオプションは、 PKG_DEFAULT_OPTIONS に列挙します。この値は、そのオ プションに対応しているパッケージすべてに組み込むオプションを並べたものです。こ の変数は mk.conf で設定するようにします。 16.2. パッケージを変換して bsd.options.mk を使うようにする 以下に掲げるのは、bsd.options.mk を架空の ``wibble'' パッケージでどのように使う かを示したものです。パッケージの Makefile に直接書くか、別のファイル options.mk に書いて Makefile からインクルードするか、どちらかの方法をとります。 PKG_OPTIONS_VAR= PKG_OPTIONS.wibble PKG_SUPPORTED_OPTIONS= wibble-foo ldap PKG_OPTIONS_OPTIONAL_GROUPS= database PKG_OPTIONS_GROUP.database= mysql pgsql PKG_SUGGESTED_OPTIONS= wibble-foo PKG_OPTIONS_LEGACY_VARS+= WIBBLE_USE_OPENLDAP:ldap PKG_OPTIONS_LEGACY_OPTS+= foo:wibble-foo .include "../../mk/bsd.prefs.mk" # this package was previously named wibble2 .if defined(PKG_OPTIONS.wibble2) PKG_LEGACY_OPTIONS+= ${PKG_OPTIONS.wibble2} PKG_OPTIONS_DEPRECATED_WARNINGS+= \ "Deprecated variable PKG_OPTIONS.wibble2 used, use ${PKG_OPTIONS_VAR} instead." .endif .include "../../mk/bsd.options.mk" # Package-specific option-handling ### ### FOO support ### .if !empty(PKG_OPTIONS:Mwibble-foo) CONFIGURE_ARGS+= --enable-foo .endif ### ### LDAP support ### .if !empty(PKG_OPTIONS:Mldap) . include "../../databases/openldap-client/buildlink3.mk" CONFIGURE_ARGS+= --enable-ldap=${BUILDLINK_PREFIX.openldap-client} .endif ### ### database support ### .if !empty(PKG_OPTIONS:Mmysql) . include "../../mk/mysql.buildlink3.mk" .endif .if !empty(PKG_OPTIONS:Mpgsql) . include "../../mk/pgsql.buildlink3.mk" .endif 最初の節には、このパッケージがどの構築オプションに対応しているかに関する情報が あり、標準状態を設定する必要があるオプションについてはその設定をしています。 1. PKG_OPTIONS_VAR は、 make(1) 変数の名前で、利用者はその名前の変数を設定して 標準のオプションを上書きすることができます。この変数名は PKG_OPTIONS. pkgbase のように設定します。オプションの処理をする段階では PKGBASE は定義さ れていないので、 PKG_OPTIONS.${PKGBASE} と定義してはいけません。 2. PKG_SUPPORTED_OPTIONS は、このパッケージが対応している構築オプションを並べ たリストです。 3. PKG_OPTIONS_OPTIONAL_GROUPS は、互いに排他的なオプションからなるグループの 名前を並べたリストです。各グループに含まれるオプションは、 PKG_OPTIONS_GROUP.groupname に列挙します。ここでは、各グループのオプション のうちもっとも特徴的な設定を先頭に書きます。各グループに含まれるオプション は、自動的に PKG_SUPPORTED_OPTIONS に追加されます。 4. PKG_OPTIONS_REQUIRED_GROUPS は、 PKG_OPTIONS_OPTIONAL_GROUPS に似ていますが 、グループに含まれるオプションをどれも選ばなかった場合には、パッケージの構 築に失敗する点が異なります。 5. PKG_OPTIONS_NONEMPTY_SETS は、オプションの集合の名前を並べたリストです。各 集合からは、少なくともひとつのオプションを設定する必要があります。各集合に 含まれるオプションは、 PKG_OPTIONS_SET.setname に列挙します。各集合に含まれ るオプションは、自動的に PKG_SUPPORTED_OPTIONS に追加されます。集合に含まれ るオプションをひとつも設定しなかった場合、パッケージの構築に失敗します。 6. PKG_SUGGESTED_OPTIONS は、標準状態で有効となる構築オプションを並べたリスト です。 7. PKG_OPTIONS_LEGACY_VARS は、旧式の mk.conf 変数を同等のオプションに対応づけ た“USE_VARIABLE:option”という組合せを並べたリストです。この組合せは、旧式 の変数の大域的なリストを残すために、“+=”を使って追加するようにします。利 用者が旧式の変数を使った場合には、警告が出ます。 8. PKG_OPTIONS_LEGACY_OPTS は、名前が変更されたオプションを新しいものに対応づ けた“old-option:new-option”という組合せを並べたリストです。この組合せは、 旧名のオプションの大域的なリストを残すために、“+=”を使って追加するように します。利用者が旧名のオプションを使った場合には、警告が出ます。 9. PKG_LEGACY_OPTIONS は、廃止された変数用のオプションを並べたリストです。これ は、PKG_OPTIONS_LEGACY_VARS と PKG_OPTIONS_LEGACY_OPTS のどちらでも対処でき ない場合、たとえば PKG_OPTIONS_VAR の名前が変更された場合などに使うものです 。 10. PKG_OPTIONS_DEPRECATED_WARNINGS は、廃止された変数やオプションが使われたこ とと、その代替として何を使うかについての、警告を並べたリストです。 パッケージ側では PKG_DEFAULT_OPTIONS や、 PKG_OPTIONS_VAR による変数名を変えて はいけません。これらはもっぱら利用者が設定するためのものです。オプションの標準 設定を提案する場合は PKG_SUGGESTED_OPTIONS を使います。 PKG_OPTIONS_VAR は、 bsd.options.mk をインクルードする前に定義する必要がありま す。 PKG_SUPPORTED_OPTIONS, PKG_OPTIONS_OPTIONAL_GROUPS, PKG_OPTIONS_REQUIRED_GROUPS のいずれも定義されていない場合は (実行対象のプラッ トフォームが、プラットフォーム固有のオプションのどれにも対応していない場合に、 これらの影響を受ける可能性があるため)、 PKG_OPTIONS は空のリストに設定され、パ ッケージがオプションの枠組を使わないように保護されます。 bsd.options.mk がインクルードされた後、変数 PKG_OPTIONS は、選択された構築オプ ションを並べたリスト (非対応あるいは廃止されたオプションは適切に除去されていま す) を値として持っています。 残りの節では、各オプション固有の処理をしています。あるオプションが PKG_OPTIONS のリストに含まれているかどうかの確認は、以下のようにするのが正しい方法です。 .if !empty(PKG_OPTIONS:Moption) 16.3. オプション名 異なるパッケージに類似の機能を追加するオプション (あるライブラリーにオプション で対応するなど) は、その機能に対応した全パッケージの間で共通の名前 (そのライブ ラリーの名前など) を使うべきです。同じ意味のオプションをもつパッケージがすでに 存在する場合は、それと同じ名前を使ってください。 ひとつのパッケージに固有の機能を追加するオプションで、他の (無関連の) パッケー ジが同じ (または類似の) オプション機能をもちそうにない場合は、冒頭に pkgname- をつけたオプション名を使うようにします。 一群の関連パッケージの間で、それらに固有のオプション機能を共有している場合は、 “主たる”パッケージ名を冒頭につけた形にします (たとえば djbware-errno-hack)。 新しいオプションを追加する場合は、 mk/defaults/options.description にそのオプシ ョンの行を追加します。行は、タブで区切られた二つのフィールドからなります。最初 のフィールドはオプション名、二つ目はその説明です。この説明は、完全な文章 (大文 字ではじまり、ピリオドで終わる) で、このオプションで何ができるかを説明します。 たとえば、“Enable ispell support.”とします。このファイルはオプション名でソー トします。 16.4. 依存パッケージのオプションを判別する buildlink3.mk ファイルを書くときには、依存パッケージがどのようなオプションで構 築されたかによって場合分けして、異なる依存性を列挙する必要がある場合がよくあり ます。このようなオプションの問い合わせには、 pkgsrc/mk/pkg-build-options.mk フ ァイルを使うようにします。通常は、以下のように使います。 pkgbase := libpurple .include "../../mk/pkg-build-options.mk" .if !empty(PKG_BUILD_OPTIONS.libpurple:Mdbus) ... .endif pkg-build-options.mk をインクルードしたところで、 PKG_BUILD_OPTIONS.libpurple 変数に、 libpurple パッケージの構築オプションが設定されます。これにより、 options.mk における PKG_OPTIONS と同様に、オプションを問い合わせることができま す。詳細は、pkg-build-options.mk ファイルをご覧ください。 Chapter 17. 構築の手順 Table of Contents 17.1. 序 17.2. プログラムの場所 17.3. 構築の過程で使われるディレクトリー 17.4. 相の実行 17.5. fetch 相 17.5.1. 何を、どこから取得するか 17.5.2. ファイルの取得はどのようにおこなわれるか? 17.6. checksum 相 17.7. extract 相 17.8. patch 相 17.9. tools 相 17.10. wrapper 相 17.11. configure 相 17.12. build 相 17.13. test 相 17.14. install 相 17.15. package 相 17.16. 掃除をする 17.17. 他の役に立つターゲット 17.1. 序 本章では、パッケージがどのように構築されるかについて、詳しく説明します。パッケ ージの構築は、複数の相 (phase) (たとえば、fetch, build, install) にわかれており 、そのすべてを以下の各節で説明します。それぞれの段階は、pre-, do-, post- のいず れかが相名の前についた、いわゆる期 (stage) にわかれます。(たとえば、 pre-configure, post-build などです。) 実際に何かがおこなわれるのは、ほとんどが do-* 期においてです。 標準的なターゲット (fetch など) は、決して上書きしないでください。変更する必要 がある場合は、対応する do-* ターゲットを上書きしてください。 プログラムを構築するための基本的な手順は常に同じです。最初に、プログラムのソー スファイル(distfile)をローカルシステムへ持ってきて展開します。コンパイルするた めの pkgsrc 独自のパッチを適用した後に、ソフトウェアを設定し、構築(通常、コンパ イルすることによって)します。最後に作成されたバイナリー等を、システムにインスト ールします。 それぞれの段階で何が起きているかを、もっと詳しく把握するために、 PKG_VERBOSE 変 数を設定することができます。または、patch の段階における詳細に関心があるだけな ら、 PATCH_DEBUG 変数を設定することもできます。 17.2. プログラムの場所 次のセクションでNetBSDパッケージシステムによって実行される手順の概略を述べる前 に、プログラムがインストールされる場所、その場所に影響をおよぼす変数について簡 単に記述します。 自動変数PREFIXは、最終的にプログラムのすべてのファイルがインストールされる場所 をしめします。通常、LOCALBASE (/usr/pkg)、またはcrossカテゴリーのパッケージのた めのCROSSBASEと同じ場所になっています。 PREFIXの値は、プログラムのソース中でこ れらのファイルが符号化されるさまざまな場所に使用されるべきです。詳細に関しては 、Section 11.3, “patches/*”およびSection 19.3.1, “共有ライブラリー - libtool ”を参照して下さい。 これらの変数のどれかを選択し使用する場合には、以下のルールに従ってください。 * PREFIXは常に現在のパッケージがインストールされる場所を指します。パッケージ 自身のインストール先のパスを参照する時に、“${PREFIX}”を使用してください。 * LOCALBASEは、すべての非X11パッケージがインストールされる場所です。他の非X11 パッケージによってインストールされたインクルードファイルやライブラリーの場 所をさがすためのコンパイラーの-Iや-Lオプションを指定する場合に、“$ {LOCALBASE}”を使用してください。 LOCALBASE という変数名は、FreeBSD でパッ ケージをすべて /usr/local にインストールしていたことに由来します。 pkgsrc では /usr/local をシステム管理者のために使わないようにしているので、この変 数名は間違った名前です。 * X11BASEは、実際に(xsrcなどに由来する)X11ディストリビューションがインストー ルされる場所です。通常のX11のインクルードファイル(パッケージとしてインスト ールされていない)をさがす場合、“${X11BASE}”を使用してください。 * X11 ベースのパッケージは特別です。インストールされる場所は、 X11BASE と LOCALBASE のどちらに依存することもありえます。 通常、X11 のパッケージは、できるかぎり LOCALBASE にインストールするものです 。X11 のパッケージでは、X11 が必要なことを要求し、適切な編集フラグを持つよ うにするために、 ../../mk/x11.buildlink3.mk をインクルードする必要がありま す。 しかし、LOCALBASE 以下にはインストールできないパッケージもあります。 app-defaults ファイルが附属するようなパッケージが該当します。このようなパッ ケージは例外であり、X11BASE 以下にインストールする必要があります。そうする ためには、パッケージ側で USE_X11BASE または USE_IMAKE のいずれかを設定しま す。 註: Makefile で USE_IMAKE や USE_X11BASE を定義したパッケージによってインス トールされたインクルードファイルやライブラリーをさがす場合、 ${X11BASE} と ${LOCALBASE} を両方調べる必要があります。 X11 パッケージをすべて強制的に LOCALBASE にインストールさせるために、 pkgtools/xpkgwedge パッケージが標準 で有効になっています。 * X11パッケージのインストール場所を参照する用途には、X11PREFIXを使ってくださ い。X11PREFIXは、xpkgwedgeがインストールされていない場合は X11BASEとなり、 xpkgwedgeがインストールされている場合はLOCALBASEとなります。 * xpkgwedgeがインストールされている場合、パッケージによってインストール先が X11BASEになっていたりLOCALBASEになっていたりすることがあります。インストー ルされているパッケージのprefixを決めるために、EVAL_PREFIX定義を使うことがで きます。この定義に“DIRNAME=”の形式の組を書くと、make(1)変数 DIRNAMEが、インストールされているパッケージ のprefixに設定されます 。そのパッケージがインストールされていない場合は“${X11PREFIX}”に設定され ます。 例を使って説明するのが一番いいでしょう。 以下は、 pkgsrc/wm/scwm/Makefileからの抜粋です。 EVAL_PREFIX+= GTKDIR=gtk+ CONFIGURE_ARGS+= --with-guile-prefix=${LOCALBASE:Q} CONFIGURE_ARGS+= --with-gtk-prefix=${GTKDIR:Q} CONFIGURE_ARGS+= --enable-multibyte EVAL_PREFIXを使って評価するパッケージに対して、以下のような定義を使ってデフ ォルトを定義することができます。 GTKDIR_DEFAULT= ${LOCALBASE} ここでGTKDIRは、 EVAL_PREFIX での最初の定義の組に対応します。 * パッケージは ${PREFIX} 以下に、 hier(7) に準じてファイルをインストールする ようにします。ただしマニュアルページは例外で、${PREFIX}/share/man ではなく ${PREFIX}/man にインストールします。 17.3. 構築の過程で使われるディレクトリー パッケージの構築時には、ソースファイル、一時ファイル、 pkgsrc 内部ファイルなど を置いておくために、さまざまなディレクトリーが使われます。そのようなディレクト リーについて説明します。 ディレクトリーを指す変数のなかには、相対パス名を値に持つものがあります。このよ うな相対パス名の基点となるディレクトリーは、おもに二つあります。一つは PKGSRCDIR/PKGPATH で、pkgsrc 特有のディレクトリー用です。もう一つは WRKSRC で、 パッケージそのものの内部にあるディレクトリー用です。 PKGSRCDIR 絶対パス名で、 pkgsrc のルートディレクトリーを指します。通常は、この変数を 使う必要はありません。 PKGDIR 当該パッケージを指す絶対パス名です。 PKGPATH PKGSRCDIR を基点とした相対パス名で、当該パッケージを指します。 WRKDIR 絶対パス名で、全作業がおこなわれるディレクトリーを指します。 distfile はこ のディレクトリーに展開されます。一般的に、このディレクトリーには、 buildlink や wrappers など、 pkgsrc の各種基盤が使う一時ディレクトリーも含 まれます。 WRKSRC 絶対パス名で、distfile が展開されるディレクトリーを指します。普通は、WRKDIR 直下のサブディレクトリーであり、多くの場合は、このディレクトリーにおける、 唯一の隠されていないディレクトリーエントリーです。この変数は、パッケージの Makefile で変更することができます。 CREATE_WRKDIR_SYMLINK 定義は、 yes または no のいずれかの値をとり、標準状態では no になります。これは、 pkgsrc の個々のパッケージのディレクトリー内に、 WRKDIR へのシンボリックリンクを作成するか否かを示します。 pkgsrc ツリーを読み取り専用 として使いたい場合は、 CREATE_WRKDIR_SYMLINK の値を no にしてください。 17.4. 相の実行 make phase (phase は相の名前) と打てば、その相を実行することができます。こうす ると、その相のために必要な相をすべて自動的に実行します。相を指定しない場合は build 相になります。つまり、あるパッケージのディレクトリーで、引数なしで make を実行すると、パッケージが構築されますが、インストールはされません。 17.5. fetch 相 パッケージの構築の最初の段階は、配布ファイル (distfiles) を、そのファイルを配布 しているサイトから取得することです。これは fetch 相がおこなう仕事です。 17.5.1. 何を、どこから取得するか 単純な場合では、MASTER_SITES で distfile (distfile のファイル名は DISTNAME が使 われます) を取得する URL をすべて定義します。これより複雑な場合については、以下 で説明します。 変数 DISTFILES は、取得する必要のある distfile を並べたリストを指定します。この 値は、標準では ${DISTNAME}${EXTRACT_SUFX} になり、ほとんどのパッケージではあえ て定義する必要がありません。 EXTRACT_SUFX は、標準では .tar.gz になりますが、自 由に変更することができます。なお、標準で定義される distfile に加えて別の distfile が必要な場合は、それを += 演算子を使って追加することはできません。たと えば以下のように書く必要があります。 DISTFILES= ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz 各 distfile は、通常は MASTER_SITES に並べられたサイトから取得されます。パッケ ージに複数の DISTFILES または複数の PATCHFILES があり、それらが異なるサイトで配 布されている場合は、 distfile ファイル (サフィックスを含む) の配布場所の URL を 並べたリストを SITES.distfile に設定することができます。 DISTFILES= ${DISTNAME}${EXTRACT_SUFX} DISTFILES+= foo-file.tar.gz SITES.foo-file.tar.gz= \ http://www.somewhere.com/somehow/ \ http://www.somewhereelse.com/mirror/somehow/ distfile を実際に取得する際、それらは、 MASTER_SITES または SITES.* に各 distfile のファイル名をそのまま (間にスラッシュを入れずに) つなげた形の URL か ら取得されます。このため、サイトを定義する変数の値は、スラッシュその他の分離記 号で終わる必要があります。このため、たとえば MASTER_SITES を、distfile 名を引数 としてとる CGI スクリプトの URL にすることができます。そうした場合、以下のよう な形で定義することになります。 MASTER_SITES= http://www.example.com/download.cgi?file= 例外は、URL の前にダッシュ (-) がついている場合です。この場合、その URL を (distfile とつなげずに) そのまま使って distfile を取得し、取得したファイルを distfile の名前で保存します。 パッケージで使うため、MASTER_SITES 用にあらかじめ定義された値がいくつか用意され ています。各変数の意味は、名前から明らかでしょう。 ${MASTER_SITE_APACHE} ${MASTER_SITE_BACKUP} ${MASTER_SITE_CYGWIN} ${MASTER_SITE_DEBIAN} ${MASTER_SITE_FREEBSD} ${MASTER_SITE_FREEBSD_LOCAL} ${MASTER_SITE_GENTOO} ${MASTER_SITE_GNOME} ${MASTER_SITE_GNU} ${MASTER_SITE_GNUSTEP} ${MASTER_SITE_IFARCHIVE} ${MASTER_SITE_KDE} ${MASTER_SITE_MOZILLA} ${MASTER_SITE_MYSQL} ${MASTER_SITE_OPENOFFICE} ${MASTER_SITE_PERL_CPAN} ${MASTER_SITE_PGSQL} ${MASTER_SITE_R_CRAN} ${MASTER_SITE_SOURCEFORGE} ${MASTER_SITE_SOURCEFORGE_JP} ${MASTER_SITE_SUNSITE} ${MASTER_SITE_SUSE} ${MASTER_SITE_TEX_CTAN} ${MASTER_SITE_XCONTRIB} ${MASTER_SITE_XEMACS} 名前から意味がわかりにくいものについて、説明しておきます。 MASTER_SITE_BACKUP には、ftp://ftp.NetBSD.org/pub/pkgsrc/distfiles/${DIST_SUBDIR} で保守されている 、パッケージのバックアップサイトが含まれます。 MASTER_SITE_LOCAL には、ftp:// ftp.NetBSD.org/pub/pkgsrc/distfiles/LOCAL_PORTS/ で保守されている、パッケージの ローカルなソース配布物が含まれます。 もしこれらの予め定義されたサイトの1つを選んだ場合、そのサイトのサブディレクトリ ーを指定することが必要となるかもしれません。これらのマクロは複数の実際のサイト に展開されるかもしれませんので、サブディレクトリーを指定する場合は、以下の表記 を使わなければなりません: MASTER_SITES= ${MASTER_SITE_GNU:=subdirectory/name/} MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=project_name/} サブディレクトリー名の後のスラッシュ/に注意してください。 17.5.2. ファイルの取得はどのようにおこなわれるか? fetch 相では、distfile がすべてローカルディレクトリー (DISTDIR, pkgsrc 利用者が 設定可能) に存在する状態にします。 distfile は以下の形式のコマンドを使って取得 されます。 ${FETCH_CMD} ${FETCH_BEFORE_ARGS} ${site}${file} ${FETCH_AFTER_ARGS} この ${site} には、複数の候補が決まった順序で使われます: 最初に MASTER_SITE_OVERRIDEを試み、次に、SITES.fileが定義されていればそれを、定義され ていなければ、MASTER_SITESかPATCH_SITESのどちらかを試みます。そして、最後に MASTER_SITE_BACKUPの値を試みます。これらのうち最初のものと最後のもの以外の順序 は、 MASTER_SORT_RANDOM を設定し、かつ MASTER_SORT_AWKか MASTER_SORT_REGEXを設 定して、ユーザーが入れ換えることができます。 この取得用のコマンドと引数は、 FETCH_USING 変数に応じたものが使われます。上述の 例は、FETCH_USING=custom とした場合のものです。 the NetBSD Foundation が運営している distfile のミラーサイトでは、自由に配布可 能な distfile をミラーするために mirror-distfiles ターゲットを使っています。 NO_SRC_ON_FTP を (たいていは“${RESTRICTED}”に) 設定しているパッケージの distfile はミラーされません。 17.6. checksum 相 distfileを取得した後に、チェックサムを生成し、distinfoファイルに保存されたチェ ックサムと比較します。もし、チェックサムが一致しなければ、構築は中断されます。 これはパッケージ作成時と同じdistfileが、構築に使用されていること、つまり、悪意 や一次配布サイトでの意図的な差し替えやネットワークの損失によってdistfileが変更 されていないことを保証するためです。 17.7. extract 相 distfileがローカルシステム上に存在している場合、通常、それらは圧縮アーカイブフ ォーマットで保存されているので、展開する必要があります。 標準では、DISTFILES はすべて展開されます。一部だけを展開する必要がある場合は、 EXTRACT_ONLY 変数を、展開する必要のあるファイルを並べたリストに設定することがで きます。 通常、ファイルの展開は mk/extract/extract という小さなプログラムを使っておこな われます。このプログラムは、各種アーカイブ形式の展開方法を知っているので、何も 変更する必要はないでしょう。それでも変更が必要な場合は、以下の変数を使うとよい でしょう。 EXTRACT_OPTS_{BIN,LHA,PAX,RAR,TAR,ZIP,ZOO} この各変数を使って、展開用のコマンドのオプションを、標準のもの (mk/extract/ extract で定義されています) から上書きします。 EXTRACT_USING この変数は、tar アーカイブ展開用のコマンドを設定するもので、 bsdtar, gtar, nbtar (標準状態での値), pax または、コマンドの絶対パス名に設定することがで きます。 NetBSD の (tar として使われる) pax でうまく展開できない場合は、な るべく gtar より bsdtar を選ぶようにします。 必要なことが extract プログラムではできない場合は、ファイル展開用のコマンドを保 持する EXTRACT_CMD 変数を上書きすることもできます。この変数で指定された展開用コ マンドは、 ${WRKSRC} ディレクトリー内で実行されます。このコマンドの実行中は、シ ェル変数 extract_file に、展開中のアーカイブファイルの絶対パス名が保持されます 。 これでもなお不十分な場合は、パッケージの Makefile で、 do-extract ターゲットを 上書きすることができます。 17.8. patch 相 展開の後で、PATCHFILESで指定されたパッチとパッケージのpatchesサブディレクトリー に存在するパッチ、さらに、$LOCALPATCHES/$PKGPATH (たとえば /usr/local/patches/ graphics/png)に存在するパッチのすべてが適用されます。 .Z、あるいは.gzで終る名前 のパッチファイルは、適用する前に伸張されます。 .orig、.rejで終るものは無視され ます。patch(1)のためのいくつかのオプションは、PATCH_DIST_ARGSで指定する事ができ ます。詳細に関してはSection 11.3, “patches/*”を参照して下さい。 デフォルトでは、パッチに曖昧さがあった場合にはpatch(1)が異常終了するような特別 な引数が渡されます。パッチを修正(再作成)して、きれいに適用できるようにしてくだ さい。そうする理由は、曖昧さがあるパッチが一見うまく適用できても、実は誤った場 所に適用されていて、深刻な問題を起こす可能性があるからです。 17.9. tools 相 この相についてはChapter 18, 構築や実行のために必要なツールで説明しています。 17.10. wrapper 相 この相では、コンパイラーとリンカー用のラッパープログラムが作成されます。以下の 変数を使って、ラッパーに手を加えることができます。 ECHO_WRAPPER_MSG 経過を表示するためのコマンドです。標準状態では何もしません。経過を見るには 、この変数を ${ECHO} に設定します。 WRAPPER_DEBUG この変数は、ラッパーのログファイルにより詳しい情報が必要かどうかに応じて、 yes (標準状態の値) または no に設定することができます。 WRAPPER_UPDATE_CACHE この変数は、ラッパーの速度を改善するためキャッシュを使わせるかどうかに応じ て、 yes または no に設定することができます。標準状態の値は yes ですが、キ ャッシュに対応していないプラットフォームでは強制的に no になります。 WRAPPER_REORDER_CMDS 順序の並び替え用のコマンドを並べたリストです。並び替え用のコマンドは、 reorder:l:lib1:lib2 のような形式をしています。これを使うと -llib1 が常に -l lib2 より先に現れるようになります。 WRAPPER_TRANSFORM_CMDS 変換用のコマンドを並べたリストです。 [TODO: investigate further] 17.11. configure 相 ほとんどのソフトウェアは、実行対象のプラットフォームで利用できるヘッダーファイ ル、システムコール、およびライブラリールーチンについての情報を必要とします。こ の情報の判断はコンフィギュレーションとして知られているプロセスであり、通常、自 動化されています。大抵の場合、スクリプトが配布物と一緒に提供され、それを実行す ることによりヘッダーファイルやMakefile等が生成されます。 パッケージが configure スクリプトを含んでいる場合、HAS_CONFIGURE を“yes”に設 定することにより、実行することができます。もし、その configure スクリプトが GNU の autoconf スクリプトである場合は、かわりに、GNU_CONFIGURE を“yes”に指定して ください。大雑把にいうと、configure 相では以下のようなことをしています。 .for d in ${CONFIGURE_DIRS} cd ${WRKSRC} \ && cd ${d} \ && env ${CONFIGURE_ENV} ${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS} .endfor CONFIGURE_DIRS (標準では“.”) は、 WRKSRC からの相対位置でのパス名を並べたリス トです。この各ディレクトリー内で、環境変数 CONFIGURE_ENV および引数 CONFIGURE_ARGS を使って configure スクリプトが実行されます。 CONFIGURE_ENV, CONFIGURE_SCRIPT (標準では“./configure”), CONFIGURE_ARGS の各変数は、いずれも パッケージ側で変更することができます。 もし、プログラムがコンフィギュレーションのために Imakefile を使用するのであれば 、USE_IMAKE を“yes”に設定することにより、適切な手順が実行されます。 (もし、$ {X11PREFIX} にインストールされるパッケージが欲しいだけで、xmkmfを実行したくない 場合、かわりにUSE_X11BASEを使用してください。) SCRIPTS_ENV に変数を設定すると、 その変数を xmkmf の環境変数に追加することができます。 プログラムがコンフィギュレーションのために cmake を使用するのであれば、 USE_CMAKE を“yes”に設定することにより、適切な手順が実行されます。 CONFIGURE_ENV に変数を追加すると、その変数を cmake の環境変数に追加することがで きます。また、CMAKE_ARGS 変数に引数を追加すると、 cmake の引数に追加することが できます。最上層ディレクトリーを指定する引数は CMAKE_ARG_PATH 変数で与えられる ようになっており、この変数の標準の値は“.” (CONFIGURE_DIRS からの相対位置) で す。 configure の段階ですることが何もない場合は、 NO_CONFIGURE を“yes”に設定します 。 17.12. build 相 パッケージの構築は、大雑把にいえば、以下のコードを実行するのと同じことです。 .for d in ${BUILD_DIRS} cd ${WRKSRC} \ && cd ${d} \ && env ${MAKE_ENV} \ ${MAKE_PROGRAM} ${BUILD_MAKE_FLAGS} \ -f ${MAKE_FILE} \ ${BUILD_TARGET} .endfor BUILD_DIRS (標準では“.”) は、 WRKSRC からの相対位置でのパス名を並べたリストで す。この各ディレクトリー内で、環境変数 MAKE_ENV および引数 BUILD_MAKE_FLAGS を 使って MAKE_PROGRAM が実行されます。 MAKE_ENV, BUILD_MAKE_FLAGS, MAKE_FILE, BUILD_TARGET の各変数は、いずれもパッケージ側で変更することができます。 MAKE_PROGRAM の標準の値は、 USE_TOOLS に“gmake”が含まれている場合は“gmake” 、含まれていない場合は“make”です。 MAKE_FILE の標準の値は“Makefile”であり、 BUILD_TARGET の標準の値は“all”です。 build の段階ですることが何もない場合は、 NO_BUILD を“yes”に設定します。 17.13. test 相 [TODO] 17.14. install 相 構築の段階が完了すると、ユーザーが構築されたプログラムやファイルを使えるように するため、ソフトウェアをパブリックなディレクトリーにインストールする必要があり ます。 install 相は、大雑把にいえば、以下のコードを実行するのと同じことです。これに加 えて、このコードの前後では、整合性の検査やパッケージの登録などをするため、多く の操作がおこなわれます。 .for d in ${INSTALL_DIRS} cd ${WRKSRC} \ && cd ${d} \ && env ${MAKE_ENV} \ ${MAKE_PROGRAM} ${INSTALL_MAKE_FLAGS} \ -f ${MAKE_FILE} \ ${INSTALL_TARGET} .endfor 各変数の意味は、build 相のものと同様です。 INSTALL_DIRS は標準では BUILD_DIRS です。INSTALL_TARGET は標準では“install”ですが、 USE_IMAKE が定義されており、 かつ NO_INSTALL_MANPAGES が定義されていない場合は、“install.man”が追加されま す。 install 相では、以下の変数が有用です。これらはいずれも install(1) コマンドの変 種であり、所有者、所有グループ、パーミッションをあらかじめ決めてあるものです。 INSTALL は、オプションを何も指定しない install コマンドです。用途別に特化した変 種には、以下のものがあります。 INSTALL_PROGRAM_DIR バイナリーを含むディレクトリー INSTALL_SCRIPT_DIR スクリプトを含むディレクトリー INSTALL_LIB_DIR 共有静的ライブラリーを含むディレクトリー INSTALL_DATA_DIR データファイルを含むディレクトリー INSTALL_MAN_DIR マニュアルページを含むディレクトリー INSTALL_PROGRAM デバッグ用シンボルを取り除くことのできるバイナリー INSTALL_SCRIPT シンボルを取り除くことのできないバイナリー INSTALL_GAME ゲームのバイナリー INSTALL_LIB 共有静的ライブラリー INSTALL_DATA データファイル INSTALL_GAME_DATA ゲーム用のデータファイル INSTALL_MAN マニュアルページ これらのほか、以下の変数があります。 INSTALLATION_DIRS pkgsrc が install 相の最初に作成するディレクトリーを PREFIX からの相対位置 表記で並べたリストです。パッケージは、ファイルをインストールする前に、必要 なディレクトリーをすべて自力で作成することになるので、その他のディレクトリ ーをすべてここに列挙します。 稀な場合として、パッケージが何もインストールしないような場合は、 NO_INSTALL を “yes”に設定します。これはほとんどの場合、regress カテゴリーのパッケージに関す るものです。 17.15. package 相 install 期が完了すると、インストールされたファイルからなるバイナリーパッケージ を作ることができます。このようなバイナリーパッケージは、たとえば make bin-install するか、 pkg_add を使って、それまでのコンパイルの過程を踏まずに、迅 速にインストールすることができます。 標準では、バイナリーパッケージは ${PACKAGES}/All に作られ、また、 CATEGORIES 変 数に設定されたカテゴリーごとに ${PACKAGES}/category にシンボリックリンクが作ら れます。PACKAGES は標準では pkgsrc/packages になります。 17.16. 掃除をする パッケージの作業が終わったら、make clean を実行して作業ディレクトリーを掃除する ことができます。依存パッケージの作業ディレクトリーもすべて掃除したい場合は、 make clean-depends を使います。 17.17. 他の役に立つターゲット pre/post-* 前のセクションで述べた主ターゲットのために、二つの補助ターゲットが存在しま す。これは主ターゲットに“pre-”や“post-”というプレフィックスをつけたもの です。これらのターゲットは、特別な設定やインストール手順のために、主ターゲ ットが実行される前や後に、パッケージの Makefile から実行されます。例えば、 プログラムのコンフィギュレーションスクリプトやインストールターゲットが省略 された場合に有用です。 do-* 主なターゲットがおかしな動作をし、それを修正するための変数が存在しない場合 、do-*ターゲットを使用することにより、それらを再定義することができます (do-*ターゲットのかわりに、ターゲット自体を再定義してはいけません。pre-* や post-*ターゲットが実行されなくなってしまいます)。通常、再定義する必要はあり ません。 reinstall もし、make install実行後に、いくつかのファイルがきちんとインストールされな かった事に気がついた場合、このターゲットを使い、再びインストールする事がで きます。この場合、“インストール済み”フラグは無視されます。 これは、DEPENDS_TARGET の標準の値です。ただし make update および make package の場合は例外であり、これらについてはそれぞれ“package”および“ update”が標準の値になります。 deinstall このターゲットは、パッケージをアンインストールするためにカレントディレクト リーでpkg_delete(1)を実行します。動作を制御するために、以下の変数を使用する ことができます。 PKG_VERBOSE pkg_delete(1)コマンドに「-v」オプションを渡します。 DEINSTALLDEPENDS 指定されたパッケージに必要な(依存する)すべてのパッケージを削除します。 このターゲットは、指定されたパッケージによってインストールされたパッケ ージを削除するために使用されます。例えば、make deinstall DEINSTALLDEPENDS=1がpkgsrc/x11/kdeで実行された場合、KDE全体を削除します 。pkg_delete(1)のコマンドラインに“-R”を指定すると設定されます。 bin-install バイナリーパッケージを、ローカルディスクまたは列挙された FTP サイト (BINPKG_SITES 変数を参照) からインストールし、利用可能なバイナリーパッケー ジがどこにもない場合には make package をおこないます。 pkg_add 用の引数、た とえば饒舌な操作などを BIN_INSTALL_FLAGS に設定することができます。 update このターゲットは、現在のパッケージを最新のものに更新します。最初にパッケー ジと、それに依存するすべてのパッケージをアンインストールします。それから最 新のバージョンのパッケージをコンパイル、インストールします。これは、現在ど のパッケージがインストールされているかを調べ、make deinstall、 make install (または、UPDATE_TARGETで設定されたターゲット)を続けて実行するのと同じです。 以前に実行したmake updateがさまざまな理由で中断された場合、パッケージの更新 のために、このターゲットを使用することができます。ただし、この場合は、make cleanを実行していない事、あるいはWRKDIRの依存パッケージのリストを削除してい ない事を確認してください。そうでなければ、インストール済みの依存パッケージ を使用し、現在のパッケージを自動更新することができません。 中断されたmake updateの再開は、パッケージツリーの他の部分が変更されていない 場合に限って動作します。更新対象のパッケージのソースコードが変更されていた 場合は、make updateの再開はきっと失敗するでしょう。 make updateの動作を変更するために、以下の変数をコマンドライン、または mk.confで使うことができます。 UPDATE_TARGET 更新されたパッケージや依存パッケージのために再帰的に使用されるインスト ールターゲット。 make update用のデフォルトは、DEPENDS_TARGETが設定され ている場合はその値、それ以外の場合は“install”です。これら以外のターゲ ットのよい例としては“package”や“bin-install”があります。ここで“ update”を設定してはいけません (無限ループに陥ってしまいます)。 NOCLEAN 更新した後、きれいに掃除をしません。調査やその他の目的のために、更新さ れたパッケージの作業用ソース等をそのままにしておきたい場合に役に立ちま す。最終的にはソースツリーを掃除してください(以下の“clean-update”ター ゲットを見てください)。そうしなければ、次回の makeやmake updateの時に古 いソースコードが残っていることでトラブルがおこるかもしれません。 REINSTALL インストール(make DEPENDS_TARGET)の前に各パッケージをアンインストールし ます。これは、make updateの実行中断後に“clean-update”ターゲット (以下 参照)が呼ばれた場合に必要となることがあります。 DEPENDS_TARGET 再帰を無効化し、パッケージのターゲットをハードコードすることができます 。updateターゲット用のデフォルトは“update”であり、事前に必要なパッケ ージを再帰的に更新するようになっています。DEPENDS_TARGETを設定するのは 、再帰的な更新を無効化したいときだけにしてください。make update (後述し ます)の最中にインストールされる各パッケージに対して、特定のターゲットを 指定するだけの場合は、これのかわりにUPDATE_TARGETを使ってください。 clean-update カレントディレクトリーでmake updateが実行された時に更新されるすべてのパッケ ージのソースツリーを掃除します。カレントパッケージ(あるいは、依存パッケー ジ)がすでにアンインストールされている(例えばmake updateを実行した後)場合に は、このターゲットを使ってはいけません。もし使用すると、更新するつもりのパ ッケージのいくつかを失う可能性があります。経験的には、初めてmake updateを実 行する前、あるいは汚れたパッケージツリーがある場合(例えばNOCLEANを使用した 場合)にのみ使用するとよいでしょう。 パッケージのツリーが掃除されているかどうかわからない場合は、ツリーの最上層 でmake cleanを実行するか、更新しようとしているパッケージのディレクトリーで 以下のコマンドをこの順に使うか、どちらかをおこなうことができます。 (make updateを初めて実行するより前におこなってください。それ以外の場合、更新しよ うとしているパッケージをすべて失ってしまいます) # make clean-update # make clean CLEANDEPENDS=YES # make update make clean-updateの動作を変更するために、以下の変数をコマンドライン、または mk.confで使うことができます。 CLEAR_DIRLIST make cleanの後で、パッケージのためのディレクトリーのリストを再構築しま せん。make updateで、更新したいすべてのパッケージがインストールされた場 合にのみ使用してください。通常、これはmake updateで自動的に実行されます 。ただし、NOCLEAN変数の設定によって実行されない事もあります(上を参照し てください)。 replace 当該パッケージのインストールを更新します。依存するパッケージの置き換えをお こなわないという点で update と異なります。このターゲットを動作させるために は、pkgtools/pkg_tarup をインストールする必要があります。 このターゲットは注意して使ってください。このターゲットを使って更新した後に 、依存するパッケージが動作するという保証はありません。特に、ライブラリーの パッケージで、共有ライブラリーのメジャーバージョンが変わるようなものを make replace した場合は、ほぼ確実に壊れます。このため、このターゲットは公式には サポートされておらず、熟練した利用者だけが使うことを推奨します。 info このターゲットは、現在のパッケージに対してpkg_info(1)をおこないます。これを 使って、インストールされているパッケージのバージョンを調べることができます 。 index これは最上層用のコマンド、つまり pkgsrc ディレクトリーで使うコマンドです。 ローカルの pkgsrc ツリー内の全パッケージのデータベースを作成します。このデ ータベースには、依存性、コメント、メンテナー、その他の有用な情報が含まれま す。個々のパッケージのエントリーは、当該パッケージのディレクトリーで make describe を実行して作成されます。作成された索引ファイルは pkgsrc/INDEX に保 存されます。この索引は、make print-index を実行すると、饒舌な形式で表示する ことができます。 make search key=something を使って、索引を検索することがで きます。 make show-deps PKG=somepackage を実行して、特定のパッケージに依存 するパッケージをすべて調べることができます。 このコマンドの実行には、非常に長い時間がかかります。速いマシンでも数時間か かるでしょう。 readme このターゲットは、 README.htmlファイルを作成します。このファイルは www/ firefoxや www/linksのようなブラウザーで閲覧することができます。作成されたフ ァイルは、ローカルホストの PACKAGESディレクトリーにあるパッケージへの参照を 含んでいます。また、 FTP_PKG_URL_HOSTとFTP_PKG_URL_DIRを元にしたURLを参照さ せることもできます。例えば、ローカルマシン上の/usr/packagesディレクトリーの バイナリーパッケージを参照するREADME.htmlファイルを作成したい場合、 FTP_PKG_URL_HOST=file://localhostとFTP_PKG_URL_DIR=/usr/packagesをセットし てください。${PACKAGES}ディレクトリーと、そのサブディレクトリーはすべてのバ イナリーパッケージで検索されます。 このターゲットは、最上層またはカテゴリーのディレクトリーで実行することもで きます。そうした場合は、配下のパッケージに対して再帰的に実行されます。 readme-all これは最上層用のコマンドであり、pkgsrc で実行します。このターゲットを使い、 README-all.htmlを作成することができます。このファイルはNetBSDパッケージコレ クションの中の、現在利用可能なすべてのパッケージのリスト、また、それらが属 するカテゴリーと簡単な説明を含んでいます。このファイルはpkgsrc/*/ README.htmlから作りだされます。したがって、make readme の後に、このターゲッ トを実行してください。 cdrom-readme これは“readme”ターゲット(上を見てください)とほとんど同じですが、CD-ROMに 焼かれるpkgsrcツリーを作る時に使われます。また、このターゲットは README.htmlファイルを作成し、CDROM_PKG_URL_HOSTとCDROM_PKG_URL_DIRに基づく URLへの参照を作ります。 show-distfiles このターゲットは、パッケージを構築するために、どのdistfileやパッチファイル が必要か (ALLFILES: DISTFILESおよびPATCHFILESをすべて含みますが、 patches/* は含みません) を表示します。 show-downlevel このターゲットは、パッケージがインストールされていない場合は何も表示しませ ん。もし、あるバージョンのパッケージがインストールされているが、現在の pkgsrcのバージョンでインストールされたものでない場合、警告メッセージを表示 します。このターゲットは、インストール済みのパッケージが古いバージョンであ り、そのバージョンが削除可能で、最新の物が追加されることを表示するために使 用されます。 show-pkgsrc-dir 当該パッケージの構築とインストールが可能な、パッケージ階層におけるディレク トリーを表示します。このディレクトリーは、そのパッケージがインストールされ た際のディレクトリーと同じとは限りません。このターゲットは、単一ホスト上で 多数のパッケージの更新をしたい場合に使うためのもので、pkgsrc の最上層の Makefileから“show-host-specific-pkgs”ターゲットで呼び出すことができます。 show-installed-depends このターゲットは、インストールされているパッケージのうち、どれが当該パッケ ージのDEPENDSと合致するかを表示します。依存関係が古いせいで構築に問題が起き る場合に便利です。 check-shlibs パッケージのインストール後に、すべてのバイナリーおよび(ELFプラットフォーム では) 共有ライブラリーが必要な共有ライブラリーを見つけられるかどうか確認し ます。mk.confでPKG_DEVELOPERが設定されている場合はデフォルトで実行します。 print-PLIST パッケージを新規に、または更新のために“make install”した後、 find -newer work/.extract_doneをもとに新しいPLISTを生成して表示します。PLIST生成は、共 有ライブラリーなどに配慮して行われますが、生成した結果をPLISTに置く前に再確 認するよう強くおすすめします。パッケージ更新時には、このコマンドの出力と、 更新前のPLISTファイルとを比較すると便利でしょう。 パッケージが、tar(1)その他のファイルのアクセス時刻を更新しない方法を使って ファイルをインストールする場合は、それらのファイルはこのターゲットで使われ る“find -newer”コマンドで検出されないので、手でPLISTに書き足すよう注意し てください! このターゲットに関するさらなる情報は、 Section 13.3, “make print-PLIST の 出力を細工する”を参照してください。 bulk-package バルクビルドの実行に使われます。適切なバイナリーパッケージがすでに存在する 場合は、何もしません。そうでない場合は、コンパイル、インストール、パッケー ジ作成をおこないます (PKG_DEPENDSが適切に設定されている場合は、依存するパッ ケージも。Section 7.3.1, “設定”参照)。バイナリーパッケージ作成後、ディス クの空き領域を確保するために、ソース、インストールしたばかりのパッケージと 依存パッケージは削除されます。 このターゲットを使うと、システムにインストールされているパッケージをすべて アンインストールすることもあるので、注意してください。 bulk-install 依存パッケージ群をインストールするためのバルクインストールで使われます。最 新のバイナリーパッケージが利用可能な場合、pkg_add(1)でそれをインストールし ます。そうでない場合は、make bulk-packageが実行されますが、インストールされ たバイナリーは削除されません。 バイナリーパッケージが“最新”であるとみなされる (pkg_add(1) でインストール される) 条件は、以下のとおりです。 * パッケージファイル (Makefile, ...)が、いずれも構築時から変更されていな いこと。 * そのパッケージが依存している(バイナリー) パッケージが、いずれも構築時か ら変更されていないこと。 このターゲットを使うと、システムにインストールされているパッケージをすべて アンインストールすることもあるので、注意してください。 Chapter 18. 構築や実行のために必要なツール Table of Contents 18.1. pkgsrc 構築用のツール 18.2. パッケージが必要とするツール 18.3. プラットフォーム附属のツール 18.4. ツールに関する質問 USE_TOOLS 定義は、パッケージを構築するためにどのコマンドが必要か (BUILD_DEPENDS のように)、あるいは、インストールしたパッケージを実行するためにどのコマンドが必 要か (DEPENDS のように) を定義するために、 pkgsrc 内部で使われており、また、個 々のパッケージ用としても使われています。適当なツールがシステムに標準で附属して いれば、多くの場合は pkgsrc のパッケージは使われません。 パッケージを構築するときは、実行検索パスの前のほうにあるディレクトリーに、代替 ツールが (シンボリックリンクまたはラッパースクリプトとして) 用意されます。 buildlink システムと同様に、こうすることで、首尾一貫した構築ができるようになり ます。 あるツールは、パッケージの構築を補助するために必要となることがあります。たとえ ば、perl, GNU make (gmake), yacc はこのために必要になることがあります。 また、あるツールは、たとえば、システム標準附属のツールでは pkgsrc によるパッケ ージの構築用としては使い物にならないために、必要となることがあります。たとえば 、パッケージが GNU awk, (yacc ではなく) bison や、より優れた sed を必要とするこ とがあります。 パッケージが使うツールの実体は、 make show-tools を実行すると一覧表示されます。 18.1. pkgsrc 構築用のツール pkgsrc が標準状態で使うツール一式は、 bsd.pkg.mk で定義されています。ここには、 cat, awk, chmod, test などのような標準的な Unix のツールが含まれています。これ らは make show-var VARNAME=USE_TOOLS を実行すると見ることができます。 個々のパッケージの構築のためにあるプログラムが必要な場合は、 USE_TOOLS 変数を使 って必要なツールを定義することができます。 18.2. パッケージが必要とするツール 以下の例では、:pkgsrc は、構築時依存性として、ネイティブのバージョンではなく pkgsrc のバージョンを使うことを意味します。また、:run は、実行時依存性としても 使うことを意味します (ので、DEPENDS になります)。このようなものを付けない場合は 、構築時依存性を意味します。これは :build を明示的に使って設定することもできま す。 (このため、以下の例のものは、それぞれ gmake:build および pkg-config:build と同じことです。) USE_TOOLS+= mktemp:pkgsrc USE_TOOLS+= gmake perl:run pkg-config このツールの枠組を使う時には、 TOOLS_PATH.foo 変数が、適切なツールへのフルパス として定義されます。たとえば、TOOLS_PATH.bash は Linux システム上では“/bin/ bash”になったりするでしょう。 実行時に常に pkgsrc バージョンのツールが必要となる場合は、この枠組ではなく、単 に DEPENDS を使ってください。 18.3. プラットフォーム附属のツール pkgsrc の改良、あるいは新プラットフォームへの移植をする時には、 pkgsrc/mk/tools /tools.${OPSYS}.mk 以下にある、対象プラットフォーム用の make file の断片を見て (あるいは作って) ください。このファイルでは、たとえば以下のように、共通的に使う ツールの名前を定義しています。 .if exists(/usr/bin/bzcat) TOOLS_PLATFORM.bzcat?= /usr/bin/bzcat .elif exists(/usr/bin/bzip2) TOOLS_PLATFORM.bzcat?= /usr/bin/bzip2 -cd .endif TOOLS_PLATFORM.true?= true # shell builtin 18.4. ツールに関する質問 18.4.1. 新しいツールを追加する方法は? 18.4.2. 利用可能なツールの全一覧を見る方法は ? 18.4.3. あるパッケージの構築に使われているツールの全一覧を見る方法は? sed が使 われているかどうかを知りたいんだけど。 18.4.1. 新しいツールを追加する方法は? TODO 18.4.2. 利用可能なツールの全一覧を見る方法は ? TODO 18.4.3. あるパッケージの構築に使われているツールの全一覧を見る方法は? sed が使 われているかどうかを知りたいんだけど。 今のところ、できません。 (TODO: が、できるようにしたいと考えています。) Chapter 19. パッケージを動くようにする Table of Contents 19.1. 一般的な操作 19.1.1. パッケージの移植性 19.1.2. mk.conf から利用者が設定可能な変数を捕まえる方法 19.1.3. ユーザーとの対話 19.1.4. ライセンスの処理 19.1.5. 制限つきパッケージ 19.1.6. 依存性の処理 19.1.7. 他のパッケージとの衝突の処理 19.1.8. 構築することができない、あるいはすべきでないパッケージ 19.1.9. 一旦インストールしたら削除すべきでないパッケージ 19.1.10. セキュリティー問題を持つパッケージへの対処 19.1.11. 既存パッケージ修正時に、バージョンを上げるにはどうするか 19.1.12. パッケージのファイル中の各種テキストを置換する (SUBST の枠組) 19.2. fetch 相での問題を修正する 19.2.1. distfileのダウンロードが単純にできないパッケージ 19.2.2. '古い'名前のまま更新されたdistfileの取り扱い 19.3. configure 相での問題を修正する 19.3.1. 共有ライブラリー - libtool 19.3.2. すでにlibtoolをサポートしているGNUパッケージでlibtoolを使う 19.3.3. GNU Autoconf/Automake 19.4. プログラミング言語 19.4.1. C, C++ および Fortran 19.4.2. Java 19.4.3. perl スクリプトを含むパッケージ 19.4.4. 他のプログラミング言語 19.5. build 相での問題を修正する 19.5.1. C および C++ のコードの条件つきコンパイル 19.5.2. コンパイラーのバグへの対処方法 19.5.3. undefined reference to “...” 19.5.4. メモリーが不足する 19.6. install 相での問題を修正する 19.6.1. 必要なディレクトリーを作成する 19.6.2. ドキュメンテーションのインストール場所 19.6.3. 最高得点ファイルをインストールする 19.6.4. パッケージを DESTDIR に対応させる 19.6.5. その他のインタープリターへのパスがハードコードされているパッケージ 19.6.6. perl モジュールをインストールするパッケージ 19.6.7. infoファイルをインストールするパッケージ 19.6.8. マニュアルページをインストールするパッケージ 19.6.9. GConf のデータファイルをインストールするパッケージ 19.6.10. scrollkeeper/rarian のデータファイルをインストールするパッケージ 19.6.11. X11 のフォントをインストールするパッケージ 19.6.12. GTK2 のモジュールをインストールするパッケージ 19.6.13. SGML または XML のデータをインストールするパッケージ 19.6.14. MIME データベースの拡張をインストールするパッケージ 19.6.15. intltool を使うパッケージ 19.6.16. 起動スクリプトをインストールするパッケージ 19.6.17. TeX モジュールをインストールするパッケージ 19.6.18. エミュレーションによるバイナリーの実行に対応したパッケージ 19.6.19. ハイカラーテーマのアイコンをインストールするパッケージ 19.6.20. デスクトップファイルをインストールするパッケージ 19.7. パッケージに問題があるという印をつける 19.1. 一般的な操作 19.1.1. パッケージの移植性 pkgsrc の目玉の一つは、多くのプラットフォームで動作することです。そのため、 pkgsrc のパッケージの移植性をできるかぎり高めることが重要になります。本章では、 pkgsrc の作業に際して、注意が必要となる具体的な事項を説明します。 19.1.2. mk.conf から利用者が設定可能な変数を捕まえる方法 pkgsrc の利用者は、MAKECONF によって参照されるファイル (標準では mk.conf) でい くつかの変数を上書きして、pkgsrc の設定をすることができます。このような変数を make(1) のプリプロセッサーディレクティブ (たとえば .if や .for) の内部で使いた い場合は、利用者の設定が読み込まれる場所より前で ../../mk/bsd.prefs.mk をインク ルードする必要があります。 しかし、変数によっては、まだ定義されていない変数への参照を含んでいることがある ために、 ../../mk/bsd.prefs.mk をインクルードした後では完全に定義することができ ないものがあります。シェルコマンドの場合は、変数の実態はマクロであり、使われる ときにしか展開されないので、このことは問題にはなりません。ただし、前述したプリ プロセッサーディレクティブの内部や、依存性を記した行 (target: dependencies のよ うな形式の行) においては、読み込み時に変数が展開されます。 Note 各変数が読み込み時に使用可能か、実行時にのみ使用可能かを網羅した一覧は、現在の ところありませんが、準備をしているところです。 19.1.3. ユーザーとの対話 時々、パッケージがユーザーとの対話を必要とする場合がありますが、そのような状況 は何通りもありえます: * distfile の取得時に、パッケージによっては、ユーザー名とパスワードの入力や web ページ上のライセンスへの同意のような、利用者の対話を必要とするものがあ ります。 * distfile の展開時に、パッケージによってはパスワードを要求することがあります 。 * パッケージの構築前の設定の補助 * 構築過程の最中の補助 * パッケージのインストール中の補助 どの段階で対話が必要になるかをpkgsrcの機構に知らせるため、 INTERACTIVE_STAGE 定 義が用意されており、パッケージのMakefileで定義します。たとえば以下のようにしま す。 INTERACTIVE_STAGE= build 複数の段階を指定することもできます: INTERACTIVE_STAGE= configure install 利用者は、BATCH 変数を設定して、この定義がおこなわれているパッケージをとばすこ とができます。 19.1.4. ライセンスの処理 ソフトウェアの作者は、そのソフトウェアをどのようなライセンスのもとでコピーする ことができるかを、定めることができます。これは著作権法にもとづくことであって、 ライセンス選択の理由は pkgsrc システムの範疇外です。pkgsrc システムでは、ライセ ンスのなかには、従うことに不服だったり、従うことが困難あるいは不可能だったりす る利用者がいるようなライセンスがたくさんあることを認識しています。 Free Software Foundation ではいくつかのライセンスに対して、それが「自由」なライセン スであると表明していますし、 Open Source Initiative では「オープンソース」を定 義しています。 pkgsrc では、ライセンスが「自由」あるいは「オープンソース」であ るといった目印をパッケージにつけたりはしないという方針をとっています。ただし、 これらの定義にあてはまらないライセンスをもつパッケージには、ライセンスについて 記した目印がついています。なお、ライセンスでコピーを認めていないパッケージは、 明らかに、「自由」にも「オープンソース」にも該当しません。 「自由」でも「オープンソース」でもないパッケージについては、構築してよいという ことを、個々のライセンスについて利用者が pkgsrc に指定しておかない限り、 pkgsrc はパッケージを構築しません。なお、このドキュメンテーションでは、「ライセンスに 同意する」 ("accepted the license") という言いまわしを避けています。 pkgsrc シ ステムは、単に、フリーでないライセンスのソフトウェアを誤って構築してしまうこと がないようにする仕組みを提供しているだけです。判断や責任は、利用者に委ねていま す。 (現在のところ、バイナリーパッケージのインストールは、この仕組みの対象外で す。これはバグです。) BSD ライセンスと GPL のパッケージだけをインストールし、それ以外はインストールし たくない、ということがあるかもしれません。標準状態では、フリーなライセンスが ACCEPTABLE_LICENSES 変数に列挙されています。 ACCEPTABLE_LICENSES 変数を "+=" で はなく "=" を使って設定すれば、どのライセンスを許容するかを利用者が上書きできま す。標準状態で許容されているライセンスは以下のとおりです。 public-domain gnu-gpl-v2 gnu-lgpl-v2 gnu-gpl-v3 gnu-lgpl-v3 original-bsd modified-bsd x11 apache-2.0 cddl-1.0 open-font-license ライセンスの目印の仕組みは、パッケージの構築、インストール、および使用にまつわ る著作権関連の問題を処理するためのものであって、再配布にまつわる問題 (RESTRICTED および NO_SRC_ON_FTP などを参照) のためのものではありません。再配布 に制限のあるパッケージには、これらの変数を使って再配布に制限があることを示す必 要があります。 パッケージのコピーが特殊なライセンスのもとで認められていることを示すには、その ライセンスを pkgsrc/licenses に置いたうえで、 LICENSE 変数をライセンスを特定す る文字列に設定します。たとえば、graphics/xv では以下のようになります。 LICENSE= xv-license 構築しようとすると、利用者はそのパッケージに適用されているライセンスが ACCEPTABLE_LICENSES 変数に設定されていないことを知らされます。 % make ===> xv-3.10anb9 has an unacceptable license: xv-license. ===> To view the license, enter "/usr/bin/make show-license". ===> To indicate acceptance, add this line to your /etc/mk.conf: ===> ACCEPTABLE_LICENSES+=xv-license *** Error code 1 ライセンス自体は make show-license すると見ることができます。そのライセンスのも のを構築してよい場合は、 pkgsrc が今後はそのライセンスを理由に構築をやめないよ うに、上の表示中で指示されている行を mk.conf に追加することができます。 ACCEPTABLE_LICENSES+=xv-license 新しいライセンスが適用されているパッケージを追加する場合、表示用のライセンスの テキストを pkgsrc/licenses に追加します。既知のライセンスの一覧は、このディレク トリーで見ることができます。 ライセンスが (整形以外で) 変更された場合は、必ず、新しいライセンスの名前を以前 のものと別の名前にします (たとえば、バージョン番号があればそれを、なければ日付 を末尾につけるなど)。これは、前バージョンのライセンスのもとにあるプログラムを構 築することを pkgsrc に指示している利用者が、新しいライセンスのもとにあるプログ ラムを構築しないようにするためです。もっと高度な点でいうと、 pkgsrc はライセン スの相当性を評価しません。すなわち、個々のライセンスのテキストを、二組織のいず れかが (「自由」あるいは「オープンソース」であると) 認めているかどうかという、 機械的な検査をしているだけなのです。 LICENSE=shareware や、 LICENSE=no-commercial-use のような言いまわしは、ライセン スの文面を特定できないので、使わないことになりました。また、このような言いまわ しを使った場合の別の問題として、利用者が pkgsrc に対して、同じ目印のついた複数 のパッケージのうち、ひとつのパッケージだけは構築を続行するが、それ以外のパッケ ージは構築を続行しない、といった指定ができなくなるというものもあります。 19.1.5. 制限つきパッケージ ライセンスによっては、ソフトウェアの再配布方法に制限があります。パッケージが「 自由」あるいは「オープンソース」でない限りは、ライセンスの目印が必要なので、制 限のあるパッケージにはすべてライセンスの目印がついているはずです。その制限につ いて記述しておくと、パッケージのツールは、自動的に制限されたこと (たとえばバイ ナリーパッケージを FTP サイトに置くこと) を控えたりすることができます。 ソース (distfile) とバイナリーそれぞれについて、置いていけないのが FTP サイトか CD-ROM かの組み合わせで、 4 種類の制限を表現することができます。どのライセンス でも、これが厳密な文言となっていることはほとんどないことや、フリーでない各ライ センスはお互いに異なる傾向があることから、 pkgsrc では FTP と CD-ROM を定義して います。 pkgsrc では、"FTP" を、ソースやバイナリーのファイルを、インターネット 上で料金を払わずに利用できるようにしてはいけない、という意味で使います。 pkgsrc では、"CD-ROM" を、ソースやバイナリーを、配布料金をとるような何らかの種類の媒体 に、他のソースやバイナリーパッケージと同梱して利用できるようにすることはできな い、という意味で使います。 このような制限を表現するため、パッケージシステムでは以下のような制限を設定でき る5個のmake変数を定義しています: * RESTRICTED なにか制限がある場合は常に、(制限の種類にかかわらず)この変数を設定します。 この変数を、その制限の理由を含む文字列に設定してください。制限を理解しなけ ればならない人は、ライセンスを読む必要がありますし、おそらく法的な助言も必 要だと考えなければなりません。 * NO_BIN_ON_CDROM バイナリーを、配布料金を取れるようにして、他のバイナリーパッケージとともに CD-ROMに収録することができません。そのような場合は常に、この変数を$ {RESTRICTED}に設定してください。 * NO_BIN_ON_FTP バイナリーを、インターネット上で料金を払わずに利用できるようにすることがで きません。そのような場合は常に、この変数を ${RESTRICTED}に設定してください 。この変数を設定すると、バイナリーパッケージは ftp.NetBSD.org に置かれませ ん。 * NO_SRC_ON_CDROM distfileを、料金を取れるようにして、他のdistfileとともにCD-ROMに収録するこ とができません。そのような場合は、この変数を ${RESTRICTED}に設定してくださ い。 * NO_SRC_ON_FTP distfileを、インターネット上で料金を払わずに利用できるようにすることができ ません。そのような場合は、この変数を ${RESTRICTED}に設定してください。この 変数を設定すると、distfile は ftp.NetBSD.org にミラーされません。 19.1.6. 依存性の処理 パッケージは他のパッケージに依存するかもしれません。そして、この依存性を定義す るためのいろいろな方法があります。pkgsrc は、buildlink3.mkを使った依存関係 (依 存性の処理用としては、こちらが望ましい方法です。この方法では以下の各変数を使っ ています。さらなる情報はChapter 14, buildlink 方法論を参照してください) のほか 、 BUILD_DEPENDS および DEPENDS 定義、 USE_TOOLS 定義をサポートしています。 両変数の基本的な差異は、以下の通りです: DEPENDS定義では、その依存性がバイナリー パッケージ内に記録されるので、後でバイナリーパッケージをインストールする時に依 存性が呼び出されます。一方、BUILD_DEPENDS定義ではバイナリーパッケージにそのよう な記録はされず、パッケージの構築に際して依存性があることが示されているだけです 。 つまり、あるパッケージが必要となるのが構築時だけである場合、そのパッケージは BUILD_DEPENDSとして書きます。 BUILD_DEPENDSおよび DEPENDS定義の書式は以下の通りです: :../..// なお、この“pre-req-package-name”のバージョン番号には、pkg_info(1) で説明され ている各ワイルドカードを含めることができます。 1. パッケージを構築または実行するために他のパッケージのバイナリーやライブラリ ーが必要で、そのパッケージに buildlink3.mk ファイルがある場合は、それを使っ てください。 .include "../../graphics/jpeg/buildlink3.mk" 2. パッケージを構築するために、他のパッケージのバイナリーが必要な場合は、 BUILD_DEPENDS 定義を使ってください。 BUILD_DEPENDS+= scons-[0-9]*:../../devel/scons 3. パッケージがリンクのためのライブラリーを必要とし、そのパッケージに buildlink3.mk ファイルがない場合は、 buildlink3.mk ファイルを作ってください 。 DEPENDS を使うと、インクルードファイルやライブラリーをコンパイラーから隠 してしまうので、このような場合には不適切です。 4. パッケージを実行するために、いくつかの実行可能ファイルが必要であり、かつ buildlink3.mk ファイルが存在しない場合は、 DEPENDS変数を使ってください。 print/lyxパッケージを実行する時には、 teTeXパッケージ由来のlatex のバイナリ ーが実行可能でなければなりません。これは、以下のように指定します。 DEPENDS+= teTeX-[0-9]*:../../print/teTeX 5. パッケージ依存関係にはワイルドカードを使うことができます。ワイルドカード依 存関係は、バイナリーパッケージを作る時には保持されることに注意してください 。依存関係はバイナリーパッケージのインストール時にチェックされ、パターンに マッチするパッケージが使われます。ワイルドカード依存関係は、注意を払って使 うよう気を付けてください。 “tk-postgresql”が“tk-*”という DEPENDSにマッチするなどの曖昧なマッチの可 能性を排除するため、“-*”ではなく“-[0-9]*”を使うことをおすすめします。 ワイルドカードは、依存パッケージがあるバージョン以上でないと構築できないこ とを指定するのにも使えます。 DEPENDS+= ImageMagick>=6.0:../../graphics/ImageMagick 以上のように書いた場合、このパッケージは ImageMagick のバージョン 6.0 以上 を使って構築されることを意味します。このような形式の依存関係は、たとえば、 依存先のコマンドラインオプションが変更された場合にでも、構築できることを保 証することができます。 あるバージョン以上のライブラリーに依存させる必要がある場合は、 the pkgsrc guide の buildlink の節をご覧ください。 セキュリティー上の修正があった場合は、パッケージ脆弱性ファイルを更新してく ださい。さらなる情報は、Section 19.1.10, “セキュリティー問題を持つパッケー ジへの対処”を参照してください。 パッケージの構築用に別のパッケージに含まれるファイルが必要な場合は、関連する配 布ファイルを DISTFILES に追加して、必要なファイルが自動的に展開されるようにしま す。例としては print/ghostscript パッケージをご覧ください。 (このパッケージは、 構築の際に jpeg のソースがソースの状態で存在することに依存しています。) 19.1.7. 他のパッケージとの衝突の処理 パッケージは、すでにインストール済みの別のパッケージと衝突する可能性があります 。例えば、パッケージが、pkgsrcの中の別のパッケージと同じファイルをインストール するような場合です。 この場合、衝突するパッケージ(バージョン文字列を含む)のリストをスペースで区切っ てCONFLICTSにセットすることができます。 例えば、x11/Xaw3d およびx11/Xaw-Xpmは同じ共有ライブラリーをインストールします。 したがって、pkgsrc/x11/Xaw3d/Makefileに以下のような設定をおこなってください。 CONFLICTS= Xaw-Xpm-[0-9]* そして、pkgsrc/x11/Xaw-Xpm/Makefileには以下の設定が必要です。 CONFLICTS= Xaw3d-[0-9]* パッケージは、名前のプレフィックスが同じで、異なるバージョン文字列をもつ別のパ ッケージと自動的に衝突します。例えば“Xaw3d-1.5”は、古いバージョンの“ Xaw3d-1.3”と衝突するでしょう。 19.1.8. 構築することができない、あるいはすべきでないパッケージ 環境によってはパッケージを構築しないよう指示するような理由がいくつかあります。 パッケージが、ほとんどのプラットフォームで構築および実行できる場合は、 NOT_FOR_PLATFORMとして例外を記述します。逆に、パッケージが一部のプラットフォー ムでしか構築および実行できない場合は、ONLY_FOR_PLATFORMを設定します。 ONLY_FOR_PLATFORM と NOT_FOR_PLATFORM の値はいずれも、OS triples (OS-version-platform) であり、グロブ形式のワイルドカードを使うことができます。 パッケージのなかには、あるオペレーティングシステムの特定のバージョンに強く依存 するものがあります。たとえば、LKM や sysutils/lsof などです。このようなバイナリ ーパッケージは、同じ OS の別バージョンと後方互換ではないので、 FTP サーバーでは 対象バージョン専用のディレクトリーにアップロードするようにします。 OSVERSION_SPECIFIC を“yes”に設定して、パッケージに印をつけてください。この変 数は、現在のところ、パッケージシステム内部のどこでも使われませんが、将来は使わ れることになるかもしれません。 パッケージをとばすべき場合(たとえば、そのパッケージが提供する機能が、すでにシス テムで提供されている場合)は、 PKG_SKIP_REASONにそのことを説明するメッセージを設 定します。必要な条件が満たされていないせいでパッケージの構築が失敗するであろう 場合は、PKG_FAIL_REASONにそのことを説明するメッセージを設定します。 19.1.9. 一旦インストールしたら削除すべきでないパッケージ あるパッケージを、一旦インストールしたら削除できないようにするためには、そのパ ッケージの Makefile で PKG_PRESERVE 定義を設定します。この定義を設定した pkgsrc エントリーから作られたバイナリーパッケージには、その旨が記録されます。“ preserved”付きのパッケージは、 pkg_delete(1) を使っても、“-f”オプションを付 けない限りは削除されません。 19.1.10. セキュリティー問題を持つパッケージへの対処 脆弱性が発見された場合、そのことを localsrc/security/advisories/ pkg-vulnerabilitiesに記載してcommitしてください。このファイルを commit した後、 同じディレクトリーで make upload して、ftp.NetBSD.org 上のファイルを更新してく ださい。 脆弱性の修正を、パッチの適用によっておこなった場合は、修正後に PKGREVISION を上 げます (もちろん、問題の修正を、新しくリリースされたソフトウェアを使っておこな った場合は、これは必要ありません)。 また、修正を安定版 pkgsrc 枝に適用したほうがよい場合は、 pullup 要求を提出して ください。 ftp.NetBSD.org 上にすでに置かれているバイナリーパッケージは、週次の cron ジョブ によって半自動的に対処されます。 19.1.11. 既存パッケージ修正時に、バージョンを上げるにはどうするか 既存のパッケージに修正を加えたときに、PKGNAMEのバージョン番号を変えると便利な場 合があります。元の作者による将来のバージョンと衝突しないようにするため、 PKGREVISION=1 (2, ...)を設定して、パッケージのバージョンに“nb1”, “nb2”, ... という接尾辞をつけることができます。この“nb”は、パッケージのツール群からは“. ”と同様の扱いを受けます。たとえば、 DISTNAME= foo-17.42 PKGREVISION= 9 とすると、PKGNAMEは“foo-17.42nb9”になります。たとえば DIST_SUBDIR の設定用な どに、 PKGNAME に接尾辞“nbX”がつかない、元の値を使いたい場合は、PKGNAME_NOREV を使います。 このパッケージの新しいリリース版が出た際には、 PKGREVISIONは消してください。た とえば、上で例示したパッケージの新しいマイナーリリースに際しては、以下のように します。 DISTNAME= foo-17.43 バイナリーパッケージに対して自明でない変化をおよぼす場合は、すべて、 PKGREVISION を上げるようにします。 PKGREVISION を上げないと、変更前のバージョン をインストールしている人が、そのパッケージが古くなったことを知るすべがなくなっ てしまいます。したがって、PKGREVISION を上げない変更とは、本質的に「誰もアップ グレードする必要のない自明な変更」ということであり、これが PKGREVISION を上げる べきか否かを大雑把に判断する方法です。 PKGREVISION を上げる意味のない変更には、 たとえば以下のようなものがあります。 * HOMEPAGE, MAINTAINER, OWNER や、Makefile 中のコメントの変更。 * 構築変数の変更で、作成されるバイナリーパッケージに変化がない場合。 * DESCR の変更。 * PKG_OPTIONS の追加で、標準のオプションに変化がない場合。 PKGREVISION を上げる価値のある変更には、たとえば以下のようなものがあります。 * セキュリティーの修正 * パッチファイルの変更または追加 * PLIST の変更 * 依存性の変更や、依存先パッケージの改称。 依存するパッケージの ABI が変更された場合にも、 PKGREVISION を上げる必要があり ます。 19.1.12. パッケージのファイル中の各種テキストを置換する (SUBST の枠組) 複数のファイルに含まれる同じテキストを置換したい場合や、テキストの置換方法を変 化させたい場合には、パッチだけでは実現できません。そこで SUBST の枠組の出番です 。この枠組では、ファイル内のテキストを置換するために簡単に使えるインターフェー スを用意しています。たとえば以下のように使います。 SUBST_CLASSES+= fix-paths SUBST_STAGE.fix-paths= pre-configure SUBST_MESSAGE.fix-paths= Fixing absolute paths. SUBST_FILES.fix-paths= src/*.c SUBST_FILES.fix-paths+= scripts/*.sh SUBST_SED.fix-paths= -e 's,"/usr/local,"${PREFIX},g' SUBST_SED.fix-paths+= -e 's,"/var/log,"${VARBASE}/log,g' SUBST_CLASSES は、ここで定義する SUBST の塊を区別するための識別子を並べたリスト です。 SUBST の枠組は pkgsrc で多用されているので、この変数には常に += 演算子を 使うことが重要です。そうしないと、一部の置換がおこなわれなくなることがあります 。 各 SUBST の塊の残りの変数は、最初の行の識別子 (この例では fix-paths) を使ってパ ラメーター化されています。これらは、関数呼び出しの引数とみなすことができます。 SUBST_STAGE.* は、この置換をどの期におこなうかを指定します。実際に使われるもの は限られていますが、相の名前と pre-, do-, post- のあらゆる組合せを使うことがで きます。もっともよく使われるのは post-patch と pre-configure です。このふたつの うち、 pre-configure を使うと、 bmake patch を実行することで、パッチを適用した ほかは一切変更されていない状態にすることができるため、こちらのほうが好まれます 。このことは、新しいパッチを作成するためにパッケージのデバッグをする際に、特に 便利です。これと同様に、pre-install よりも post-build のほうが好まれます。これ は、一般的に install 相は極力簡素なものにするほうがよいからです。 post-build を 使った場合、後にインストールされるものと同じファイルが作業ディレクトリーにでき あがるので、正しく置換がおこなわれたかを確認することができます。 SUBST_MESSAGE.* は、置換がおこなわれる直前に表示するテキストで、省略可能です。 SUBST_FILES.* は、置換の対象となるファイルを、シェルのグロブパターンで指定した ものを並べたリストです。このパターンは、WRKSRC ディレクトリーからの相対位置とし て解釈されます。 SUBST_SED.* は置換の内容を sed(1) への引数の形で指定したものを並べたリストです 。各 sed コマンドの前には -e をつけて、 SUBST の塊全体が一様に見えるようにしま す。 以上のほかにも変数がいくつかありますが、それらはほとんど使われないものなので、 mk/subst.mk ファイル内でのみ文書化されています。 19.2. fetch 相での問題を修正する 19.2.1. distfileのダウンロードが単純にできないパッケージ 動的なURLからダウンロードする必要がある場合は、 DYNAMIC_MASTER_SITES を設定する ことができます。すると、make fetchは、ダウンロードすべき各ファイルを引数として files/getsite.shを呼び出します。このスクリプトは、ファイルをダウンロードするデ ィレクトリーのURLを出力することが前提となっています。 graphics/ns-cult3dが、こ の使い方の例となっています。 パスワード用に個人情報の登録が必要だったり、ソースに代金を払う必要があったり、 その他もろもろの理由により、ダウンロードが自動化できない場合は、 FETCH_MESSAGE を、構築中止前にユーザーに表示する説明文を行ごとに並べたリストに設定することが できます。たとえば以下のようにします。 FETCH_MESSAGE= "Please download the files" FETCH_MESSAGE+= " "${DISTFILES:Q} FETCH_MESSAGE+= "manually from "${MASTER_SITES:Q}"." 19.2.2. '古い'名前のまま更新されたdistfileの取り扱い 時々、ソフトウェアパッケージの作者がソフトウェアのリリース後に変更を加え、変更 後のdistfileを、バージョン番号を変えずに公開することがあります。このとき、 pkgsrcにそのパッケージがすでに入っていると、チェックサムが一致しないことになり ます。distfileの更新が意図されたものであって、トロイの木馬などが仕込まれたので はないことを確認するため、新しい distfile の内容と変更前の古い distfile の内容 と比較してください。新旧の distfile を比較したことと、何が変わったのかを、 commit メッセージに含めてください。確認後、この問題の正しい回避策は、 DIST_SUBDIR を一意な (普通は PKGNAME_NOREV にもとづく) ディレクトリー名に設定す ることです。これを設定すると、このパッケージの DISTFILES と PATCHFILES はすべて 、 distfiles ディレクトリー以下の、設定した名前のサブディレクトリーに置かれます 。 (詳細は、Section 19.1.11, “既存パッケージ修正時に、バージョンを上げるにはど うするか”をご覧ください。) この問題がよく起きる場合は、ディレクトリー名に PKGNAME を使ったり (これにより nbX サフィックスが含まれる)、 ${PKGNAME_NOREV} -YYYYMMDD のように日付を付けたりすることができます。設定後は、distinfo ファイル を作り直すのを忘れないでください。このファイルでは、ファイル名のなかに DIST_SUBDIR パスが含まれているからです。この変更によって、インストールされるパ ッケージが以前のものと異なるものになる場合は、 PKGREVISION も上げます。さらに、 パッケージの正当な作者にメールを出して、リリース後に、ファイル名を変えずに distfile の内容を変えるのはよろしくないやり方だと伝えてください。 19.3. configure 相での問題を修正する 19.3.1. 共有ライブラリー - libtool pkgsrcはさまざまな種類のマシンをサポートします。それらはa.outとELFのような異な るオブジェクトフォーマットを使い、共有ライブラリー、ダイナミックローディングの 有無すらも異なります。これに対応するためにコマンドそのもの、およびオプションが コンパイラー、リンカーなどに渡される必要があります。すべてのマシンで正しく動作 させることは非常にむずかしく、テストのためにすべてのマシンを持っていない場合は 特にそうでしょう。 devel/libtoolパッケージはこれを助けます。 devel/libtoolはプ ラットフォームによらずに、ソースファイルから、静的、動的なライブラリー両方を構 築する方法を“知って”いるからです。 以下に、libtoolをパッケージで使用するための7つの手順を記述します。 1. USE_LIBTOOL=yesをパッケージのMakefileへ追加します。 2. ライブラリーオブジェクトのために、“${LIBTOOL} --mode=compile ${CC}”を“$ {CC}”に設定します。ライブラリーが、提供されたMakefileだけを使用して構築さ れるのであれば、CCの定義にこれを追加するだけです。このコマンドひとつだけで 、 PICと非PICのライブラリーオブジェクトを作成します。したがって、共有ライブ ラリーとそうでないライブラリーの構築規則を別々に記述する必要はありません。 3. ライブラリーのリンクのための“ar”、“ranlib”、“ld -Bshareable”コマンド を削除してください。そしてその代わりに以下のコマンドを使用してください。 ${LIBTOOL} --mode=link \ ${CC} -o ${.TARGET:.a=.la} \ ${OBJS:.o=.lo} \ -rpath ${PREFIX}/lib \ -version-info major:minor ライブラリーの拡張子は.laに、オブジェクトの拡張子は .loに変更されることに注 意してください。OBJS を必要に応じて変更してください。このコマンドは、必要な ものすべて、 .a、.so.major.minor、そしてELFのシンボリックリンク(必要なら)を 自動的にカレントディレクトリーに作成します。特に、メジャー番号とマイナー番 号がゼロの場合は、“-version-info”をかならず含めるようにしてください。そう しないとlibtoolは共有ライブラリーのバージョンを取り除きます。 libtool のマニュアルより: libtool のライブラリーのバージョンは、以下の三つの整数で表されます。 CURRENT このライブラリーが実装しているインターフェース番号のうち最新のもの。 REVISION CURRENT インターフェースの実装番号。 AGE このライブラリーが実装しているインターフェースの最新のものと最古のものの間の差。 すなわち、このライブラリーが実装しているのは、 `CURRENT - AGE' から `CURRENT' までの番号の範囲にある、 すべてのインターフェース番号です。 二つのライブラリーの CURRENT と AGE 番号がいずれも同じ場合、 ダイナミックリンカーは REVISION 番号が大きいほうのライブラリーを選びます。 また、“-release”オプションは、ある一つの場合に限って、a.outとELF(シンボリ ックリンクを除く)との間で異なる結果をもたらします。“libfoo-release.so.x.y ”の形式のELFライブラリーは、a.outプラットフォーム上では“libfoo.so.x.y”の シンボリックリンクを持ちます。これは自動的に処理されます。 “-rpath引数”は構築されたライブラリーのインストール先ディレクトリーです。 PLISTには、 .la ファイルだけを含めます。これ以外のファイルは自動的に追加さ れます。 4. 共有オブジェクト(.so)ファイル(すなわち、dlopen(3)でロードされるファイルであ って、共有ライブラリーでは*ありません*)のリンク時には、ファイルにバージョン が加えられないようにするため、“-module -avoid-version”を使ってください。 PLISTファイルにはfoo.so の一覧が加わります。 5. インストールする前のライブラリーに依存するプログラムをリンクする時に、 cc (1)かld(1)の前に“${LIBTOOL} --mode=link”を書いてください。このコマンドは 、正しいライブラリー(静的、または共有)を見つけます。ただし、libtoolを使う時 には-Lオプションで相対パスを指定すること(“-L../somelib”のように)ができな いことに注意してください。引数として.laファイルを使うように修正しなければな りません。例えば、 ${LIBTOOL} --mode=link ${CC} -o someprog -L../somelib -lsomelib は、以下のように変更する必要があります。 ${LIBTOOL} --mode=link ${CC} -o someprog ../somelib/somelib.la これで、ライブラリーを正しく扱う事ができます。 6. ライブラリーをインストールするときに、install(1) あるいはcp(1)コマンドの前 に“${LIBTOOL} --mode=install”を書いて下さい。そしてライブラリーの名前を .laに変えてください。例えば、以下のように書く必要があります。 ${LIBTOOL} --mode=install ${BSD_INSTALL_LIB} ${SOMELIB:.a=.la} ${PREFIX}/lib これは、静的リンクのための.a、共有ライブラリー、必要なシンボリックリンクを インストールし、ldconfig(8)を実行します。 7. PLISTには、 .la ファイルだけを含めます (これは、以前のものから変わった点で す)。 19.3.2. すでにlibtoolをサポートしているGNUパッケージでlibtoolを使う USE_LIBTOOL=yes をパッケージの Makefile に追加します。こうするとほとんどの場合 、パッケージ固有の libtool を無視します。古い libtool を使っているパッケージで は、 libtool はdo-configureターゲットでltconfigスクリプトにより作られます。make configure; find work*/ -name libtool のようにして、libtool スクリプトの場所を確 認することができます。 LIBTOOL_OVERRIDE で、どの libtool スクリプトを無視するかを、WRKSRC からの相対位 置で指定します。指定しなかった場合、“libtool */libtool */*/libtool”に設定され ますので、パッケージ固有の libtool スクリプトの場所がこのいずれとも異なる場合は 、適宜設定してください。 静的ライブラリー *.a の構築やインストールが必要ない場合は、かわりに SHLIBTOOL_OVERRIDE を使います。 パッケージが動的共有オブジェクトのロードに、libtool (libltdl)のプラットフォーム 独立なライブラリーを使う場合は、 devel/libltdl/buildlink3.mkをインクルードして ください。 パッケージによっては、環境により動作や構築ができなくなるような、正しくない libtoolの使い方をしているものがあります。ありがちな間違いは以下のようなものです 。 * 実行形式やライブラリーで、共有オブジェクト(-module)を依存ライブラリーとして インクルードする。このこと自体は、以下の二つのうちいずれかが行なわれている 場合は、問題になりません。 1. その共有オブジェクトが正しく命名されている。すなわち、 libfoo.laではな く libfoo.laとなっている。 2. -dlopenオプションが実行形式のリンク時に使われている。 * ルーチンの初期化を適切に呼ばずにlibltdlを使う。関数lt_dlinit()を呼んで、マ クロ LTDL_SET_PRELOADED_SYMBOLSを実行形式にインクルードするようにしましょう 。 19.3.3. GNU Autoconf/Automake パッケージが、configureスクリプトやmakefileの雛型Makefile.inを再生成するために GNU autoconfまたはautomakeを実行する必要がある場合、これらの実行は pre-configureターゲットでおこないます。 autoconfのみを必要とするパッケージでは以下のようになります: AUTOCONF_REQD= 2.50 # if default version is not good enough USE_TOOLS+= autoconf # use "autoconf213" for autoconf-2.13 ... pre-configure: cd ${WRKSRC} && autoconf ... また、automakeとautoconfを必要とするパッケージでは以下のようになります: AUTOMAKE_REQD= 1.7.1 # if default version is not good enough USE_TOOLS+= automake # use "automake14" for automake-1.4 ... pre-configure: set -e; cd ${WRKSRC}; \ aclocal; autoheader; automake -a --foreign -i; autoconf ... GNU Automake を使うパッケージは、ほぼ確実に GNU Make を必要とします。 生成されたファイルに対して、configureプロセスがさらに変更を加える時がありますが 、この時には構築プロセスが一連のautomakeの手順を再実行しようとします。 configureの段階でさまざまなファイルに手を加えると、この挙動は止められます。この 挙動が問題が起こす場合は、そのパッケージのMakefileで AUTOMAKE_OVERRIDE=NOを設定 することができます。 19.4. プログラミング言語 19.4.1. C, C++ および Fortran C, C++ および Fortran 言語用のコンパイラーは、 NetBSD の基本システムに附属して います。標準では、 pkgsrc はパッケージが C で書かれていると仮定し、それ以外のコ ンパイラーをすべて隠します (ラッパーの枠組による。Chapter 14, buildlink 方法論 参照)。 パッケージがどの言語のコンパイラーを必要としているかを表すには、 USE_LANGUAGES 変数を設定します。使うことのできる値は、現在のところ、“c”, “c++”, “fortran ” (および、これらの任意の組合せ) です。標準では“c”になります。GNU の configure スクリプトを使うパッケージでは、 C++ で書かれているものであっても、通 常は configure 相で C コンパイラーを必要とします。 19.4.2. Java プログラムが Java で書かれている場合は、pkgsrc における Java の枠組を使います。 パッケージは ../../mk/java-vm.mk をインクルードする必要があります。この Makefile の断片は、以下の変数を用意してくれます。 * USE_JAVA は、 JDK への依存性が追加されるかどうかを定義します。 USE_JAVA が “run”に設定された場合は、 JDK への実行時依存性があるだけです。標準では“ yes”となり、この場合は JDK への構築時依存性も追加されます。 * パッケージが Java2 の実装を必要とすることを表すため、 USE_JAVA2 を設定しま す。この変数が対応している値は、“yes”, “1.4”, “1.5”です。“yes”は任 意の Java2 の実装を受け入れます。“1.4”はバージョン 1.4 以上を要求し、“ 1.5”はバージョン 1.5 以上のみを受け入れます。この変数は標準では設定されま せん。 * PKG_JAVA_HOME は、依存している Java 実装のランタイムの場所を自動的に設定す るものです。 JAVA_HOME 変数の定義が必要なプログラムでは、この変数に適切な値 を設定するために使うことができます。 19.4.3. perl スクリプトを含むパッケージ perl スクリプトがパッケージに含まれる場合は、 USE_TOOLS 変数に“perl”を追加し 、適切なインタープリターへのパスが設定されるようにするために REPLACE_PERL を設 定します。 REPLACE_PERL の値には、パスを調節する対象のスクリプトを WRKSRC から の相対位置として並べたリストを含めるようにします。対象のスクリプト内に現れる */ bin/perl はすべて、 perl の実行ファイルへのフルパスに置き換えられます。 特定のバージョンの perl が必要な場合は、 PERL5_REQD 変数をバージョン番号に設定 します。標準では“5.0”になります。 perl モジュールの扱いについては、 Section 19.6.6, “perl モジュールをインストー ルするパッケージ”をご覧ください。 19.4.4. 他のプログラミング言語 現在のところ、pkgsrc では、他のプログラミング言語に対する特別な扱いはありません 。その言語のコンパイラーのパッケージに buildlink3.mk ファイルがある場合は、この ファイルをインクルードします。このファイルがない場合は、適切なコンパイラーのパ ッケージへの (構築時) 依存性を追加するだけです。 19.5. build 相での問題を修正する パッケージ構築時に最もよくある障害は、プラットフォームによっては必要なヘッダー ファイル、関数やライブラリーがなかったり、あるいは、ライブラリーで提供される関 数がパッケージ作者の考えているものと違っていたりするものです。そのようなことを 回避するために、ほとんどの場合は、ない関数を使わないようにしたり、代替の関数を 提供したりするようにソースコードを書き換えることができます。 19.5.1. C および C++ のコードの条件つきコンパイル パッケージに最初から GNU configure スクリプトが附属している場合は、構築の障害の 修正方法としては、コードを変更せずに configure スクリプトを変更するのが望ましい 方法です。configure スクリプトが附属しない場合は、コンパイル対象のオペレーティ ングシステムやハードウェアアーキテクチャーに応じて必要なマクロを定義している C プリプロセッサーを役立てることができます。このマクロは、たとえば #if defined (__i386) のようにして調べることができます。ほとんどすべてのオペレーティングシス テム、ハードウェアアーキテクチャー、およびコンパイラーには、独自のマクロがあり ます。たとえば、__GNUC__, __i386__, __NetBSD__ の各マクロがすべて定義されている 場合は、i386 互換 CPU 上の NetBSD を使っていることと、コンパイラーが GCC である ことがわかります。 以下に列挙するハードウェアおよびオペレーティングシステム用のマクロは、使ってい るコンパイラーに依存します。たとえば、Solaris 上でコードを条件付きコンパイルし たい場合、 __sun__ は SunPro コンパイラーでは定義されていないので使ってはいけま せん。かわりに __sun を使います。 19.5.1.1. オペレーティングシステムを特定するための C プリプロセッサーマクロ 4.4 BSD から派生したシステムとそれ以外のシステムを見分けるには、以下のコードを 使うようにしてください。 #include #if (defined(BSD) && BSD >= 199306) /* BSD-specific code goes here */ #else /* non-BSD-specific code goes here */ #endif これでは十分正確でない場合は、以下のマクロを検査することもできます。 FreeBSD __FreeBSD__ DragonFly __DragonFly__ Interix __INTERIX IRIX __sgi (TODO: 出典の確認) Linux linux, __linux, __linux__ NetBSD __NetBSD__ OpenBSD __OpenBSD__ Solaris sun, __sun 19.5.1.2. ハードウェアアーキテクチャーを特定するための C プリプロセッサーマクロ i386 i386, __i386, __i386__ MIPS __mips SPARC sparc, __sparc 19.5.1.3. コンパイラーを特定するための C プリプロセッサーマクロ GCC __GNUC__ (メジャーバージョン), __GNUC_MINOR__ MIPSpro _COMPILER_VERSION (MIPSpro 7.41 なら 0x741) SunPro __SUNPRO_C (Sun C 5.7 なら 0x570) SunPro C++ __SUNPRO_CC (Sun C++ 5.8 なら 0x580) 19.5.2. コンパイラーのバグへの対処方法 ソースファイルのなかには、コンパイラーのバージョンとアーキテクチャーの組合せに よって、また、ほとんどの場合は、最適化を有効にしたことも関係して、コンパイラー のバグを発現させるものがあります。よくある症状は、gccの内部エラーや、ファイルの コンパイルが完了しないというものです。 たいていは、回避策として、MACHINE_ARCH とコンパイラーのバージョンを確認し、問題 のあるファイル・MACHINE_ARCH・コンパイラーの組合せに対して最適化を無効にし、そ のことをpkgsrc/doc/HACKSに文書化しておくことが必要となります。このファイルに多 くの例が載っているので、参照してください。 19.5.3. undefined reference to “...” このエラーメッセージは、しばしば、パッケージが必要な共有ライブラリーにリンクし ていないことを表します。以下の関数は、このエラーメッセージを何度も出すことがわ かっているものです。 +-----------------------------------------------------------------+ | 関数 |ライブラリー|影響のあるプラットフォーム| |-------------------------+------------+--------------------------| |accept, bind, connect |-lsocket |Solaris | |-------------------------+------------+--------------------------| |crypt |-lcrypt |DragonFly, NetBSD | |-------------------------+------------+--------------------------| |dlopen, dlsym |-ldl |Linux | |-------------------------+------------+--------------------------| |gethost* |-lnsl |Solaris | |-------------------------+------------+--------------------------| |inet_aton |-lresolv |Solaris | |-------------------------+------------+--------------------------| |nanosleep, sem_*, timer_*|-lrt |Solaris | |-------------------------+------------+--------------------------| |openpty |-lutil |Linux | +-----------------------------------------------------------------+ このようなリンカーのエラーの修正は、多くの場合、パッケージの Makefile に LIBS. OperatingSystem+= -lfoo を追加してから bmake clean; bmake を実行すれば十分です 。 19.5.3.1. 特殊な問題: SunPro コンパイラー SunPro コンパイラーを使っている場合は、別の問題の可能性があります。このコンパイ ラーは、以下のようなコードを処理することができません。 extern int extern_func(int); static inline int inline_func(int x) { return extern_func(x); } int main(void) { return 0; } ここからは、inline_func 関数がたとえ使われていなくても、この関数用のコードが生 成され、そのコードから extern_func が参照されますが、この参照は通常は解決するこ とができません。この問題を解決するため、パッケージに関数のインライン化を無効化 するよう指示してみることができます。 19.5.4. メモリーが不足する 時には、コンパイラーの実行でオペレーティングシステム固有のソフトリミットに達す るために、パッケージの構築に失敗することがあります。 UNLIMIT_RESOURCES 変数を設 定して、 pkgsrc に資源の制限を解除するよう伝えることができます。現在のところ、 使うことのできる値は、“datasize”と“stacksize” (あるいは両方) です。この変数 を設定すると、シェル組み込みの ulimit コマンドを実行した場合と同様に、それぞれ 、データセグメントのサイズとスタックのサイズの上限を、ハードリミットまで引き上 げます。 19.6. install 相での問題を修正する 19.6.1. 必要なディレクトリーを作成する 一部のプラットフォームに附属する BSD 互換の install は、一度に複数のディレクト リーを作成することができません。このため、 ${INSTALL_*_DIR} を使うときは、以下 のようにします。 ${INSTALL_DATA_DIR} ${PREFIX}/dir1 ${INSTALL_DATA_DIR} ${PREFIX}/dir2 こうするかわりに、単に“dir1 dir2”を INSTALLATION_DIRS 変数に追加するという方 法もあります。こうすると、適切な処理が自動的におこなわれます。 19.6.2. ドキュメンテーションのインストール場所 一般的には、ドキュメンテーションは ${PREFIX}/share/doc/${PKGBASE} または $ {PREFIX}/share/doc/${PKGNAME} (後者は、パッケージのバージョン番号を含んでいま す) 以下にインストールします。 GNU autoconf を使っている最近のパッケージの多くは、 HTML のドキュメンテーション のインストール先を、“--with-html-dir”オプションを使って設定することができます 。時には、このフラグを使わないとドキュメンテーションが ${PREFIX}/share/doc/html や他の場所にインストールされるために、このフラグを使う必要があることがあります 。 例外は、textproc/gtk-doc ツールによって生成される、ライブラリーの API のドキュ メンテーションです。このドキュメンテーションは、専用のブラウザー (devhelp) から 使うものであり、ブラウザーが標準で使う場所である ${PREFIX}/share/gtk-doc に置く ようにします。このようなドキュメンテーションは、ファイル名の末尾が .devhelp ま たは .devhelp2 であることから区別できます。 (これらのファイルを ${PREFIX}/share /doc/${PKGBASE} または ${PREFIX}/share/doc/${PKGNAME} にインストールしても使う ことができます。この場合、これらのディレクトリーの直下に .devhelp* ファイルを置 く必要があり、サブディレクトリー階層を追加することはできません。通常は、“ --with-html-dir=${PREFIX}/share/doc”を使えばそのようにすることができます。 $ {PREFIX}/share/gtk-doc のほうが好ましいのですが。) 19.6.3. 最高得点ファイルをインストールする パッケージによっては (ほとんどは games カテゴリーのもの)、システム上の各ユーザ ーが最高得点を記録できるように、得点ファイルをインストールします。これを実現す るために、バイナリーは setgid してインストールし、得点ファイルはグループとオー ナーのいずれかまたは両方を当該グループやオーナー (伝統的には "games" ユーザーお よびグループ) の所有とする必要があります。 SETGIDGAME, GAMEDATAMODE, GAMEGRP, GAMEMODE, GAMEOWN の各変数でこの挙動を制御します。詳細は mk/defaults/mk.conf に 書かれています。 なお、games に setgid されたインストールは、標準では有効になっていません。 SETGIDGAME=YES を設定すると、これに応じて他の各変数が設定されます。 このため、パッケージではファイルの所有やアクセス許可属性を決してハードコードせ ずに、 INSTALL_GAME および INSTALL_GAME_DATA の設定に応じて適切に設定されるよう にします。 19.6.4. パッケージを DESTDIR に対応させる パッケージが DESTDIR に対応しているというのは、ファイルを最終的な置き場所にイン ストールせずに、足場となるディレクトリーにインストールするということです。その 後、通常の方法でインストール可能なバイナリーパッケージが作成されます。この対応 には、二つの方法があります。パッケージを root としてインストールする必要がある 場合 (“destdir”)と、root 以外のユーザーでインストール可能な場合 (“ user-destdir”) です。 * PKG_DESTDIR_SUPPORT を、“destdir”または“user-destdir”のいずれかに設定す る必要があります。 Makefile で bsd.prefs.mk をインクルードする場合、 PKG_DESTDIR_SUPPORT は、インクルードの前に設定する必要があります。 * すべてのインストール操作では、インストール先を ${DESTDIR} から始まる場所に する必要があります。 * automake は、たいていは、この DESTDIR に対して、自動的に対処します。自動化 されていない処理や pre/post-install では、不適切に処理されることが多いので 、修正してください。 * ファイルが、特別な所有者や所有グループでインストールされる場合は、 SPECIAL_PERMS を使ってください。 * 一般的に、各パッケージは、 DESTDIR を使えるようにするために、 UNPRIVILEGED に対応させるようにしてください。 19.6.5. その他のインタープリターへのパスがハードコードされているパッケージ パッケージには perl 以外のインタープリターへのパスがハードコードされていること もあります。スクリプトのインタープリターへのフルパスを適切なものにするため、当 該パッケージの Makefile で、以下のような定義をする必要があります (ここでは例と して tclsh を使います)。 REPLACE_INTERPRETER+= tcl REPLACE.tcl.old= .*/bin/tclsh REPLACE.tcl.new= ${PREFIX}/bin/tclsh REPLACE_FILES.tcl= # パスを修正する必要がある tcl スクリプトを列挙します # REPLACE_PERL と同様に、${WRKSRC} からの相対位置とします Note 2006 年 3 月より前は、この各変数は _REPLACE.* および _REPLACE_FILES.* という名 前でした。 19.6.6. perl モジュールをインストールするパッケージ perl5モジュールを提供するパッケージでは、MakefileにMakefileの断片 ../../lang/ perl5/module.mkをインクルードしてください。このファイルには、perl5モジュール用 の標準的なperlの構成をするdo-configureターゲットのほか、その構成を調整するため のさまざまなフックが含まれています。詳細は、このファイル中のコメントをご覧くだ さい。 perl5 のモジュールがインストールされる場所は、構築プロセスで使われるperl のバー ジョンに応じて変わります。これを扱うために、pkgsrc は、インストールされ た.packlistファイル(ほとんどの perl5 モジュールが生成します) に列挙された各ファ イルに対応する行を、PLIST に追加します。これは、packlist ファイルへのパスをスペ ースで区切ったリストをPERL5_PACKLISTとして定義することで行なわれるようになりま す。たとえば以下のように定義します。 PERL5_PACKLIST= ${PERL5_SITEARCH}/auto/Pg/.packlist PERL5_SITELIB, PERL5_SITEARCH, PERL5_ARCHLIBの各変数は、perl5モジュールがインス トールされうる三つの場所を表すもので、packlistを持たないperl5パッケージで使うこ とができます。この3変数の置換は、PLISTでもおこなわれます。 19.6.7. infoファイルをインストールするパッケージ パッケージによっては、infoファイルをインストールしたり、“makeinfo”または“ install-info”コマンドを使ったりします。このようなパッケージでは、パッケージの Makefile で INFO_FILES を定義するようにします。これを定義しておくと、info ファ イルを Info ディレクトリーファイルに登録するために、INSTALL および DEINSTALL ス クリプトが作られるようになります。 info ファイルの登録用の“install-info”コマ ンドは、システム附属のものが使われるか、または、必要があればそれ用のパッケージ が自動的に追加されて使われます。 PKGINFODIR は ${PREFIX} 以下のディレクトリーで、 info ファイルが置かれる主な場 所です。 PKGINFODIR は標準では“info”となっており、利用者が上書きすることがで きます。 info ファイルは、そのパッケージの PLIST に列挙します。ただし、分割された info ファイルは列挙する必要はありません。 構築時に“makeinfo”コマンドが必要なパッケージは、 Makefile で USE_TOOLS 変数に “makeinfo”を追加する必要があります。あるバージョン以上の“makeinfo”コマンド が必要な場合は、パッケージの Makefile で TEXINFO_REQD 変数を必要な最低バージョ ンに設定します。デフォルトでは、 3.12 が最低限必要なバージョンとなります。 makeinfo コマンドがシステムにないか、最低限必要なバージョンを満たさない場合は、 devel/gtexinfo パッケージへの構築時の依存関係が自動的に追加されます。 パッケージで提供されるソフトウェアの構築やインストールの過程では、 install-info コマンドを使ってはいけません。 info ファイルの登録は INSTALL スクリプトの仕事で あって、適切な makeinfo コマンドを使う必要があるからです。 pkgsrc の基盤は、以上のことを実現するため、 PATH のはじめのほうにあるディレクト リーに、 install-info や makeinfo を上書きするスクリプトを作成します。 install-info を上書きするスクリプトは、メッセージを記録すること以外、何の効果も ありません。makeinfo を上書きするスクリプトは、メッセージを記録し、TEXINFO_REQD の値に従って、適切な makeinfo コマンドを実行するか、または異常終了します。 19.6.8. マニュアルページをインストールするパッケージ マニュアルページをインストールするパッケージはすべて、マニュアルページを同じデ ィレクトリー内にインストールして、マニュアルページを共通のひとつの場所から探せ るようにします。 pkgsrc では、この場所は ${PREFIX}/${PKGMANDIR} であり、パッケ ージ内ではこの表記を使うようにします。 PKGMANDIR の値は標準では“man”です。こ れ以外によく使われる値は、“share/man”です。 Note PKGMANDIR の独自設定には、完全には対応していません。 PLIST ファイル内では、マニュアルページのファイルの最上層ディレクトリーを、単に man/ と書くことができます。これは pkgsrc の枠組みが必要に応じて変換してくれます 。これ以外の場所の場合は、正確な PKGMANDIR を使って書く必要があります。 GNU_CONFIGURE が“yes”に設定されているパッケージでは、標準では ./configure --mandir スイッチを使って、マニュアルページをどこにインストールするかを設定しま す。このパスは GNU_CONFIGURE_MANDIR で、標準では ${PREFIX}/${PKGMANDIR} になり ます。 パッケージが GNU_CONFIGURE を使うが、 --mandir は使わない場合は、 CONFIGURE_HAS_MANDIR を“no”に設定することができます、また、./configure スクリ プトが標準的ではない --mandir の使い方をする場合は、必要に応じて GNU_CONFIGURE_MANDIR を設定することができます。 圧縮したマニュアルページのインストールに関する情報は、 Section 13.5, “マニュア ルページの圧縮”をご覧ください。 19.6.9. GConf のデータファイルをインストールするパッケージ パッケージが、 GConf が使用する .schemas または .entries ファイルをインストール する場合は、これらが確実にデータベースに登録されるようにするために、いくつか特 別な手順を踏む必要があります。 1. GConf の buildlink3.mk ファイルではなく ../../devel/GConf/schemas.mk をイン クルードします。こうすると、インストールおよびアンインストール時に、 GConf のデータベースを再構築し、また、GConf のデータファイルのインストール場所を 標準的な configure 引数を使ってパッケージに伝えてくれます。また、パッケージ がデータベースに直接アクセスすることが一切できなくなります。 2. パッケージが .schemas ファイルを必ず ${PREFIX}/share/gconf/schemas 以下にイ ンストールするようにします。 ${PREFIX}/etc 以下にインストールするようになっ ている場合は、手作業でパッケージを修正する必要があります。 3. PLIST を確認し、etc/gconf ディレクトリー以下の項目をすべて削除します。これ らは自動的に処理されるものだからです。詳細は Section 9.13, “設定ファイルの 置き場所を変更する方法は?”を参照してください。 4. Makefile で、 GCONF_SCHEMAS 変数を定義します。変数値にはパッケージがインス トールする .schemas ファイルをすべて列挙します。このファイル名にディレクト リーを含めてはいけません。 5. Makefile で、 GCONF_ENTRIES 変数を定義します。変数値にはパッケージがインス トールする .entries ファイルをすべて列挙します。このファイル名にディレクト リーを含めてはいけません。 19.6.10. scrollkeeper/rarian のデータファイルをインストールするパッケージ パッケージが、 scrollkeeper/rarian が使用する .omf ファイルをインストールする場 合は、これらが確実にデータベースに登録されるようにするために、いくつか特別な手 順を踏む必要があります。 1. rarian の buildlink3.mk ファイルではなく ../../mk/omf-scrollkeeper.mk をイ ンクルードします。こうすると、インストールおよびアンインストール時に、 scrollkeeper のデータベースを再構築してくれます。また、パッケージがデータベ ースに直接アクセスすることが一切できなくなります。 2. PLIST を確認し、libdata/scrollkeeper ディレクトリー以下の項目をすべて削除し ます。これらは自動的に処理されるものだからです。 3. PLIST から share/omf ディレクトリーを削除します。これは rarian が処理します 。(make print-PLIST で自動でおこなえます。) 19.6.11. X11 のフォントをインストールするパッケージ パッケージがフォントファイルをインストールする場合は、インストール時とアンイン ストール時に、フォントのインストール先ディレクトリーにあるフォントデータベース を再構築する必要があります。この処理は pkginstall の枠組を使って自動的におこな うことができます。 フォントのインストール先ディレクトリーを FONTS_DIRS.type 変数に列挙することがで きます。変数名中の type は、“ttf”, “type1”, “x11”のいずれかです。また、デ ータベースファイル fonts.dir は PLIST に含めてはいけません。 なお、フォント用のディレクトリーを新たに作らないようにしてください。 X サーバー がフォントを見つけるための設定をユーザーが手動でおこなう必要がないようにするた め、新しいディレクトリーではなく標準的なディレクトリーを使うようにします。 19.6.12. GTK2 のモジュールをインストールするパッケージ パッケージが GTK2 の IM モジュールやローダーをインストールする場合は、これらが 確実に GTK2 のデータベースに登録されるようにするために、いくつか特別な手順を踏 む必要があります。 1. gtk2 の buildlink3.mk ファイルではなく ../../x11/gtk2/modules.mk をインクル ードします。こうすると、インストールおよびアンインストール時に、GTK2 のデー タベースを再構築してくれます。 2. GTK2 の IM モジュールをインストールするパッケージでは、 GTK2_IMMODULES=YES を設定します。 3. GTK2 のローダーをインストールするパッケージでは、 GTK2_LOADERS=YES を設定し ます。 4. パッケージが GTK2 のデータベースディレクトリーを直接いじらないよう修正しま す。データベースは以下のとおりです。 * libdata/gtk-2.0/gdk-pixbuf.loaders * libdata/gtk-2.0/gtk.immodules 5. PLIST を確認し、libdata/gtk-2.0 ディレクトリー以下の項目をすべて削除します 。これらは自動的に処理されるものだからです。 19.6.13. SGML または XML のデータをインストールするパッケージ パッケージが、システム全体で使われるカタログへ登録する必要のある SGML または XML のデータファイル (DTD, sub-catalog など) をインストールする場合は、いくつか 特別な手順を踏む必要があります。 1. パッケージの Makefile で ../../textproc/xmlcatmgr/catalogs.mk をインクルー ドします。こうすると、インストールおよびアンインストール時に、データファイ ルをシステム全体で使われるカタログに登録してくれます。 2. SGML_CATALOGS を、このパッケージがインストールする SGML カタログをすべてを フルパス表記にしたものに設定します。 3. XML_CATALOGS を、このパッケージがインストールする XML カタログをすべてをフ ルパス表記にしたものに設定します。 4. SGML_ENTRIES を、SGML カタログに追加する個々のエントリーに設定します。各エ ントリーは 3 個の文字列からなります。書き方の詳細は xmlcatmgr(1) (特に、 'add' アクション用の引数) を参照してください。なお、通常はこの変数を使うこ とはありません。 5. XML_ENTRIES を、XML カタログに追加する個々のエントリーに設定します。各エン トリーは 3 個の文字列からなります。書き方の詳細は xmlcatmgr(1) (特に、'add' アクション用の引数) を参照してください。なお、通常はこの変数を使うことはあ りません。 19.6.14. MIME データベースの拡張をインストールするパッケージ パッケージが、.xml ファイルを ${PREFIX}/share/mime/packages 以下にインストール することで MIME データベースを拡張する場合は、データベースがこの新規ファイルに ついて確実に整合性を持つようにするために、いくつか特別な手順を踏む必要がありま す。 1. ../../databases/shared-mime-info/mimedb.mk をインクルードします (同じディレ クトリーにある buildlink3.mk ファイルは、他の buildlink3.mk ファイルでイン クルードするために予約されているので使いません) こうすると、インストールお よびアンインストール時に、MIME データベースを再構築してくれます。また、パッ ケージがデータベースに直接アクセスすることが一切できなくなります。 2. PLIST を確認し、share/mime ディレクトリー以下の項目のうち、 share/mime/ packages 以下に置かれるファイル以外のものをすべて削除します。このディレクト リーについては update-mime-database プログラムが自動的に処理しますが、除外 したファイルはパッケージ依存のファイルなので、ファイルをインストールしたパ ッケージが自分で削除する必要があります。 3. PLIST から share/mime/* ディレクトリーをすべて削除します。これらは shared-mime-info プログラムが処理します。 19.6.15. intltool を使うパッケージ パッケージが構築時に intltool を使う場合は、 intltool を USE_TOOLS に追加します 。こうすると、パッケージの配布ファイルに附属する intltool ではなく、 pkgsrc の intltool を強制的に使うようになります。 この仕組みは、intltool 構築時の依存関係を追跡して、利用可能な最新版を使います。 この方法を使うことで、リリース後にできたバグ修正も適用することができます。 19.6.16. 起動スクリプトをインストールするパッケージ パッケージに rc.d スクリプトが附属する場合、このスクリプトは、標準では起動ディ レクトリーにコピーされませんが、 mk.conf にオプション PKG_RCD_SCRIPTS=YES を追 加指定すると、パッケージのインストール時に、スクリプトが /etc/rc.d 以下にコピー されます。また、パッケージのアンインストール時には、自動的にスクリプトが削除さ れます。 19.6.17. TeX モジュールをインストールするパッケージ パッケージが、TeX パッケージを texmf ツリーにインストールする場合は、 texmf ツ リーの ls-R データベースを更新する必要があります。 Note kpathsea のような主たる TeX パッケージ以外のパッケージは、 ${PREFIX}/share/ texmf ではなく ${PREFIX}/share/texmf-dist 内にファイルをインストールするように します。 1. ../../print/kpathsea/texmf.mk をインクルードします。こうすると、インストー ル時とアンインストール時に ls-R を再構築してくれます。 2. パッケージが ${PREFIX}/share/texmf-dist の texmf ツリー以外の texmf ツリー にファイルをインストールする場合は、 TEX_TEXMF_DIRS を、データベースの更新 が必要となる texmf ツリーをすべて並べたリストに設定します。 パッケージが、updmap を使って登録する必要があるフォントマップファイルもイン ストールする場合は、 ../../print/texlive-tetex/map.mk をインクルードしたう えで、 TEX_MAP_FILES と TEX_MIXEDMAP_FILES のいずれかまたは両方を、そのよう なフォントマップファイルをすべて並べたリストに設定します。こうすると、イン ストール時とアンインストール時に updmap が自動的に実行され、 TeX 出力ドライ バー用のフォントマップファイルの有効化や無効化をしてくれます。 3. PLIST には ls-R データベースは一切含めないようにします。このデータベースは teTeX-bin パッケージによってのみ削除されるものだからです。 19.6.18. エミュレーションによるバイナリーの実行に対応したパッケージ パッケージのなかには、あるオペレーティングシステム用のバイナリーを (エミュレー ションに対応した) 別のオペレーティングシステム上で実行するための、ライブラリー や実行ファイルを提供するものがあります。例としては、NetBSD 上で Linux のバイナ リーを実行するものがあげられます。 pkgtools/rpm2pkg は、Linux の rpm パッケージの展開やパッケージ化を補助するもの です。 CHECK_SHLIBS を no に設定して、インストールされた実行ファイル用のライブラリーを 動的リンカーがすべて見つけられることを検査する check-shlibs ターゲットを抑止す ることができます。この検査では標準の動的リンカーを実行するので、エミュレーショ ンパッケージに対しては検査が失敗します。エミュレーションで使われるライブラリー は、標準のディレクトリーには置かれていないからです。 19.6.19. ハイカラーテーマのアイコンをインストールするパッケージ パッケージが、 share/icons/hicolor 以下に画像をインストールするか share/icons/ hicolor/icon-theme.cache データベースを更新するかあるいはその両方をおこなう場合 は、テーマ用の共有ディレクトリーを適切に扱い、キャッシュデータベースを確実に再 構築するために、以下の手順を踏む必要があります。 1. ../../graphics/hicolor-icon-theme/buildlink3.mk をインクルードします。 2. PLIST を確認し、テーマのキャッシュを参照するエントリーを削除します。 3. PLIST が share/icons/hicolor 階層からアイコン用の共有ディレクトリーを削除し ないようにします。これは自動的に処理されるものだからです。 後の 2 点について、 PLIST がこれらを守っていることを確認する最良の方法は、 make print-PLIST を使って作り直すことです。 19.6.20. デスクトップファイルをインストールするパッケージ パッケージが、.desktop ファイルを share/applications 以下にインストールし、その ファイルに MIME 情報が含まれている場合は、それらが MIME データベースに確実に登 録されるようにするために、以下の手順を踏む必要があります。 1. ../../sysutils/desktop-file-utils/desktopdb.mk をインクルードします。 2. PLIST を確認し、 share/applications/mimeinfo.cache ファイルを参照するエント リーを削除します。これは自動的に処理されるものだからです。 最後の点について、 PLIST がこれらを守っていることを確認する最良の方法は、make print-PLIST を使って作り直すことです。 19.7. パッケージに問題があるという印をつける 場合によっては、パッケージの問題をすぐに解決できないことがあります。この場合、 パッケージが壊れていることを表すだけの目印をつけることができます。これをおこな うには、BROKEN 変数を、 (RESTRICTED 変数と同様に) パッケージが壊れている理由に 設定するだけです。利用者がパッケージを構築しようとすると、パッケージはその場で このメッセージを表示して、構築をしないようになります。 BROKEN となったパッケージは、不定期的に pkgsrc から削除されます。 Chapter 20. デバッグ パッケージを作成する時に落ちいりやすい間違いをチェックし、パッケージを動作させ るための手順があります。これは基本的には前のセクションで説明したことと同じです が、デバッグを助けるための方法を追加しています。 * PKG_DEVELOPER=yes を mk.conf で設定しておいてください * pkgtools/url2pkgをインストールし、デバッグ対象のパッケージ用にディレクトリ ーを作ってそこに移動してから、 url2pkg を実行します。 % mkdir /usr/pkgsrc/category/examplepkg % cd /usr/pkgsrc/category/examplepkg % url2pkg http://www.example.com/path/to/distfile.tar.gz * Makefileに、必要な編集を加えます。 * DESCRの内容を書きます * make configure を実行します。 * ドキュメンテーション、およびconfigureの段階でわかった依存関係をすべて、パッ ケージのMakefileに書き加えます。 * 以下を繰り返しおこなって、パッケージを作り上げます % make % pkgvi ${WRKSRC}/some/file/that/does/not/compile % mkpatches % patchdiff % mv ${WRKDIR}/.newpatches/* patches % make mps % make clean root以外のユーザーで作業をおこなうと、改変すべきでないファイルは改変されま せん。特に、構築の段階以外では。 mkpatches, patchdiff および pkgvi は、 pkgtools/pkgdiff パッケージに入っています。 * 必要ならMakefileを修正してください。 Section 11.1, “Makefile”を参考にして ください。 * PLISTを作成します: # make install # make print-PLIST >PLIST # make deinstall # make install # make deinstall これは通常、rootで実行する必要があります。残ったままのファイルがないか調べ ます: # make print-PLIST もし、なにかファイルが見つかれば、それらはPLISTに不足しているので、追加して ください。 * これでPLISTの修正ができました。パッケージを再度インストールして、バイナリー パッケージを作ります: # make reinstall # make package * インストールしたパッケージを削除します: # pkg_delete examplepkg * 上記の make print-PLIST コマンドを繰り返します。今度は何も見つからないはず です: # make print-PLIST * バイナリーパッケージを再インストールします: # pkg_add .../examplepkg.tgz * 遊んでみてください。すべてが機能することを確認してください。 * pkgtools/pkglintに含まれるpkglintを実行し、報告される問題を修正してください 。 # pkglint * 提出してください(もし cvs アクセス可能であればコミットしてください)。 Chapter 21, 提出およびコミットが参考になります。 Chapter 21. 提出およびコミット Table of Contents 21.1. バイナリーパッケージの提出 21.2. ソースパッケージの提出 (NetBSD 開発者以外の方向け) 21.3. パッケージを追加・更新・削除する際の一般的な覚書 21.4. コミット: パッケージのCVSへのインポート 21.5. パッケージを新しいバージョンに更新する 21.6. pkgsrc のパッケージの名前を変更する 21.7. pkgsrcのパッケージを移動する 21.1. バイナリーパッケージの提出 我々は、トロイの木馬等を含まないことを保証するために、pkgsrc 開発者からしかバイ ナリーを受け取りません。これは、誰かを排斥するものではなく、むしろユーザーを保 護するための方針です。しかしながら、あなたの作ったバイナリーパッケージをどこか に置き、配布することは自由に行なってもかまいません。NetBSD 開発者がバルクビルド を実行してパッケージをアップロードしたい場合は、 Section 7.3.8, “バルクビルド の成果をアップロードする”を参照してください。 21.2. ソースパッケージの提出 (NetBSD 開発者以外の方向け) 最初にパッケージが完全かどうか、コンパイル、実行できるかどうかを確認してくださ い。このドキュメントのChapter 20, デバッグ、その他が参考になるでしょう。次に、 パッケージを構成するファイルすべてからなる tar(1) アーカイブを作り、gzip して uuencode してください。最後に、このパッケージを pkgsrc のバグ追跡システムに送信 してください。 send-pr(1) コマンドを使って送信するか、このコマンドがない場合は web ページ http://www.NetBSD.org/support/send-pr.html をご覧ください。この web ページには、説明と、パッケージを提出できるフォームへのリンクがあります。これら のかわりに、 sysutils/gtk-send-pr パッケージを使って提出することもできます。 問題報告においては、カテゴリー (category) は“pkg”とし、問題の概要 (synopsis) にパッケージ名とバージョン番号を含めます。また、説明 (description) のフィールド に、パッケージの簡単な説明 (COMMENT 変数または DESCR ファイルの内容でもOKです) を書きます。uuencode したパッケージのデータは“fix”フィールドに含めます。 複数のパッケージを提出したい場合は、一つのパッケージにつき一つのPRにわけて送っ てください。そうすることで、私たちが追跡しやすくなります。 以上のようにするほか、新しいパッケージは pkgsrc-wip (“pkgsrc work-in-progress ”) に入れることもできます。詳細は、ホームページ http:// pkgsrc-wip.sourceforge.net/ をご覧ください。 21.3. パッケージを追加・更新・削除する際の一般的な覚書 パッケージの追加、更新、移動、および削除は、すべて pkgsrc/doc/CHANGES-YYYY に書 いてください。このファイルを、これまでと同じ形式のまま最新の状態に保つことは非 常に重要なことです。なぜなら、このファイルはスクリプトにより www.NetBSD.org や 他のサイトのページを自動的に更新するために使用されているからです。また、pkgsrc/ doc/TODO ファイルを確認し、今回更新あるいは削除したパッケージのことが書かれてい る場合は、その部分を削除してください。 パッケージの PKGREVISION を引き上げた時に、その変更がセキュリティーに関するもの やその他関連のあるものである場合は、 pkgsrc/doc/CHANGES-YYYY に載せるようにしま す。依存性の更新にともなう大量の引き上げについては、ここには書かないでください 。これら以外の場合は、書くべきかどうかは開発者が自分で決めることです。 正しい CHANGES-YYYY の項目を作るのを手伝ってくれる make ターゲット、 make changes-entry があります。このターゲットは CTYPE および NETBSD_LOGIN_NAME とい うオプションの変数を使います。一般的な使い方は、まず CHANGES-YYYY ファイルを (あとで衝突して修正する必要が起こらないように) 最新の状態にした上で、パッケージ のディレクトリーに cd します。パッケージを更新した場合は make changes-entry だ けで十分です。新規パッケージの追加や、パッケージの移動または削除の場合は、コマ ンドラインで CTYPE 変数を "Added", "Moved" または "Removed" に設定します。ロー カルのログイン名が NetBSD のログイン名と異なる場合は、mk.conf で NETBSD_LOGIN_NAME を設定することができます。また、このターゲットは、TODO ファイ ルから、当該パッケージの項目を自動的に削除してくれます。最後に、 make changes-entry-commit などとして pkgsrc/doc/CHANGES-YYYY の変更を commit するの を忘れないでください。なお、cvs.NetBSD.org から直接チェックアウトせずに、ローカ ルにコピーしたリポジトリーを使って作業している場合などは、 USE_NETBSD_REPO=yes を設定するとよいでしょう。こうすると、 cvs コマンドでは本家リポジトリーを使うよ うになります。 21.4. コミット: パッケージのCVSへのインポート このセクションは、pkgsrcリポジトリーへの書き込みアクセス権限を持っている pkgsrc 開発者にのみ意味があるものです。cvsはカレントディレクトリーからの相対位置にファ イルをインポートすることと、cvs importコマンドに渡したパス名からリポジトリー中 のファイルの位置が決まることを忘れないでください。新しく作ったパッケージは、“ TNF”のベンダータグと“pkgsrc-base”のリリースタグでインポートしてください。例 えば: $ cd .../pkgsrc/category/pkgname $ cvs import pkgsrc/category/pkgname TNF pkgsrc-base また、インポートに使ったディレクトリーは、忘れずに邪魔にならないところに移して おいてください。そうしておかないと、ソースツリーを次に“cvs update”したときに cvsが文句を言います。さらに、この新しいパッケージを、categoryの Makefileに忘れ ずに追加してください。 初回のインポートでは、コミットメッセージにDESCRファイルの内容を含めておき、どう いうパッケージなのかがメーリングリストの読者にわかるようにしてください。 新しいパッケージを追加する場合は、“cvs add”ではなく“cvs import”を使うように してください。"cvs import"なら、単一のコマンドですべて記述することができ、また 、一貫したタグを打つことができるからです。 21.5. パッケージを新しいバージョンに更新する パッケージを更新するときは、新旧バージョン間の変更点の簡潔で適切で意味のある要 約を、コミットログに必ず書いてください。そうすべき理由はいろいろあります: * URLは不安定なものであり、時間がたつと変わることがあります。完全になくなるか もしれませんし、新しい情報に書き換わるかもしれません。 * 新旧バージョン間の変更点をCVSリポジトリーに保持しておくと、cvsやanoncvsの利 用者にとって、非常に便利です。 * 新旧バージョン間の変更点をCVSリポジトリーに保持しておくと、pkgsrc-changes メーリングリストの読者が、パッケージをいつ更新するかの戦術を立てられるよう になり、非常に便利です。 また、あるパッケージに新しいバージョンがリリースされたというだけの理由で、 CVS リポジトリー上のパッケージを更新しないほうがいいことを認識してください。私たち は、pkgsrcに含まれるパッケージに関して保守的であることを好みます。というのも、 開発版やベータ版のパッケージは、pkgsrcが使われる場面のほとんどに対して、まった くふさわしくないからです。どのバージョンをpkgsrcに入れるのがよいか、分別をもっ て判断してください。新機能(テストされていない機能があるかもしれません)よりも安 定性のほうが好ましいことを念頭に置いてください。 21.6. pkgsrc のパッケージの名前を変更する パッケージ名の変更は、なるべくしないようにしてください。 パッケージ名を変更する際には、かならず、他の Makefile やオプションや buildlink などで古い名前を参照している箇所をすべて修正します。 パッケージ名を変更する際には、さらに、 SUPERSEDES を旧パッケージのパッケージ名 と dewey 式のバージョン番号に設定します。名前が複数回変わっている場合は、複数並 べて設定することができます。これで、新しいパッケージで旧名のパッケージを置き換 える作業は完了です。 なお、CHANGES-YYYY ファイルにおける“successor”の記述は、必ずしも、supersedes の意味ではありません。successor は、厳密な同等品でなくても、代替として使えるも のを助言するものでもいいからです。 21.7. pkgsrcのパッケージを移動する パッケージの名前の変更や移動は、しないほうがよいのですが、それでも必要な場合は 、以下の手順でおこないます。 1. パッケージのディレクトリーをどこかにコピーします。 2. コピーしたものからCVSディレクトリーをすべて削除します。 手順1,2は、以下のようにすることもできますので、今後の作業にはこちらを使って ください: % cvs -d user@cvs.NetBSD.org:/cvsroot export -D today pkgsrc/category/package 3. CATEGORIESを修正します。また、“../../category/package”のかわりに単に“../ package”とすることができるDEPENDSのパスをすべて修正します。 4. 修正後のパッケージの Makefile で、 PREV_PKGPATH を、移動前のカテゴリー/パッ ケージのパス名に設定します。この PREV_PKGPATH は、パッケージの更新を pkgsrc の構築によっておこなうツールが使います。たとえば、そういったツールは pkg_summary(5) データベースから (SUPERSEDES がない場合) PREV_PKGPATH を検索 して、これをもとにパッケージの移動後の PKGPATH を調べることができます。なお 、この検索で複数のパスが見つかることもありえるので、ツールの側では PKGBASE もあわせて検査します。この PREV_PKGPATH の値を設定するのは、 SUPERSEDES が 設定されない場合 (つまり、PKGBASE が変わらない場合) です。 5. 新しい場所で、修正後のパッケージをcvs import します。 6. このパッケージに依存しているパッケージを調べます: % cd /usr/pkgsrc % grep /package */*/Makefile* */*/buildlink* 7. 手順5で見つかったものに対して、このパッケージへのパスを、新しい場所を指すよ うに修正します。 8. 古い場所で、移動前のパッケージをcvs rm (-f)します。 9. oldcategory/Makefile からこのパッケージを削除します。 10. newcategory/Makefile にこのパッケージを追加します。 11. 変更および削除されたファイルを commit します: % cvs commit oldcategory/package oldcategory/Makefile newcategory/Makefile (もちろん、手順5の各パッケージもです)。 Chapter 22. よくある質問 この節では、パッケージ作成中に湧くような疑問と回答を掲載します。あなたがお持ち の疑問に対する答がここにない場合は、まず、他の節を見てみてください。それでも答 が見つからなければ、 pkgsrc-users メーリングリストで尋ねてください。 22.1. MAKEFLAGS, .MAKEFLAGS, MAKE_FLAGS の各変数の違いは? 22.2. MAKE, GMAKE, MAKE_PROGRAM の各変数の違いは? 22.3. CC, PKG_CC, PKGSRC_COMPILER の各変数の違いは? 22.4. BUILDLINK_LDFLAGS, BUILDLINK_LDADD, BUILDLINK_LIBS の各変数の違いは? 22.5. make show-var VARNAME=BUILDLINK_PREFIX.foo したら、空だといわれるのはな ぜ? 22.6. ${MASTER_SITE_SOURCEFORGE:=package/} ってどういうこと? 中身の := がわかり ません。 22.7. パッケージ開発者向けのメーリングリストはどれ? 22.8. pkgsrc の資料はどこにある? 22.9. 少し時間があるんだけど、何をしたらいい? 22.1. MAKEFLAGS, .MAKEFLAGS, MAKE_FLAGS の各変数の違いは? MAKEFLAGS は、 pkgsrc 内部で呼び出される make(1) に渡されるフラグであり、 MAKE_FLAGS は、パッケージを構築するときに MAKE_PROGRAM に渡されるフラグで す。 [FIXME: What is .MAKEFLAGS for?] 22.2. MAKE, GMAKE, MAKE_PROGRAM の各変数の違いは? MAKE は、 pkgsrc の基盤が使う make(1) プログラムへのパスです。GMAKE は、 GNU Make へのパスですが、これを使うためには USE_TOOLS+=gmake する必要があ ります。MAKE_PROGRAM は、パッケージの構築に使われる Make プログラムへのパ スです。 22.3. CC, PKG_CC, PKGSRC_COMPILER の各変数の違いは? CC は、本物の C コンパイラーへのパスで、pkgsrc の利用者が設定することがで きます。 PKG_CC は、コンパイラーのラッパーへのパスです。 PKGSRC_COMPILER は、コンパイラーへのパスではなく、使われるコンパイラーの種類です。最後の 変数に関するさらなる情報は、 mk/compiler.mk をご覧ください。 22.4. BUILDLINK_LDFLAGS, BUILDLINK_LDADD, BUILDLINK_LIBS の各変数の違いは? [FIXME] 22.5. make show-var VARNAME=BUILDLINK_PREFIX.foo したら、空だといわれるのはな ぜ? 最適化のために、一部の変数は“wrapper”の段階以降でしか使えません。 wrapper の段階を“シミュレート”するには、お尋ねのコマンドに PKG_PHASE= wrapper を付け加えます。 22.6. ${MASTER_SITE_SOURCEFORGE:=package/} ってどういうこと? 中身の := がわかり ません。 := は、一見、代入演算子のようですが、そうではありません。 ${LIST: old_string=new_string} という修飾子が make(1) マニュアルページに書かれて おり、 ${SRCS:.c=.o} というのを見たことがあるかもしれませんが、これはこの 修飾子の特殊な形です。この MASTER_SITE_* の事例では、 old_string は空の文 字列、 new_string は package/ です。このため、 : と = がくっついているの です。 22.7. パッケージ開発者向けのメーリングリストはどれ? tech-pkg pkgsrc 開発関連の技術的な議論のためのメーリングリストです。たとえば、 pkgsrc の基盤の変更を求めるフィードバック、新機能の提案、pkgsrc の新 しいプラットフォームへの移植に関する質問、パッケージ保守のための助言 、多数のパッケージに影響のあるパッチ、基盤にバグが見つかったために pkgsrc-users からここに場を移された助けの要請などです。 pkgsrc-bugs send-pr(1) で送られた "pkg" カテゴリーのバグレポートはすべてここに流 れます。ここへバグの報告を直接しないでください。バグの報告には、他の いずれかのメーリングリストを使ってください。 22.8. pkgsrc の資料はどこにある? pkgsrc に関する資料がある場所は、たくさんあります。 * The pkgsrc guide (この文書) は、数多くある pkgsrc の部品について説明 した章を集めたものですが、内容が古くなりがちな章もあります。どの章が そうなのかは、示しにくいのですが。 * メーリングリストのアーカイブ (http://mail-index.NetBSD.org/ 参照) で は、ある機能に関する議論、pkgsrc の基盤の新しい部品の告知や、時にはあ る機能を廃止することにしたという告知などを見ることができます。これの 便利なところは、各記事に日付がつけられていることです。 * mk/ ディレクトリーにあるファイルの多くは、冒頭のコメントで、そのファ イルの目的と、 pkgsrc 利用者やパッケージ作者による使用方法を説明して います。このドキュメンテーションを簡単に見つける方法は、bmake help を 実行することです。 * CVS のログメッセージは豊富な情報源ですが、かなり省略して書かれる傾向 が (特に、頻繁におこなわれる処置に関するログでは) あります。何が変わ ったかを詳細に説明したログもありますが、そのようなものは他の pkgsrc 開発者向けのものであって、平均的な pkgsrc 利用者向けのものではありま せん。ログメッセージは変更点を記録しているだけなので、変更前のことを 知らない場合は、たいして価値がないかもしれません。 * pkgsrc の部品のなかには、“暗黙の文書化”、つまり、資料はそのコードを 書いた開発者の頭の中にあるだけ、というものもあります。このようなもの の情報を入手するには、 cvs annotate コマンドを使ってコードを書いた人 を調べて、後から他の人が見られるように (前の説明参照) tech-pkg メーリ ングリストで尋ねてください。担当の開発者がメールを確実に読むようにす るため、その人に CC してもよいでしょう。 22.9. 少し時間があるんだけど、何をしたらいい? これは、まだよく尋ねられてはいないのですが、答えてしまいます。 * pkg_chk -N (このコマンドは pkgtools/pkg_chk パッケージにあります) を 実行します。こうすると、インストールしているパッケージについて、もっ と新しいバージョンがあるが pkgsrc では更新されていないものを教えてく れます。 * pkgsrc/doc/TODO を見ます ? このファイルには、提案されている新しいパッ ケージの一覧と、実現したらよい pkgsrc の整理や拡張の一覧が載っていま す。 * pkgsrc-wip review メーリングリストでレビュー依頼が出ているパッケージ をレビューします。 Chapter 23. GNOME のパッケージングおよび移植 Table of Contents 23.1. メタパッケージ 23.2. GNOME アプリケーションをパッケージングする 23.3. GNOME を新バージョンに更新する 23.4. 修正の指針 GNOME の web サイトによれば、 GNOME プロジェクトでは二つのものを提供します: 一つは、利用者にとって直観的 で魅力的なデスクトップである GNOME デスクトップ環境です。もう一つは、アプリ ケーション構築用の広範な枠組である GNOME 開発プラットフォームで、その他のデ スクトップに統合されています。 pkgsrc を使うと、多くのプラットフォームのもとで、完全な GNOME 環境の自動的な構 築やインストールを透過的におこなうことができます。 pkgsrc は、buildlink3 技術、 ラッパーとツールの枠組や、設定ファイルの自動処理があることから、 GNOME の構築お よびパッケージングシステムとして最も高度なもののひとつであると、自信を持ってい うことができます。インストールされたソフトウェアの構成要素を、完全にきれいにア ンインストールできるようにするため、多くの取り組みがおこなわれています。 pkgsrc は NetBSD の公式パッケージングシステムなので、上述したことはすなわち、 NetBSD のもとで GNOME が機能するようにするために、多大な取り込みがおこなわれて いるということです。最近では、DragonFly BSD も pkgsrc をパッケージングシステム として採用しており、同 OS のもとで GNOME の構築やインストールができるようにする ため、移植性に関する修正を数多く寄せてくれています。 あなたの力が必要です あなたの空き時間を NetBSD のために使っていただけたら、 pkgsrc および GNOME は、 おもしろげな新機能の導入に注力することができます。まずは保留中の作業の一覧をご 覧ください。NetBSD のもとで GNOME デスクトップを完全に機能させるまでには、まだ 長い道が残っているため、あなたの助けが必要なのです。 23.1. メタパッケージ pkgsrc には、GNOME 関連のメタパッケージが三つあります。 * meta-pkgs/gnome-base: GNOME デスクトップ環境の中核部分を提供します。これは GNOME を正常に起動させるために必要なものだけからなっており、日々の操作をす るうえで重要な機能が足りないかもしれません。このパッケージの考え方は、末端 利用者がこのパッケージの上層で独自の構成をできるようにするためのものであり 、このメタパッケージをまずインストールして最低限の機能を整えてから、個々の アプリケーションを追加するというものです。 * meta-pkgs/gnome: GNOME プロジェクトが定義する GNOME プラットフォームおよび デスクトップの、完全なインストールを提供します。これは、GNOME の公式 FTP サ ーバーの platform/x.y/x.y.z/sources および desktop/x.y/x.y.z/sources ディレ クトリーで配布されている構成要素にもとづいています。このディレクトリーにあ る開発者専用ツールは、他の構成要素の正常動作のために必要な場合以外は、イン ストールされません。同様に、バインディングセット附属のパッケージ (bindings/ x.y/x.y.z/sources) も、末端利用者向けの構成要素からの依存により必要な場合以 外は、含まれません。このパッケージは、meta-pkgs/gnome-base を「拡張」するも のです。 * meta-pkgs/gnome-devel: GNOME の構成要素を CVS リポジトリーから取得した場合 用に、その構築のために必要なツールをすべてインストールします。これらは autogen.sh スクリプトを正常に動かすために必要なものです。 以上の各パッケージでは、更新を簡単にできるようにするため、 DEPENDS 行が依存性に もとづく順序で並べられています。あるパッケージが、それより前に並んでいるパッケ ージに依存することはできますが、後に並んでいるパッケージに依存することはできま せん。この順序を守ることは、更新を簡単にするために非常に重要なことです。これを 、アルファベット順に並びかえてはいけません。 23.2. GNOME アプリケーションをパッケージングする ほとんどすべての GNOME アプリケーションは C で書かれており、構築システムとして 共通のツール一式を使っています。C 以外の言語 (Python など) を新たに追加する場合 は事情が異なりますが、最低限必要なツールについては、以下のことが参考になるでし ょう。 * ほとんどすべての GNOME アプリケーションは、構築システムとして GNU Autotool を使っています。GNOME に限らない一般的な決めごととして、このことをパッケー ジに教えてやる必要があります。 GNU_CONFIGURE=yes USE_LIBTOOL=yes USE_TOOLS+=gmake * パッケージが pkg-config を使って依存性を決めている場合は、必要なユーティリ ティーのリストに同ツールを追加します。 USE_TOOLS+=pkg-config さらに、構築の過程の最後で pkgtools/verifypc を使って、作ったパッケージのな かで指定した依存性に間違いがなく、要求バージョンもすべて正しいことを確認し ます。 * パッケージが intltool を使う場合は、依存性を処理するため、また、利用可能な 最新バージョンを使うようにするため、かならず intltool を USE_TOOLS に追加し ます。 * パッケージが gtk-doc (ドキュメンテーション生成ユーティリティー) を使う場合 は、依存性を追加してはいけません。このツールは巨大なものですし、パッケージ の distfile には生成済みのドキュメンテーションが附属しているはずだからです (そうなっていない場合はバグですので、報告してください)。このようなパッケー ジでは、以下のようにして gtk-doc を無効化するようにします (標準で無効になっ ている場合を除く)。 CONFIGURE_ARGS+=--disable-gtk-doc HTML ファイルの標準でのインストール場所 (share/gtk-doc/) は適 切なものなので、パッケージが別の場所へのインストールを要求した場合以外は変 更しないようにします。場所を変更すると、devhelp などのプログラムがファイル を開けなくなってしまいます。場所の変更は、以下のようにしておこなうことがで きます。 CONFIGURE_ARGS+=--with-html-dir=${PREFIX}/share/gtk-doc/... GNOME は、インストール用プレフィックスの下に複数の共有ディレクトリーおよびファ イルをもっており、データベースの保守のために使っています。ここでいう共有とは、 同じディレクトリーやファイルを複数の異なるパッケージが使うことであり、 PLIST の 内容の衝突を起こします。現在、pkgsrc にはもっともありがちな部類の事例を扱うため の仕組みがあるので、ファイルのリストには必ず @unexec ${RMDIR} という行を書くよ うにし、共有のファイルは書かないようにしてください。この仕組みを使わずに独自の 処理をしてしまうと、作成したパッケージが、正しくないものになってしまうでしょう 。 以下の表は、共有ディレクトリーまたはファイルを使うような、ありがちな状況を挙げ たものです。各状況について、適切な処置を示しています。ここで示した処置を適用し た後は、 make print-PLIST を使ってパッケージのファイルのリストを作り直し、それ が正しいことを確認してください。 Table 23.1. GNOME パッケージ用の PLIST の扱い +-----------------------------------------------------------------------------+ | パッケージの挙動 | 処置 | |-----------------------------------------+-----------------------------------| |share/omf 以下に OMF ファイルをインストー|Section 19.6.10, “scrollkeeper/ | |ルする。 |rarian のデータファイルをインストー| | |ルするパッケージ”参照。 | |-----------------------------------------+-----------------------------------| |share/icons/hicolor 階層以下にアイコンを |Section 19.6.19, “ハイカラーテーマ| |インストールする、または share/icons/ |のアイコンをインストールするパッケ | |hicolor/icon-theme.cache を更新する。 |ージ”参照。 | |-----------------------------------------+-----------------------------------| |share/mime/packages 以下にファイルをイン |Section 19.6.14, “MIME データベー | |ストールする。 |スの拡張をインストールするパッケー | | |ジ”参照。 | |-----------------------------------------+-----------------------------------| |share/applications 以下に .desktop ファイ|Section 19.6.20, “デスクトップファ| |ルをインストールし、かつそのファイルに |イルをインストールするパッケージ” | |MIME 情報が含まれる。 |参照。 | +-----------------------------------------------------------------------------+ 23.3. GNOME を新バージョンに更新する GNOME を全体として見た場合、二種類の更新があります。 メジャーアップデート GNOME 3 (がいつか登場したとして) への道程は、まだ相当長いものなので、ここで は、バージョンが 2.X から 2.Y (Y は X より大きい偶数) に上がることをメジャ ーアップデートということにします。メジャーアップデートでは構成要素のコード に多くの変更がおこなわれており、 GNOME のほとんどすべての distfile が新しい バージョンに更新されているため、更新は面倒な作業になります。変更のなかには 、以前のバージョン系列との API や ABI の互換性を損なうものがあることもあり ます。このような事情があるので、破損を最小限にするために、更新は一度にまと めておこなう必要があります。 通常、メジャーアップデートでは、約 80 個のパッケージが更新されるほか、新し いパッケージがいくつか追加されます。 マイナーアップデート ここでは、バージョンが 2.A.X から 2.A.Y (Y は X より大きい数) に上がること をマイナーアップデートということにします。 GNOME の構成要素すべてが更新され るわけではないことや、枝内でのバージョン増大に沿った形でおこなうことができ 、 API や ABI の互換性が失われないことなどから、更新は簡単におこなうことが できます。 マイナーアップデートで更新されるパッケージ数は、大きく変動することがありま すが、通常は約 50 個です。 pkgsrc の GNOME 構成要素を新しい安定版リリース (メジャーまたはマイナー) に更新 するためには、以下の手順に沿っておこなうようにします。 1. 以下のコマンドを使って、新しいリリースを構成する tarball の一覧を作ります。 こうすると、構成要素の distfile の全一覧が list.txt ファイルに得られます。 % echo ls "*.tar.bz2" | \ ftp -V ftp://ftp.gnome.org/pub/gnome/platform/x.y/x.y.z/sources/ | \ awk '{ print $9 }' >list.txt % echo ls "*.tar.bz2" | \ ftp -V ftp://ftp.gnome.org/pub/gnome/desktop/x.y/x.y.z/sources/ | \ awk '{ print $9 }' >>list.txt 2. 各メタパッケージの Makefile を開き、バージョンを更新後のリリースのものに上 げます。 3 個のメタパッケージは常にバージョンに整合性をもたせるようにします 。 PKGREVISION がある場合は、当然、削除します。 3. 各メタパッケージについて、 DEPENDS 行を更新して、前掲のコマンドで得られた最 新バージョンと合致するようにします。これより新しいバージョンにしては (たと えそれが FTP サーバーにあったとしても) いけません。このメタパッケージは、特 定の GNOME リリースを構成するバージョンだけを揃えることを意図したものだから です。ただし、統合デスクトップを使用する上での深刻な問題が新しいバージョン で解決する場合には、例外的に認められます。これは、たいていの場合、 GNOME に よる新しいバージョンは使わずに、 pkgsrc 内でのリビジョンを上げる形をとりま す。 list.txt ファイルに現れないパッケージは、利用可能な最新バージョンに (pkgsrc にそれがあれば) アップデートするようにします。たとえば、meta-pkgs/ gnome-devel メタパッケージに含まれるパッケージのうち GNU Autotools に依存す るパッケージがこれに該当します。 4. 変更後のメタパッケージからパッチを作り、そこから「新規の」行を抽出します。 この結果から、pkgsrc のどのパッケージをどの順序でアップデートする必要がある か、概要がわかります。 % cvs diff -u gnome-devel gnome-base gnome | grep '^+D' >todo.txt 5. デスクトップのメジャーアップデートの場合は、インストールされているパッケー ジをすべて削除し、まっさらな状態から始めることをおすすめします。 6. ここが、もっとも長い作業が必要なところです。 todo.txt に書き出された各パッ ケージを、並んでいる順序どおりに更新するという作業を繰り返します。デスクト ップのメジャーアップデートの場合は、全パッケージの更新が完了するまで commit してはいけません。未更新のパッケージを壊す可能性があるからです。 7. パッケージが新しいものになり動作する状態になったら、個々のパッケージを一つ ずつ、適切な log メッセージをつけて commit してゆきます。最後に、3 個のメタ パッケージの更新と、これらに対応する doc/CHANGES- および pkgsrc/doc/ TODO ファイルの変更を commit します。 23.4. 修正の指針 GNOME は 100 のパッケージを擁する、pkgsrc の大きな構成要素です。 GNOME パッケー ジに移植性に関する修正を施した場合は、常に、常に、常に、 GNOME 本家の開発者に還 元していただくということが重要です (Section 11.3.5, “作者へのフィードバック” 参照)。彼らに移植性についての注意を喚起して、将来のバージョンが無修正で NetBSD で構築できるようにするためには、そうするしかないのです。 pkgsrc 独自のパッチを 少なくすればするほど、将来の更新は楽になります。 GNOME のメジャーアップデート対 応に取り組む開発者としては、皆さんにそのようにしていただけるとありがたく思いま す。 最もありふれたバグの報告先は、GNOME の Bugzilla と freedesktop.org の Bugzilla です。GNOME の構成要素すべてがこれらをバグ追跡用に使っているわけではありません が、ほとんどはこれらを使っています。バグ報告に際しては、常に、現在起きている問 題や、移植性を最大限にするためにはどのように改良したらよいかについて、詳細に説 明するようにし、また、可能であれば CVS の head に対するパッチをつけてください。 詳しく書けば書くほど、パッチが採用される可能性が高くなります。 また、プリプロセッサーを使った細工で移植性の問題を修正するようなことはしないで ください。 FreeBSD で GNOME に取り組む人たちは、彼らのオペレーティングシステム への GNOME の移植にあたり大きな仕事をしていますが、このせいで、公式の GNOME の ソースに __FreeBSD__ や、これと同類のマクロの検査が蔓延してしまっています。これ は移植性を損なうものです。詳細は、私たちのパッチ作成の指針 (Section 11.3.4, “ パッチ作成の指針”) をご覧ください。 Part III. pkgsrc 基盤の内部 この部では、開発者向けの手引きに書かれているインターフェースの背後にある基盤に 関するあらゆることを扱います。パッケージのメンテナーをしているだけの人には、こ の部は必要ないはずです。 Table of Contents 24. pkgsrc の基盤の設計 24.1. 変数定義の意図するもの 24.2. 問題を未然に防ぐ 24.3. 変数の評価 24.3.1. 読み込み時 24.3.2. 実行時 24.4. 変数の仕様を定める方法は? 24.5. Makefile の断片のインターフェースを設計する 24.5.1. 引数を伴うプロシージャー 24.5.2. 引数に応じたアクション 24.6. ファイルが読み込まれる順序 24.6.1. bsd.prefs.mk での順序 24.6.2. bsd.pkg.mk での順序 25. 退行テスト 25.1. 退行テストの枠組 25.2. 退行テストを実行する 25.3. 新しい退行テストを追加する 25.3.1. 上書き可能な関数 25.3.2. 補助関数 26. pkgsrc を移植する 26.1. pkgsrc を未対応のオペレーティングシステムに新たに移植する 26.2. 未対応のコンパイラーに新たに対応させる Chapter 24. pkgsrc の基盤の設計 Table of Contents 24.1. 変数定義の意図するもの 24.2. 問題を未然に防ぐ 24.3. 変数の評価 24.3.1. 読み込み時 24.3.2. 実行時 24.4. 変数の仕様を定める方法は? 24.5. Makefile の断片のインターフェースを設計する 24.5.1. 引数を伴うプロシージャー 24.5.2. 引数に応じたアクション 24.6. ファイルが読み込まれる順序 24.6.1. bsd.prefs.mk での順序 24.6.2. bsd.pkg.mk での順序 pkgsrc の基盤は、Makefile の小さな断片がたくさん集まってできています。それぞれ の断片に、適切なインターフェースを定義することが必要です。本章では、そのような インターフェースの何たるかを説明します。 24.1. 変数定義の意図するもの pkgsrc の基盤において変数が定義されている場合、変数が定義されている場所や定義の 方法自体が、その変数の使用目的について多くを語っています。また、変数を定義して いるファイルの冒頭のコメントや、この手引きに、さらなる資料があることもあります 。 特別なファイルとして、 mk/defaults/mk.conf があります。このファイルには、利用者 が定義する変数がすべて書かれています。これらの変数のなかには ?= 演算子を使って 定義されているものもありますが、そうでないものは、何かを定義すると“yes”を意味 することになるため、定義されていません。これらの変数はすべて、 pkgsrc 利用者が MAKECONF ファイルで定義して上書きすることができます。 このファイル以外では、以下のようなならわしとなっています。 ?= 演算子を使って定 義されている変数は、個々のパッケージで上書きすることができます。 また、= 演算子を使って定義されている変数は、実行時に読み出し専用で使うことがで きます。 変数名が下線で始まる変数は、 pkgsrc の基盤以外からは一切読み書きできません。こ れらは、特記のない限り、変更してもかまいません。 Note 以上のならわしは、現在のところ、 pkgsrc の基盤全体に一貫して適用されているわけ ではありません。 24.2. 問題を未然に防ぐ リストを含む変数はすべて、標準状態では空になっているものです。このならわしに従 わない変数は、 USE_LANGUAGES と DISTFILES の二つです。この二変数は、パッケージ の Makefile (その他、ここからインクルードされるファイル) において、 += 演算子を 使って単純に変更することができません。あらかじめ値が設定されているかどうかや、 何が設定されているかがまったくわからないからです。 DISTFILES については、パッケ ージ側で標準の値が“わかっている”ので、以下の例のように定義するだけですみます 。 DISTFILES= ${DISTNAME}${EXTRACT_SUFX} additional-files.tar.gz このような標準の値を使っているために、同じ値が多くのパッケージの Makefile に現 れます。 USE_LANGUAGES についても同様ですが、こちらは、標準の値 (“c”) が非常 に短いために目立ちません。とはいえ、多くのファイルにこの値が書かれています。 24.3. 変数の評価 24.3.1. 読み込み時 変数の評価は、変数が使われる文脈によって、読み込み時におこなわれる場合と、実行 時におこなわれる場合があります。変数が読み込み時に評価されるのは、以下のような 文脈においてです。 * := および != 演算子の右辺 * .if や .for のような make ディレクティブ * (訳註: make(1) の) 依存性を記述した行。 特別な例外として、.for ループの反復変数があります。これは、どの文脈で使われるか にかかわらず、インライン展開されます。 変数の値は読み込みによって変わる可能性があるので、誤って評価することのないよう 注意する必要があります。読み込み時に評価してはいけない変数の典型例は、 DEPENDS および CONFIGURE_ARGS です。評価の結果何が起きるかをわかりやすくするため、以下 の例を見てください。 CONFIGURE_ARGS= # none CFLAGS= -O CONFIGURE_ARGS+= CFLAGS=${CFLAGS:Q} CONFIGURE_ARGS:= ${CONFIGURE_ARGS} CFLAGS+= -Wall このコードからわかることは、:= 演算子を使うと、容易に、予期しない結果を生むとい うことです。最初の段落はごくふつうのコードです。二つ目の段落では CONFIGURE_ARGS を評価しており、この結果、 CFLAGS=-O になります。三つ目の段落では、 -Wall を CFLAGS に付け加えていますが、この追加が CONFIGURE_ARGS には反映されません。実際 のコードではたいてい、この三つの段落が完全に無関係のファイルに現れます。 24.3.2. 実行時 ファイルがすべて読み込まれた後は、変数の値は一切変更することができません。シェ ルコマンド内で使われる変数は、この時点で展開されます。 24.4. 変数の仕様を定める方法は? バグや (ほとんどは文書化されていない) 方針への違反を検出するために、変数の定義 や使い方を制限する方法はたくさんあります。詳細は、 pkglint の開発者向けドキュメ ンテーションをご覧ください。 24.5. Makefile の断片のインターフェースを設計する ほとんどの .mk ファイルは、以下の二種類のいずれかに分類されます。一つのファイル が複数の種類の性質を持つと、見つけにくいバグの原因となることがしばしばあるので 、そういうことは避けるようにします。 24.5.1. 引数を伴うプロシージャー 伝統的な命令型プログラミング言語の言葉で説明すると、いくつかの .mk ファイルはプ ロシージャーということになります。プロシージャーは入力引数をとり、?インクルード された後に? 出力引数を返します。Makefile 内の変数はすべて大域的なスコープをもつ ため、すでに別の意味で使われている引数名を使わないよう注意する必要があります。 たとえば、PKGNAME は、引数名としては不適切なものです。 プロシージャーは、プリプロセッシングの際に完全に評価されます。このため、プロシ ージャーを呼ぶときには、入力引数はすべて完全に解決可能である必要があります。た とえば、 CONFIGURE_ARGS は、たいていは、プロシージャーを呼んだ後にテキストが追 加されることから、変数の一部しかプロシージャーに渡されないことになるので、決し て入力引数として使ってはいけません。また、他の変数から導かれる値への参照は、プ ロシージャーの呼び出しの後に更新されます。 プロシージャーは、その出力引数を、プリプロセッシングディレクティブ内で使うもの として、または、実行時のみに利用可能なものとして、いずれかを宣言することができ ます。後者は、他の実行時変数への参照を含む変数用です。 プロシージャーは、複数の呼び出しが可能なように書くものです。つまり、ファイルに 多重インクルードの防護策を施してはいけません。 プロシージャーの例としては、 mk/bsd.options.mk や mk/buildlink3/bsd.builtin.mk があります。引数が読み込み時に評価されることを表すため、引数は := 演算子を使っ て与えます。この演算子は、この目的のためだけに使うようにします。 24.5.2. 引数に応じたアクション アクションファイルは、入力引数をとり、実行時変数を定義することができます。読み 込み時変数を定義することはできません。アクションファイルには pkgsrc の基盤によ って暗黙のうちにインクルードされるものもありますが、そのようなもの以外は明示的 にインクルードする必要があります。 アクションファイルの例としては、 mk/subst.mk があります。 24.6. ファイルが読み込まれる順序 パッケージの Makefile は、通常、一連の変数の定義からできており、最後の行で .. /../mk/bsd.pkg.mk ファイルをインクルードしています。コンパイラーや X11 の実装の 種類など、特定の機能の有無を問い合わせる必要がある場合は、最後のインクルードの 前に、これ以外の各種 *.mk ファイルをインクルードすることができます。 .if や .for のようなプリプロセッサーディレクティブを多用しているので、ファイルを読み込 む場所と順序が問題になります。 本節では、各種ファイルをどこで読み込むか、および、その順序の理由を説明します。 24.6.1. bsd.prefs.mk での順序 bsd.prefs.mk で最初におこなわれることは、 OPSYS, OS_VERSION, MACHINE_ARCH など 、基本的な変数をいくつか定義することです。 次に、MAKECONF (通常は mk.conf) で指定されているファイルから、ユーザーによる設 定が読み込まれます。それから、ユーザーによって上書きされたもの以外の変数が mk/ defaults/mk.conf から読み込まれます。 ユーザーによる設定の後に、システムの設定とプラットフォームの設定が読み込まれま す。これらはユーザーによる設定を上書きすることがあります。 その後、ツールの定義が読み込まれます。この時点では、ツールのラッパーはまだ影響 しません。ラッパーは、パッケージを構築する時に影響をおよぼします。このため、ツ ール名を直接使うのではなく、適切な変数を使う必要があります。 最後に、ラッパーおよびパッケージシステムのフレーバーから、必須の変数がいくつか 、パッケージ構築過程の初期段階でキャッシュされていた変数とともに、読み込まれま す。 24.6.2. bsd.pkg.mk での順序 最初に、bsd.prefs.mk が読み込まれます。 次に、パッケージ側で定義されない変数の標準状態の値を定義している、各種の *-vars.mk ファイルが読み込まれます。この変数は、後になって、無関連のファイルで 使われる可能性もあります。 その次に、bsd.pkg.error.mk ファイルから error-check ターゲットが提供されます。 このターゲットは、 DELAYED_ERROR_MSG または DELAYED_WARNING_MSG を使う他のター ゲットすべてに対して、特別な依存性として追加されます。 その後、hacks.mk から、パッケージ固有のハックがインクルードされます。 そして、他の各種ファイルのインクルードが続きます。この段階でインクルードされる ファイルのほとんどは、インクルードされる順序に関して依存性を持ちませんが、なか には依存性を持つものもあります。 ここで、PKG_FAIL_REASON と PKG_SKIP_REASON を検査するコードが実行されます。ここ までの段階でインクルードされるすべてのファイルに対しては、この両変数の使用が制 限されます。これより後にインクルードされるファイルでは、黙って無視されます。 それから、目的のターゲットに対応するファイルが、この後で実行される順序でインク ルードされますが、実際の順序は問題とはならないはずです。 最後に、何ら興味深い変数を設定するものではなく、実行される make ターゲットを定 義するだけのファイルが、さらにいくつかインクルードされます。 Chapter 25. 退行テスト Table of Contents 25.1. 退行テストの枠組 25.2. 退行テストを実行する 25.3. 新しい退行テストを追加する 25.3.1. 上書き可能な関数 25.3.2. 補助関数 pkgsrc の基盤は多くのコードベースの集合体であり、熟考のすえ作られた各小片の周辺 を少し変更しただけで pkgsrc が使い物にならなくなるであろう曲り角がたくさんあり ます。ほとんどの変更によって pkgsrc が壊されることを防ぐため、 pkgsrc の基盤の 重要な部分に変更を加える場合は、常に一連の退行テストを実行するようにします。本 章では、pkgsrc において退行テストがどのように機能するか、および、新しいテストを どのように追加すればよいかを、説明します。 25.1. 退行テストの枠組 25.2. 退行テストを実行する まず、pkgtools/pkg_regress パッケージをインストールする必要があります。このパッ ケージには pkg_regress コマンドが附属しており、あとは、このコマンドを実行するだ けで、 regress カテゴリーにあるテストをすべて実行してくれます。 25.3. 新しい退行テストを追加する regress カテゴリー内のディレクトリーのうち、 spec というファイルを含むものは、 それぞれがひとつの退行テストに対応しています。 spec ファイルはシェルプログラム で、 pkg_regress コマンドからインクルードされます。以下の関数は、必要に応じて上 書きすることができます。 25.3.1. 上書き可能な関数 各関数は引数をとりません。関数はいずれも、“set -e”された状態の下で呼ばれるの で、テストにおいて実行される各コマンドの終了コードを、注意して確認してください 。 do_setup() この関数は、テスト用に環境変数を準備します。標準では、何もしません。 do_test() この関数は、テストを実際に実行します。標準では、この関数は TEST_MAKE を引数 MAKEARGS_TEST で呼んで、エラーメッセージをはじめとする出力をファイル TEST_OUTFILE に書き込みます。 check_result() この関数は、テスト実行後に実行するもので、ふつうは、実際の出力を予想したも のと比較するために使います。これにより、次節のようなさまざまな補助関数が使 えるようになります。 do_cleanup() この関数は、テストの実行が終わった後に、すべての掃除をします。標準では、何 もしません。 25.3.2. 補助関数 exit_status(expected) この関数は、do_test() 関数の終了コードを、第一引数と比較します。異なる場合 は、テストは失敗します。 output_require(regex...) この関数は、各引数について、 do_test() の出力が拡張正規表現に一致することを 検査します。一致しない場合、テストは失敗します。 output_prohibit(regex...) この関数は、各引数について、 do_test() の出力が拡張正規表現に一致しないこと を検査します。いずれかの正規表現に一致する場合、テストは失敗します。 Chapter 26. pkgsrc を移植する Table of Contents 26.1. pkgsrc を未対応のオペレーティングシステムに新たに移植する 26.2. 未対応のコンパイラーに新たに対応させる pkgsrc システムはすでに、多くのオペレーティングシステム、ハードウェアアーキテク チャー、およびコンパイラーに移植されています。本章では、pkgsrc の移植性をさらに 高めるために必要な手順を説明します。 26.1. pkgsrc を未対応のオペレーティングシステムに新たに移植する pkgsrc を未対応のオペレーティングシステム (以下、 MyOS とします) に移植するには 、以下のファイルを作成あるいは修正する必要があります。 pkgtools/bootstrap-mk-files/files/mods/MyOS.sys.mk このファイルには、いくつかの基本的な定義、たとえば C コンパイラーの名前が含 まれています。 mk/bsd.prefs.mk OPSYS, OS_VERSION, LOWER_OS_VERSION, LOWER_VENDOR, MACHINE_ARCH, OBJECT_FMT, APPEND_ELF の各変数、その他このファイルに書かれている各変数を定 義するコードを追加します。 mk/platform/MyOS.mk このファイルには、 pkgsrc が使用するプラットフォーム固有の定義が含まれてい ます。まず他のプラットフォーム用のファイルのいずれかをコピーしてから、必要 に応じて編集します。 mk/platform/MyOS.pkg.dist このファイルには、ディレクトリーを並べたリストが、パーミッションビットと所 有権とともに含まれています。ここに含まれるディレクトリーは、明示的に USE_MTREE を設定している各パッケージのインストールに際して、自動的に作成さ れます。この機能は、廃止が予定されています。 mk/platform/MyOS.x11.dist 既存の x11.dist ファイルのいずれかを、 MyOS.x11.dist にコピーするだけです。 mk/tools/bootstrap.mk プラットフォームによっては、ベースシステム附属のツールが pkgsrc で使うには 不十分なことがあります。たとえば sed(1) には、処理可能な行長が短く制限され ているバージョンがたくさんあります。したがって、pkgsrc では別途ツールを用意 しており、このファイルで有効化することができます。 mk/tools/tools.MyOS.mk このファイルでは、 pkgsrc 自身が必要とするツールおよび、別のツールや pkgsrc のパッケージが必要とするツールすべてのパスを定義しています。これらのツール が移植対象のプラットフォームではどこにあるかを調べて、書き足します。 これで、lang/perl5 や shells/bash のような、いくつかの基本的なパッケージが構築 できるようになったはずです。 26.2. 未対応のコンパイラーに新たに対応させる TODO Appendix A. パッケージの簡単な例: bison Table of Contents A.1. ファイル A.1.1. Makefile A.1.2. DESCR A.1.3. PLIST A.1.4. pkglint でパッケージをチェックする A.2. 構築、インストール、パッケージングの手順 私たちは、パッケージコレクションにないソフトウェアをさがし、GNU bisonを選びまし た。バークレーのyaccがすでにソースツリーに存在するので、 bisonを使いたい人はい ないでしょう。しかし、練習という意味では役にたちます。 A.1. ファイル A.1.1. Makefile # $NetBSD$ # DISTNAME= bison-1.25 CATEGORIES= devel MASTER_SITES= ${MASTER_SITE_GNU} MAINTAINER= thorpej@NetBSD.org HOMEPAGE= http://www.gnu.org/software/bison/bison.html COMMENT= GNU yacc clone GNU_CONFIGURE= yes INFO_FILES= bison.info .include "../../mk/bsd.pkg.mk" A.1.2. DESCR GNU version of yacc. Can make re-entrant parsers, and numerous other improvements. Why you would want this when Berkeley yacc(1) is part of the NetBSD source tree is beyond me. A.1.3. PLIST @comment $NetBSD$ bin/bison man/man1/bison.1.gz share/bison.simple share/bison.hairy A.1.4. pkglint でパッケージをチェックする NetBSDパッケージシステムは、 pkgtools/pkglint を含んでいます。このツールはこれ らのファイルの内容をチェックするのを助けてくれます。一度インストールしてしまえ ば、このツールは非常に簡単に使うことができます。検査したいパッケージのディレク トリーに移動し、pkglintを実行するだけです。 $ pkglint looks fine. 指定されたコマンド行の引数(pkglint(1)を見てください)によっては、より多くのチェ ックがおこなわれます。例えば pkglint -Call -Wall は、非常に徹底したチェックをお こないます。 A.2. 構築、インストール、パッケージングの手順 パッケージのためのディレクトリーと、いくつかの追加のディレクトリーを作成します 。 # cd /usr/pkgsrc/lang # mkdir bison # cd bison # mkdir patches Makefile、DESCRおよびPLISTを作り (Chapter 11, パッケージコンポーネント - ファイ ル、ディレクトリー、およびコンテンツ参照)、distfile を取得します。 # make fetch >> bison-1.25.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://prep.ai.mit.edu/pub/gnu//. Requesting ftp://prep.ai.mit.edu/pub/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/) ftp: Error retrieving file: 500 Internal error >> Attempting to fetch from ftp://wuarchive.wustl.edu/systems/gnu//. Requesting ftp://wuarchive.wustl.edu/systems/gnu//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/) ftp: Error retrieving file: 500 Internal error >> Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//. Requesting ftp://ftp.freebsd.org/pub/FreeBSD/distfiles//bison-1.25.tar.gz (via ftp://orpheus.amdahl.com:80/) Successfully retrieved file. distfileのチェックサムを distinfoへ作成します。 # make makedistinfo コンパイルします。 # make >> Checksum OK for bison-1.25.tar.gz. ===> Extracting for bison-1.25 ===> Patching for bison-1.25 ===> Ignoring empty patch directory ===> Configuring for bison-1.25 creating cache ./config.cache checking for gcc... cc checking whether we are using GNU C... yes checking for a BSD compatible install... /usr/bin/install -c -o bin -g bin checking how to run the C preprocessor... cc -E checking for minix/config.h... no checking for POSIXized ISC... no checking whether cross-compiling... no checking for ANSI C header files... yes checking for string.h... yes checking for stdlib.h... yes checking for memory.h... yes checking for working const... yes checking for working alloca.h... no checking for alloca... yes checking for strerror... yes updating cache ./config.cache creating ./config.status creating Makefile ===> Building for bison-1.25 cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g LR0.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g allocate.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g closure.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g conflicts.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g derives.c cc -c -DXPFILE=\"/usr/pkg/share/bison.simple\" -DXPFILE1=\"/usr/pkg/share/bison.hairy\" -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -g ./files.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getargs.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g gram.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g lalr.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g lex.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g main.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g nullable.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g output.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g print.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g reader.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g reduce.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g symtab.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g warshall.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g version.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getopt.c cc -c -DSTDC_HEADERS=1 -DHAVE_STRING_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MEMORY_H=1 -DHAVE_ALLOCA=1 -DHAVE_STRERROR=1 -I./../include -g getopt1.c cc -g -o bison LR0.o allocate.o closure.o conflicts.o derives.o files.o getargs.o gram.o lalr.o lex.o main.o nullable.o output.o print.o reader.o reduce.o symtab.o warshall.o version.o getopt.o getopt1.o ./files.c:240: warning: mktemp() possibly used unsafely, consider using mkstemp() rm -f bison.s1 sed -e "/^#line/ s|bison|/usr/pkg/share/bison|" < ./bison.simple > bison.s1 すべてOKのようなので、ファイルをインストールします。 # make install >> Checksum OK for bison-1.25.tar.gz. ===> Installing for bison-1.25 sh ./mkinstalldirs /usr/pkg/bin /usr/pkg/share /usr/pkg/info /usr/pkg/man/man1 rm -f /usr/pkg/bin/bison cd /usr/pkg/share; rm -f bison.simple bison.hairy rm -f /usr/pkg/man/man1/bison.1 /usr/pkg/info/bison.info* install -c -o bin -g bin -m 555 bison /usr/pkg/bin/bison /usr/bin/install -c -o bin -g bin -m 644 bison.s1 /usr/pkg/share/bison.simple /usr/bin/install -c -o bin -g bin -m 644 ./bison.hairy /usr/pkg/share/bison.hairy cd .; for f in bison.info*; do /usr/bin/install -c -o bin -g bin -m 644 $f /usr/pkg/info/$f; done /usr/bin/install -c -o bin -g bin -m 644 ./bison.1 /usr/pkg/man/man1/bison.1 ===> Registering installation for bison-1.25 これでbisonを使用することができます。そして、pkg_delete bisonを実行することで bisonを削除することもできます。もし、バイナリーパッケージが欲しければ、以下のよ うにしてください。 # make package >> Checksum OK for bison-1.25.tar.gz. ===> Building package for bison-1.25 Creating package bison-1.25.tgz Registering depends:. Creating gzip'd tar ball in '/u/pkgsrc/lang/bison/bison-1.25.tgz' もし、ソースやオブジェクトファイルが必要ないのであれば、掃除してください。 # make clean ===> Cleaning for bison-1.25 Appendix B. 構築のログ Table of Contents B.1. figletの構築 B.2. figlet のパッケージング B.1. figletの構築 # make ===> Checking for vulnerabilities in figlet-2.2.1nb2 => figlet221.tar.gz doesn't seem to exist on this system. => Attempting to fetch figlet221.tar.gz from ftp://ftp.figlet.org/pub/figlet/program/unix/. => [172219 bytes] Connected to ftp.plig.net. 220 ftp.plig.org NcFTPd Server (licensed copy) ready. 331 Guest login ok, send your complete e-mail address as password. 230-You are user #5 of 500 simultaneous users allowed. 230- 230- ___ _ _ _ 230- | _| |_ ___ ___| |_|___ ___ ___ ___ 230- | _| _| . |_| . | | | . |_| . | _| . | 230- |_| |_| | _|_| _|_|_|_ |_|___|_| |_ | 230- |_| |_| |___| |___| 230- 230-** Welcome to ftp.plig.org ** 230- 230-Please note that all transfers from this FTP site are logged. If you 230-do not like this, please disconnect now. 230- 230-This archive is available via 230- 230-HTTP: http://ftp.plig.org/ 230-FTP: ftp://ftp.plig.org/ (max 500 connections) 230-RSYNC: rsync://ftp.plig.org/ (max 30 connections) 230- 230-Please email comments, bug reports and requests for packages to be 230-mirrored to ftp-admin@plig.org. 230- 230- 230 Logged in anonymously. Remote system type is UNIX. Using binary mode to transfer files. 200 Type okay. 250 "/pub" is new cwd. 250-"/pub/figlet" is new cwd. 250- 250-Welcome to the figlet archive at ftp.figlet.org 250- 250- ftp://ftp.figlet.org/pub/figlet/ 250- 250-The official FIGlet web page is: 250- http://www.figlet.org/ 250- 250-If you have questions, please mailto:info@figlet.org. If you want to 250-contribute a font or something else, you can email us. 250 250 "/pub/figlet/program" is new cwd. 250 "/pub/figlet/program/unix" is new cwd. local: figlet221.tar.gz remote: figlet221.tar.gz 502 Unimplemented command. 227 Entering Passive Mode (195,40,6,41,246,104) 150 Data connection accepted from 84.128.86.72:65131; transfer starting for figlet221.tar.gz (172219 bytes). 38% |************** | 65800 64.16 KB/s 00:01 ETA 226 Transfer completed. 172219 bytes received in 00:02 (75.99 KB/s) 221 Goodbye. => Checksum OK for figlet221.tar.gz. ===> Extracting for figlet-2.2.1nb2 ===> Required installed package ccache-[0-9]*: ccache-2.3nb1 found ===> Patching for figlet-2.2.1nb2 ===> Applying pkgsrc patches for figlet-2.2.1nb2 ===> Overriding tools for figlet-2.2.1nb2 ===> Creating toolchain wrappers for figlet-2.2.1nb2 ===> Configuring for figlet-2.2.1nb2 ===> Building for figlet-2.2.1nb2 gcc -O2 -DDEFAULTFONTDIR=\"/usr/pkg/share/figlet\" -DDEFAULTFONTFILE=\"standard.flf\" figlet.c zipio.c crc.c inflate.c -o figlet chmod a+x figlet gcc -O2 -o chkfont chkfont.c => Unwrapping files-to-be-installed. # # make install ===> Checking for vulnerabilities in figlet-2.2.1nb2 ===> Installing for figlet-2.2.1nb2 install -d -o root -g wheel -m 755 /usr/pkg/bin install -d -o root -g wheel -m 755 /usr/pkg/man/man6 mkdir -p /usr/pkg/share/figlet cp figlet /usr/pkg/bin cp chkfont /usr/pkg/bin chmod 555 figlist showfigfonts cp figlist /usr/pkg/bin cp showfigfonts /usr/pkg/bin cp fonts/*.flf /usr/pkg/share/figlet cp fonts/*.flc /usr/pkg/share/figlet cp figlet.6 /usr/pkg/man/man6 ===> Registering installation for figlet-2.2.1nb2 # B.2. figlet のパッケージング # make package ===> Checking for vulnerabilities in figlet-2.2.1nb2 ===> Packaging figlet-2.2.1nb2 ===> Building binary package for figlet-2.2.1nb2 Creating package /home/cvs/pkgsrc/packages/i386/All/figlet-2.2.1nb2.tgz Using SrcDir value of /usr/pkg Registering depends:. # Appendix C. pkgsrc FTP サーバーのディレクトリー配置 Table of Contents C.1. distfiles: ソースファイルの配布物 C.2. misc: 種々雑多なもの C.3. packages: バイナリーパッケージ C.4. reports: バルクビルドの結果報告 C.5. current, pkgsrc-20xxQy: ソースパッケージ 他の大規模プロジェクトと同様に、初心者の方にとって pkgsrc のディレクトリー配置 は非常に複雑なものです。 ftp.NetBSD.org での基点ディレクトリーは /pub/pkgsrc/ です。他のサーバーでは、基点ディレクトリーの場所は異なるかもしれませんが、基点 ディレクトリー以下の内容はどのサーバーでもすべて同じはずです。このディレクトリ ーには、以下で説明するような、いくつかのサブディレクトリーがあります。 C.1. distfiles: ソースファイルの配布物 distfiles ディレクトリーは、 pkgsrc の各パッケージのアーカイブファイルのうち、 このサーバーにミラーされているものを多数含んでいます。配布ファイルのファイル名 にバージョン番号が明示的に含まれていなかったり、一般的すぎる名前 (たとえば release.tar.gz) だったりする場合には、パッケージ名を冠したサブディレクトリーが 使われます。 C.2. misc: 種々雑多なもの このディレクトリーは、個々の pkgsrc 開発者がサーバーに置いておく価値があると判 断したものを含んでいます。 C.3. packages: バイナリーパッケージ このディレクトリーは、 pkgsrc が対応している各種プラットフォーム用のバイナリー パッケージを含んでいます。各プラットフォーム用のサブディレクトリーは OPSYS/ARCH /OSVERSION_TAG のような形式になっています。これらの意味は以下のとおりです。 * OPSYS は、当該パッケージが構築された対象のオペレーティングシステム名です。 この名前は uname コマンドの出力に合わせているので、ふだん聞き慣れた名前とは 違う名前になっていることがあります。 * ARCH は、当該パッケージが構築された対象のプラットフォームのハードウェアアー キテクチャー名です。 ABI (Application Binary Interface) が複数あるプラット フォームでは、 ABI も含めた名称になっています。 * OSVERSION は、オペレーティングシステムのバージョンです。バージョン番号が頻 繁に変わる場合 (たとえば NetBSD-current) は、たとえば 4.99.x のように、頻繁 に変わる部分を x に置き換えています。 * TAG は、安定版の枝の場合は 20xxQy、 HEAD の場合は head です。後者は、パッケ ージが定期的に更新されるものである場合にのみ使います。そうでない場合は、た とえば head_20071015 のように、 pkgsrc のチェックアウト日を付け加えた形にし ます。 このような方式となっている理由は、pkgsrc の利用者がバイナリーパッケージを探すと きに、サーバー上のディレクトリーを辿って、自分のマシンに最適なバイナリーパッケ ージを簡単に見つけられるからです。利用者はたいてい、オペレーティングシステムと ハードウェアアーキテクチャーを知っているので、 OPSYS と ARCH を最初にしています 。これらを選べば、 OSVERSION と TAG の最適な組合せを選ぶことができます。通常の 場合、オペレーティングシステムのバージョンが違っても、パッケージには互換性があ るからです。 これらの各ディレクトリーには、当該プラットフォーム用のバイナリーパッケージ全体 が置かれています。 All というディレクトリーがあり、ここにすべてのバイナリーパッ ケージを含んでいます。このほか、カテゴリー別のディレクトリーがあり、バイナリー パッケージの実体へのシンボリックリンクを含んでいます。 C.4. reports: バルクビルドの結果報告 ここには、構築できないプラットフォームがあるパッケージを修正したい方向けに、バ ルクビルドの結果の報告が置いてあります。サブディレクトリーの構造はSection C.3, “packages: バイナリーパッケージ”と同じです。 C.5. current, pkgsrc-20xxQy: ソースパッケージ このディレクトリーは pkgsrc “そのもの”、つまり、ソースアーカイブからバイナリ ーパッケージを作る方法を定義したファイル一式を含んでいます。 pkgsrc ディレクトリーは、 CVS リポジトリーのスナップショットを含んでおり、定期 的に更新されます。 pkgsrc.tar.gz ファイルは、このディレクトリーと同じ内容を含ん でおり、全体をダウンロードできるようになっています。 四半期ごとの枝用のディレクトリーには、さらに pkgsrc-20xxQy.tar.gz というファイ ルがあります。これは、枝が分岐した時点の状態の pkgsrc を含んでいます。 Appendix D. the pkgsrc guide 編集の指針 Table of Contents D.1. make ターゲット D.2. 編集手順 本節では、この the pkgsrc guide そのものの編集に関する情報を掲載します。 D.1. make ターゲット the pkgsrc guide のソースコードは pkgsrc/doc/guide/files 以下に置かれており、こ れをもとに、以下のような数々のファイルが生成されます。 * pkgsrc/doc/pkgsrc.txt * pkgsrc/doc/pkgsrc.html * http://www.NetBSD.org/docs/pkgsrc/ * http://www.NetBSD.org/docs/pkgsrc/pkgsrc.pdf: the pkgsrc guide の PDF 版。 * http://www.NetBSD.org/docs/pkgsrc/pkgsrc.ps: the pkgsrc guide の PostScript 版。 D.2. 編集手順 the pkgsrc guide の編集手順は、以下のとおりです。 1. the pkgsrc guide (と、XML にもとづくその他の NetBSD ドキュメンテーション) の再生成に必要なパッケージがインストールされていることを確認します。 ASCII および HTML 版の生成に必要なのは meta-pkgs/netbsd-doc、 PostScript および PDF 版の生成に必要なのは meta-pkgs/netbsd-doc-print です。各形式のドキュメ ンテーションの一貫性を保つために、いずれのパッケージもインストールする必要 があります。 2. cd doc/guide を実行して、適切なディレクトリーに移動します。これ以降の手順は 、すべてこの場所でおこないます。 3. files/ 以下にある XML ファイルを編集します。 4. bmake を実行して、the pkgsrc guide が妥当な XML であることを確認し、最終的 な出力ファイルを構築します。何かエラーが出た場合は、元のファイルを編集する だけで結構です。作業ディレクトリーには、files/ 以下のファイルを指すシンボリ ックリンクがあるだけだからです。 5. (cd files && cvs commit) 6. bmake clean && bmake を実行して、適切な RCS Id を含んだ出力ファイルを作り直 します。 7. bmake regen を実行して、 pkgsrc/doc および htdocs 以下にそれぞれファイルを インストールして commit します。 Note 章の追加、削除、または改名をした場合は、 htdocs ディレクトリー以下で cvs add や cvs delete を使って、元のファイルとの対応を揃える必要があります。