diff --git a/ja/handbook/cutting-edge/chapter.sgml b/ja/handbook/cutting-edge/chapter.sgml index 690d88d88b..4955acad22 100644 --- a/ja/handbook/cutting-edge/chapter.sgml +++ b/ja/handbook/cutting-edge/chapter.sgml @@ -1,2528 +1,2569 @@ 開発の最前線: FreeBSD-current と FreeBSD-stable あるリリースから次のリリースまでの期間にも, FreeBSD の開発は 休みなく続けられています. この開発の最前線に興味を持っている人のために, 手元のシステムを最新の開発ツリーに同期させておくための, とても使いやすい仕掛けが何種類も用意されています. 注意: 開発の最前線は, 誰でもが扱えるという性質のものではありません! もしもあなたが, 開発途中のシステムを追いかけようか, それともリリース バージョンのどれかを使い続けようかと迷っているのなら, きっとこの章が参考になるでしょう. 最新のFreeBSDを追いかける 原作: &a.jkh;. 訳: &a.hanai; 6 November 1996. FreeBSD-current ってなに? FreeBSD-current とは，文字通りに，日々変更されている FreeBSD のソース のスナップショット以外の何ものでもありません． 中には現在開発途上の ソフトウェア, 実験的な変更, あるいは過渡的な機能などが含まれています. また, この中に入っている機能がすべて次の公式リリースに 入るとはかぎりません. FreeBSD-current をソースからほとんど毎日コンパイルしている人はたくさん いますが, 時期によっては FreeBSD-current はコンパイルさえできない状態に なっていることもあります. これらの問題は一般的には可能な限り素早く解決 されますが, FreeBSD-current のソースが不幸をもたらすか, それとも非常に 素晴らしい機能をもたらすかというのは文字通り, ある与えられた24時間の間 のどの部分であなたがソースを手に入れたか, による場合もあります. 誰が FreeBSD-current を必要としてるの? FreeBSD-current は, 主に次の三つの重要なグループを対象としています. ソースツリーのある部分に関して活発に作業している FreeBSD グループのメンバー. 彼らにとっては “最新のもの” にしておくのが 絶対に必要なことなのです． 活発にテストをする FreeBSD グループのメンバー. 彼らは, FreeBSD-current を “健全である” ことを出来るだけ確認するために種々の問題と戦うのに 時間を費やすのを厭わない人々です. 彼らはまた, 様々な変更に関する提案や FreeBSD の大まかな方向付けを行ないたいと思っている 人々でもあります. 単に, 様々な事に目を向け, 参考のために (例えば，動かすためではなく 読むため に) 最新のソースを使いたいと思って いる FreeBSD (または他の) グループのまわりにいるメンバー. これらの人々はまた, 時々コメントやコードを寄稿してくれます. FreeBSD-current に期待しては<emphasis>いけない</emphasis>ことは? なにか新しくカッコイイモノがあると聞き, 自分の周囲では 一番にそれを持ちたいがためにリリース前のコードの断片を 追いかけること. バグを修正するための素早い方法. 我々によって “公式にサポートされている” こと. 私たちは 3 つの “公式な” FreeBSD-current のグループの一つに実際に属する 人々を助けるのにベストを尽くしますが, 技術的なサポートを行なうには 単に「時間が足りない」のです. これは我々が外の人を助けるの好まない, ケチで意地悪い人間だと いうことではなく (もしそうなら FreeBSD なんかやっていません), 文字通り 我々は一日に 400 ものメッセージに答え かつ FreeBSD の作業をする ことなど出来ない! ということなのです. もし, たくさんの質問に答えるか, それとも FreeBSD を良くする作業を続けるかという選択が与えられた場合, あなた方のほとんどは後者を支持する, と私は確信しています. FreeBSD-current を使う &a.current;と&a.cvsall;に加わって下さい. これは単に良い考えであるというだけでなく, 必須のことなのです. もし FreeBSD-current メーリングリストに入っていなければ, 様々な人がシステムの現在の状態について 述べているコメントを決して見ることは ありませんし, 従って他の人が既に見つけて解決している多くの問題に 戸惑っ てあきらめてしまうでしょう. さらに言うと, システムを正常に保つための 重要な情報を見逃してしまう可能性もあります. cvs-all メーリングリストでは, それぞれの変更についての commit ログを見ることができますし, それに関して起こり得る副作用の情報を得ることができ, もう一つの加わるに値するメーリングリストです. これらのメーリングリストに入るには, &a.majordomo; へ subscribe freebsd-current subscribe cvs-all と書いたメールを送って下さい. オプションとして本文に help と書けば, Majordomo はあなたへ我々がサポ ートする様々なメーリングリストに参加 / 脱退する方法に関する詳しい ヘルプを送ります. ftp.FreeBSD.ORG からのソースの入手. 以下の3つの方法で行なうこと が出来ます. 下に述べられているCTMを用いる. 均一なレートの, 良質の TCP/IP 接続を持っていない人には, これが一番いい方法でしょう. cvsup を この supfile を用いて使用する. これは 2 番目に推薦される方法です. なぜなら, cvsup によって一度全体 を入手し, 後は変更されたところだけを入手することが 出来るからです. たくさんの人が自動的にソースを最新のもに保つために cvsup を cron から起動しています. これを行なうための非常に簡単な 方法は, 単に - &prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz +
&prompt.root; pkg_add -f \ +ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
とタイプすることです. ftp を使う. FreeBSD-current のソースツリーは常に ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current に “公開” されています. 我々はまた全体を compress/tar して入手できる wu-ftpd を使ってい ます. 例えば, usr.bin/lex があったとすると, ftp> cd usr.bin ftp> get lex.tar.Z とすることにより, ディレクトリ全体(この場合, usr.bin/lex以下全体) を compress された tar ファイルとして入手することができます. 以上のことをまとめると, 必要に応じて迅速なアクセスをする必要があり, 接続のバンド幅が問題ではなければ cvsup か ftp を使いましょう. そうではなければ CTM を使いましょう. もしソースを, 眺めるだけでなく走らせるために入手しているので あれば, 一部だけ選ぶのではなく, current の全体を手に入れてください. なぜなら, ソースの様々な部分が他の部分の更新に依存しており, 一部のみを コンパイルしようとすると, ほぼ間違いなくトラブルを起こすからです. current をコンパイルする前に /usr/src にある Makefile をよく読んでください. アップグレードの処理の一部として, 少なくとも一回は最初に make world を行なうべきでしょう. &a.current; を読めば, 次のリリースへ向けて, 時々必要になる 他のブートストラップの方法に関して 常に最新情報を得ることが出来ます. アクティブになって下さい! もし FreeBSD-current を走らせているなら 我々はそれに関するコメント, 特に拡張やバグ潰しに関する提案, を欲して います. コードを伴う提案はもっとも歓迎されるものです! FreeBSD の安定状態の持続 原作: &a.jkh;. 訳: &a.jp.iwasaki;. FreeBSD-stable ってなに? FreeBSD-stable は, 次の本流のリリースを目指した新機能をあまり採り入 れない保守的な変更のための開発の支流です. 実験的またはテスト未完の変更 はこの支流には取り入れられません (最新の FreeBSD を追いかける 参照). 誰が FreeBSD-stable を必要としているの? もしあなたが仕事で使用しているとか, なによりも FreeBSD システムの安 定性を最重要視するなら, stable を追いかけることを考えるべきで しょう. stable の支流は前のリリースに関して効果的にバグフィッ クスされた流れであるため, 最新のリリース ( &rel.current;-RELEASE 執筆時点) をインストールしているのであれば, 特に そうです. stable ツリーが常に完全に互換性があり安定するように努力し ていますが, たまに間違いがあることに注意してください (結局, 内容が吟味 されずに素早く送られた変更を含むソースがまだあるのです). また, current を stable へ移行する前に完璧なテストフィック スに最善を尽くしますが, 私たちのテストはすべてのケースを十分に網羅して いるとは限りません. もし何か stable で不具合があるようでした ら, 私たちにすぐに教えてください (次の節参照). FreeBSD-stable を使う &a.stable; へ加わってください. このメーリングリスト では, stable の構築に関連する事柄や, その他の注意すべき点 に関する情報が流れています. また開発者は議論の余地がある修正や変更 を考えている場合に, このメーリングリストで公表し, 提案された変更に 関して問題が生じるかどうかを返答する機会を ユーザに与えます. また, cvs-all メーリングリストでは, それぞれの変更がなされると 起こりうる副作用に関するすべての適切な情報と一緒に commit log を 読むことができます. subscribe しておきたいもう一つのメーリングリストです. メーリングリストに参加するには, &a.majordomo へメッセージの本文に 次のように書いたメールを送ってください: subscribe freebsd-stable subscribe cvs-all オプションとして本文に `help' と書けば, Majordomo は私たちがサポー トする様々なメーリングリストに参加 / 脱退する方法に関する詳しいヘ ルプを送付します. もし, あなたが新しいシステムを可能な限り -stable に近いものにインストールしようとする場合には, 最新のブランチの snapshot を ftp://releng3.freebsd.org/pub/FreeBSD から取得し, これを一般のリリースのものと同様に インストールしてください. もし, 既に 2.2 系列の前のリリースが動いている場合で, これをソースからアップグレードしようとするならば, ftp.FreeBSD.ORG より簡単に これを行う事が出来ます. これには次の 3つの方法があります. CTM 機能を使用する. 転送レートが 安定している TCP/IP 接続でない場合は, この方法が適して います. cvsup を この supfile を用いて使用する. 一度コレクション全体を入手してしまえば, 前回からの変更部分だけですむので, 2 番目に推奨される方法です. 多くの人が cron から cvsup を実行し, 自動的にソースコー ドを最新の状態に保っています. これを簡単に扱うには次のようにタイプしてください. - &prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz +
&prompt.root; pkg_add -f \ +ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
 ftp を使用する. FreeBSD-stable 用のソースツリーは 常に次のところで“公開”されています : ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-stable 私たちはまた, tar/compress でツリー全体を入手できる wu-ftpd を使用しています. 例えば : usr.bin/lex に対して: ftp> cd usr.bin ftp> get lex.tar.Z とすることにより, ディレクトリ全体を compress された tar ファイルとして入手することができます. 基本的には, ソースに迅速でオンデマンドなアクセスが必要で, 接続のバンド幅が問題でなければ, cvsup か ftp を使いましょう. そうで ない場合は CTM を使いましょう. stable をコンパイルする前に, /usr/src にある Makefile をよ く読んでください. 少なくとも一回はアップグレードの処理の一部として 最初に make world を実行するべきでしょう. &a.stable; を読めば, 次のリリースに移行する に当たって時々必要となる既存システムからの 新システムの構築手順に ついての最新情報が得られるでしょう. インターネットを通じたソースツリーの同期 原作: &a.jkh;. 訳: &a.jp.iwasaki;. 13 September 1997. インターネット接続 (または電子メール) を使用して, あなたの興味の対 象によって FreeBSD プロジェクトのソースのある一部分または全体の最新を 追いかける方法は色々あります. 私たちが提供している基本的なサービスは Anonymous CVS, CVSup と CTM です: Anonymous CVS と CVSup は pull 同期モデルを採用しています. CVSup の場合, ユーザ (または cron スクリプト) が cvsup 起動し, どこかにある cvsupd サーバとやりとりしてファイルを 最新状態にします. 届けられる更新情報はその時点の最新のものであり, また必要な時にだけ取り寄せられます. 興味のある特定のファイルやディレクトリに 限定して更新することも簡単にできます. クライアント側のソースツリーの状態・ 設定ファイルの指定に従い, サーバによって更新情報が 素早く生成されます. Anonymous CVS は, このプログラムがリモートの CVS リポジトリから直接変更点を pull できるようにした &man.cvs.1; への拡張であるという点で, CVSup よりもずっと単純です. CVSup は効率の点ではるかにまさっていますが, Anonymous CVS の方が簡単に利用できます. 一方, CTM はあなたが持っているソースとマスタアーカイブ上に あるそれとの対話的な比較をおこないませんし, あるいは向こう側から変更点を pull したりもしません. そのかわりに, 前回の実行時からの変更を認識するスクリプトが マスタ CTM マシン上で一日に数回実行され, すべての変更を compress して通し番号を振り, さらに電子メールで転送できるようにエンコードします (印字可能な ASCII キャラクタのみです). 受信した後は, これらの “CTM のデルタ” は自動 的にデコード, 検査してユーザのソースのコピーに変更を適用する &man.ctm.rmail.1; によって処理可能となります. この処理は CVSup や Anonymous CVS よりずっと効率 的であり, pull モデルというよりむしろ push モデルで あるため, 私たちのサーバ資源の負荷は軽くなります. もちろん他のトレードオフもあります. うっかりアーカイブ の一部を消してしまっても, CVSup は壊れた部分を検出して再構築してくれます. CTM はこれをやってくれませんし, Anonymous CVS はおそらく他の何よりも深く混乱してしまうことが多いでしょう. もしソースツリーの一部を消してしまったら, (最新の CVS “ベースデルタ”から) 一からやり直し, CTM か anoncvs を使って悪い部分を消去し, 再同期させることによって すべてを再構築しなければなりません. Anonymous CVS, CTM, CVSup についての 詳しい情報については, 以下の節を参照してください: Anonymous CVS 原作: &a.jkh; 訳: &a.jp.sugimura;. 19 July 1998. <anchor id="anoncvs-intro">導入 Anonymous CVS (もしくは, anoncvs として知られています) は離れたところにある CVS リポジトリと同期を取るために FreeBSD に付属している CVS ユーティリティに含まれている機能です. 他にもありますが, それは FreeBSD のユーザが, 特別な権限なしに FreeBSD プロジェクトの公式な anoncvs サーバに読み取り専用で CVS の操作をすることができるようにするためのものです. それを使うには, 単に CVSROOT 環境変数を設定して適切な anoncvs サーバを指定し, そして &man.cvs.1; コマンドを使って手元にある リポジトリのようにアクセスするだけです. CVSup と anoncvs のサービスは本質的に同じ機能ではないか ということも言われていますが, ユーザが同期を取る方法を選ぶときに影響を与えるような さまざまなトレードオフが存在します. 要約して言えば, CVSup はネットワーク資源の使い方においては非常に効率がよく, またはるかに技術的に洗練されたものですが, 相当な手間がかかります. CVSup を使うには, 特別なクライアントをまずインストールして設定しなくては 1bit も取ってくることができず, またそのとき CVSup では collections と呼んでいるかなり大きなかたまりだけからしか 取ってこれません. それに対して anoncvs では, CVS モジュールの名前を指定することで特定のプログラムの (ls や grep のような) 個々のファイルから調べることができます. もちろん, anoncvs は CVS リポジトリの読み取り専用の操作に対してのみ適しているので, もしあなたが FreeBSD プロジェクトのものと共有されたなにか ローカルなリポジトリを作ってそこでの開発を 行おうというときには, CVSup だけが唯一の手段となってしまいます. <anchor id="anoncvs-usage">Anonymous CVS を使う &man.cvs.1; を設定して Anonymous CVS リポジトリを使うには単に CVSROOT 環境変数を設定して FreeBSD プロジェクトの anoncvs サーバを指定するだけのことです. この文書を書いているときには, 次のサーバが利用できるようになっています. USA: anoncvs@anoncvs.freebsd.org:/cvs CVS はかつて存在した (もしくは, 時にはこれから存在するものも :) ほとんどどんなバージョンの FreeBSD のソースを “check out” することができますが, あなたは &man.cvs.1; の リビジョン () のオプションや FreeBSD プロジェクトのリポジトリの中で それをどのように指定したらいいものかということを よく知っておく必要があります. タグには 2 種類あって, リビジョンタグとブランチタグがあります. リビジョンタグは特定の改訂版を指しており, それはいつも同じものを意味しています. 一方ブランチタグは, 指定されたときの指定された開発の流れにおける 最も新しい改訂版を示しています. ブランチタグは特定の改訂版を指していないために, その意味はきょうと明日では違うものになっているでしょう. ユーザが興味を持つであろうブランチタグの一覧です. HEAD 主要部をなす流れ, すなわち FreeBSD-current のための名前です. また, どのリビジョンも 指定されなかったときにはこれになります. RELENG_3 FreeBSD-3.x の開発のための流れです. FreeBSD-stable としても知られています. ports コレクションには無効です. RELENG_2_2 FreeBSD-2.2.x の開発のための流れです. 2.2-stable - としても知られています. ports + としても知られています. このブランチは大部分が + すたれています. ports コレクションにはふさわしくありません. RELENG_2_1_0 FreeBSD-2.1.x の開発のための流れです - このブランチは大部分がすたれています. ports コレクションにはふさわしくありません. ユーザが興味を持つであろうリビジョンタグの一覧です. + + RELENG_3_1_0_RELEASE + + FreeBSD-3.1. ports + コレクションにはふさわしくありません. + + + + + RELENG_3_0_0_RELEASE + + FreeBSD-3.0. ports + コレクションにはふさわしくありません. + + + + + RELENG_2_2_8_RELEASE + + FreeBSD-2.2.8. ports + コレクションにはふさわしくありません. + + + + + RELENG_2_2_7_RELEASE + + FreeBSD-2.2.7. ports + コレクションにはふさわしくありません. + + + RELENG_2_2_6_RELEASE FreeBSD-2.2.6. ports コレクションにはふさわしくありません. RELENG_2_2_5_RELEASE FreeBSD-2.2.5. ports コレクションにはふさわしくありません. RELENG_2_2_2_RELEASE FreeBSD-2.2.2. ports コレクションにはふさわしくありません. RELENG_2_2_1_RELEASE FreeBSD-2.2.1. ports コレクションにはふさわしくありません. RELENG_2_2_0_RELEASE FreeBSD-2.2.0. ports コレクションにはふさわしくありません. RELENG_2_1_7_RELEASE FreeBSD-2.1.7. ports コレクションにはふさわしくありません. RELENG_2_1_6_1_RELEASE FreeBSD-2.1.6.1. ports コレクションにはふさわしくありません. RELENG_2_1_6_RELEASE FreeBSD-2.1.6. ports コレクションにはふさわしくありません. RELENG_2_1_5_RELEASE FreeBSD-2.1.5. ports コレクションにはふさわしくありません. RELENG_2_1_0_RELEASE FreeBSD-2.1.0. ports コレクションにはふさわしくありません. ブランチタグを指定したときには, 普通はその開発の流れにおける 最も新しいバージョンのファイルを受け取ることができます. もし以前のバージョンのものが欲しいときには, 日付を オプションを使って指定すればよいです. 例 本当はなにかする前には &man.cvs.1; のマニュアルページの全体を ちゃんと読んでからのほうがいいのですが, Anonymous CVS の使い方の本質的なところを簡単に例を挙げて説明します. -current (ls(1)) をちょっと確認してから消してみます. &prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs &prompt.user; cvs co ls &prompt.user; cvs release -d ls ls(1) のバージョンを 2.2-stable ブランチから調べてみます. &prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs &prompt.user; cvs co -rRELENG_2_2 ls &prompt.user; cvs release -d ls - FreeBSD 2.2.2 と FreeBSD 2.2.6 とで ls(1) - の変更点のリストを (unidiff で) 作ってみます. + ls(1) の変更点のリストを (unidiff で) 作ってみます. &prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs &prompt.user; cvs rdiff -u -rRELENG_2_2_2_RELEASE -rRELENG_2_2_6_RELEASE ls 他のどんなモジュールの名前が 使われているか検索してみます. &prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs &prompt.user; cvs co modules &prompt.user; more modules/modules &prompt.user; cvs release -d modules 他の資料 次の資料は CVS を学ぶのに役に立つでしょう. CVS チュートリアル. Cal Poly によります. Cyclic Software, 商用として CVS を維持しています. CVSWeb は FreeBSD Project の CVS のための web インターフェースです. <application>CTM</application> 原作: &a.phk;. 更新: 19-October-1997. 訳: &a.hanai; 13 September 1997. CTM はリモートのディレクトリツリーを中央のツリーに同期させるための 手段です. これはFreeBSDのソースツリーの配布を行なうために開発されまし たが, 時が経つにつれて別の目的にも有用であることがわかるかも しれません. デルタを作り出す処理に関するドキュメントは現在ほとんど ありません. 従って, もしあなたがCTM を他のことに使いたいなら &a.phk;にさらなる情報を問い合わせてください. なぜ<application>CTM</application>を使うの? CTM を使うことにより FreeBSD ソースツリーのローカルコピー を手にいれることができます. ソースツリーが使えることの魅力は数多くあります. 完全な cvs ツリーを追いかけるにしても, ひとつのブランチを追いかける にしても CTM は必要な情報を与えてくれます. もしあなたがFreeBSDのアクティブな開発者であるにもかかわらず お粗末なTCP/IP接続しか持っていなかったり, またはTCP/IP接続が 行なえないとしたら, あるいは単に変更が自動的に送られてきて ほしいというのであれば CTM はそんなあなたのために 作られたのです. アクティブなブランチでは 1 日に最大三つまでのデルタを受け取る必 要があります. これが自動的に e-mail で送られてくるという方法を ぜひ検討してみてください. デルタのサイズは常にできるだけ小さく保たれています. 大抵の場合5KBよりも小さく, たまに(10回に1回程度)10-50KBになり, ときおり100KBかもっと大きくなる でしょう. 開発ソースから直接に得られたものを使うことについては, あらかじめ パッケージにされたリリースとは違い, いろいろと注意することが あります. これは特に “current” のソースを選んでいるときは 重要です. 最新の FreeBSD を追いかけるを読むことを お勧めします. <application>CTM</application>を使うには何が必要? 二つのものが必要でしょう: CTM プログラムとそれに与える (“current” レベルを得るための)最初のデルタです. CTM プログラムはバージョン2.0のリリース以来FreeBSDの一部にな りました. もしソースのコピーを持っているなら /usr/src/usr.sbin/CTMにあります. もしFreeBSDの2.0以前のバージョンなら, 最新のCTMのソースを直接 ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm から入手できます. CTM に与える “デルタ” は二つの方法, FTPまたはe-mail, で得ること ができます. もしインターネットにFTPアクセスできるなら, 次のFTPサイト: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/CTM または, その ミラーサイト が CTM へのアクセスをサポートします. 適切なディレクトリに FTP して README ファイルを入手し, そこから スタートしてください. e-mail によってデルタを得たいという場合は: CTM 配布メーリングリストのいずれかに参加するために &a.majordomo; へ subscribe のメールを送ってください. “ctm-cvs-cur” は完全な cvs ツリー をサポートします. “ctm-src-cur” は開発先端ブランチをサポートします “ctm-src-2_2” は 2.2 リリースのブランチのサポートです. (もしmajordomoを使って参加する方法を知らない のであれば, 最初にhelp という語を含むメッセージを送ってください. — 使い方の説明が送られてくるでしょう.) メールで CTM による更新ファイルを受け取り始めると, 中身を取り出して使用 するために ctm_rmail プログラムを使うかもしれません. それを完全 に自動で行ないたいなら, /etc/aliases から ctm_rmailプロ グラムを直接使うこともできます. さらに詳しいことはctm_rmail manページを御覧ください. CTM デルタを得るためにどの方法を使うのであっても, ctm-announce@FreeBSD.ORG メーリングリストに参加するべきです. このメーリングリストは将来的には CTMシステムの操作に関する アナウンスがポストされる唯一の場になるでしょう. メーリングリストに加わるためにはsubscribe ctm-announce と書いた一行だけのメールを &a.majordomo; へ送ってください. はじめて<application>CTM</application>を使い始める CTM デルタを使い始めるためには, これは以降作られる全ての デルタの出発点を手にいれる必要があります. 最初にあなたが何をすでに持っているかをはっきりさせましょう. すべての人は “空”のディレクトリから始めなければなりません. ツリーをサポートしてるあなたの CTM を稼働するためには 指定した“空” のデルタを使う必要があります. いくつかの分岐点 では, あなたの都合により CD 内に分配されている“スタータ” デルタを使用できるようになっています. しかしながら, これは 頻繁に行われることではありません. 適切な出発点が決まれば, その出発点を CTM が 維持するツリーへ変換するための “スタータ” 初期デルタを使う必要が あります. 移行デルタは番号の後ろに X をつけたものがそうです (たとえばsrc-cur.3210XEmpty.gz). X の後ろは最初の開始ポイントに対応します. Empty は 空のディレクトリです. ルールとして Empty からの移行デルタは 100 デルタごとに 作られます. ところで, これらは非常に大きいです! XEmptyのデルタは 数十MBの gzip で圧縮されたデータというのが普通です. 一度スタートするためのベースデルタを得ると, それに続く多数の 全てのデルタも必要になるでしょう. <application>CTM</application>を日常で使う デルタを適用するためには, 単に &prompt.root; cd /where/ever/you/want/the/stuff &prompt.root; ctm -v -v /where/you/store/your/deltas/src-xxx.* とします. CTM はどれがgzipされているか理解します. 従って最初に gunzipしておく必要はありません. ディスクの節約にもなります. 全体の処理に関して確信するまでは CTM は(ソース)ツリーに対して 何もしません. また, デルタを確かめるためには フラグを使うことができます. このフラグがあると CTM はツリーに対して実際には何も行ないません. 単にデルタの完全性を確認し, 現在のツリーに問題なく使用できるかを確認 するだけです. CTM には他にもオプションがあります. 詳細に関しては マニュアルページを参照するかソースを見てください. もし誰かが “ユーザ インターフェース” の部分に関して助けてくれるなら 私はとても嬉しいです. なぜならどういうオプションが何を, どのよう に, いつ行なうようにするべきか決めかねているからです. 以上でやることは本当に全部です. 新しいデルタを入手した時には, ソースを最新のものにするためにそれを CTMに通すだけです. もしデルタを再ダウンロードするのが 骨の折れる作業であれば, デルタを 消さないでおいてください. なにかおかしなことが起こった場合には置いておけば良かった と思うかもしれません. もしフロッピーディスクしか持っていない状況 であってもコピーを取るのに fdwriteを使うことを考えてください. ローカルの変更を保存する 開発者としてはソースツリー中のファイルを 使って実験したり変更したく なるものです. CTM はローカルの変更を制限つきでサポートします: ファイル foo の存在をチェックする前に, foo.ctm を参照しにいきます. このファイルが存在する場合, CTM は foo の代りにこれを処理します. この動作はローカルの変更を保持する簡単な手段を 提供します: 単に変更したいファイルを拡張子 .ctm 付きのファイル名で コピーするだけです. あとは自由にコードをハックでき, .ctm ファイルの方は CTM が最新状態に保ってくれます. <application>CTM</application> のその他の面白いオプション 更新で変更されるファイルを正確に知る CTM のソースリポジトリに対する変更のリストを オプションを使って決定することができます. これは, 変更のログを保存したい, 変更されたファイルをなんらかの方法で 前・後処理したい, または単にこだわりたい :-) 場合には, 役に立つでしょう. 更新前にバックアップを取る CTM の更新によって変更されるファイルすべてのバックアップを 取りたくなることがあります. オプションを指定すると CTM は デルタで変更されるファイルすべてを backup-file としてバックアップするようになります. 更新で変更されるファイルを制限する CTM の更新の範囲を制限したり一連のデルタのから ほんの数ファイルを 抽出したくなることがあります. と オプションを用い正規表現を 指定することで, CTM が処理するファイルのリストを制御することが できます. 例えば, lib/libc/Makefile の最新のコピーを保存してある CTM デルタのコレクションから抽出するには, 以下のコマンドを実行します. &prompt.root; cd /where/ever/you/want/to/extract/it/ &prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* CTM デルタで指定されたファイルごとに, そして オプションがコマンドラインで指定された順序で 適用されます. すべての そして オプションが適用された後に更新対象と選択された場合に限り, CTM はそのファイルを処理します. <application>CTM</application>の将来計画 重要なもの なんらかの CTM システムへの認証機構を用い, 不正な CTM の更新の 検出を可能とする. CTM へのオプションを整理する. さもないと混乱し, 直観に反したもの になります. 残念なことに私は非常に忙しいです. 従ってこれを行なうどんな手助け でも歓迎します. その際, 自分が何をやりたいかを私に 言うのを忘れずに. その他 “DESに染まった” (例えば, 国外への持ち出しが規制された)ソースは まったく含まれません. 手に入るのは“国際”バージョンだけです. もし興味のある人が多いようであれば, 我々はsec-curシーケンスも セットアップするつもりです. ports コレクションに対するデルタのシーケンスもあります. しかし, まだあまり興味は持たれていないようです. もしこれに対するメーリング リストが欲しい時も私に言ってください. 我々はセットアップすることを 考えます. ありがとう! &a.bde; - 辛辣なペンと価値のないコメントに対して. + 鋭い記述とすばらしいコメントに対して. &a.sos; よく辛抱してくれました. Stephen McKay ctm_[rs]mailを書いてくれました. とても感謝して います. &a.jkh; 彼が頑固として譲らなかったため, 私もこの CTM をもっと良いものに しないわけにはいきませんでした. 彼の頑固さに感謝します. ユーザの人みんな 気に入ってくれることを願っています... <application>CVSup</application> 原作: &a.jdp;. 訳: &a.jp.iwasaki;. 27 February 1997. <application>CVSup</application> の紹介 CVSup は, リモートのサーバホストにあるマスタ CVS リポジトリから ソースツリーを配布し更新するための ソフトウェアパッケージです. FreeBSD のソースは, カリフォルニアにある中心的な開発マシンの CVS リポジトリの 中でメンテナンスしています. CVSup を使用することで, FreeBSD ユーザは 簡単に自分のソースツリーを最新の状態に しておくことができます. CVSup は pull モデルとよばれる更新のモデルを採用しています. pull モデルでは, 各クライアントが更新したい場合に更新したい時点で, サーバに更新の問い合わせをおこないます. サーバはクライアントからの 更新の要求を受け身の状態で待ちます. したがって, すべての更新は クライアント主導でおこなわれます. サーバは頼まれもしない更新情報を 送るようなことはしません. ユーザは CVSup クライアントを手動で実行して 更新をおこなうか, cron ジョブを設定して定期的に自動実行する必要があります. 用語 CVSup のように大文字で表記しているものは, ソフトウェアパッケージ 全体を指します. 主な構成物は, 各ユーザマシンで実行するクライアントである cvsup, FreeBSD の各ミラーサイトで実行するサーバ cvsupd です. FreeBSD の文書やメーリングリストを読んだ際に, sup についての言及を 見かけたかもしれません. sup は CVSup の前に存在していたもので, 同様の 目的で使われていました. CVSup は sup と同じように使用されており, 実際, sup と互換性のあるコンフィグレーションファイルを使用します. CVSup の方がより高速で柔軟性もあるので, もはや sup は FreeBSD プロジェクトでは使用されていません. <application>CVSup</application> のインストール FreeBSD 2.2 以降を使用している場合, CVSup をインストールするもっとも 簡単な方法は, FreeBSD ports コレクション の port または対応する バイナリ package を使うことです. どちらを使うかは, CVSupを自分で作りたいかどうかによります. FreeBSD-2.1.6 または 2.1.7 を使用している場合は, 残念ながら FreeBSD-2.1.{6,7} には存在しないバージョンの C ライブラリが必要となるため バイナリ package は使用できません. しかし, port は FreeBSD 2.2 とまったく同じように 簡単に使うことができます. 単に tar ファイルを展開し, cvsup ディレクトリへ cd して make install とタイプするだけです. CVSup は Modula-3 で書かれているため, package と port 両方とも Modula-3 ランタイムライブラリが インストールされていることが必要です. これらは port の lang/modula-3-lib および package の lang/modula-3-lib-3.6 にあります. これらのライブラリの port や package に対して cvsup と同じ管理方法を取っていれば, CVSup の port や package をインストールする際に, これらのライブラリも自動的に コンパイルそして/またはインストールされます. Modula-3 ライブラリはかなり大きく, これらの転送やコンパイルはすぐに 終わるものではありません. この理由から, 三つめの選択肢が提供されています. 以下のアメリカ合衆国にある配布サイトのどちらからでも, FreeBSD 用の スタティックリンクされた CVSup 実行形式が入手可能です: ftp://ftp.freebsd.org/pub/FreeBSD/development/CVSup/cvsup-bin-16.0.tar.gz (GUI 込みのクライアント). ftp://ftp.freebsd.org/pub/FreeBSD/development/CVSup/cvsup.nogui-bin-16.0.tar.gz (GUI なしのクライアント). ftp://ftp.freebsd.org/pub/FreeBSD/development/CVSup/cvsupd-bin-16.0.tar.gz (サーバ). また, 世界中にあるたくさんの FreeBSD FTP ミラーサイト からも入手可能です. : ほとんどのユーザはクライアントのみが必要になるでしょう. これらの 実行形式は完全に自己完結しており, FreeBSD-2.1.0 から FreeBSD-current までの, どのバージョンでも動作します. まとめると, CVSup をインストールするための選択肢は以下の通りです: FreeBSD-2.2以降: スタティックバイナリ, port, package FreeBSD-2.1.6, 2.1.7: スタティックバイナリ, port FreeBSD-2.1.5 以前: スタティックバイナリ <application>CVSup</application> のコンフィグレーション CVSup の動作は, supfile と呼ばれるコンフィグレーションファイルで 制御します. FreeBSD-2.2 からは, supfile のサンプルがディレクトリ /usr/share/examples/cvsup の下にあります. 2.2 以前のシステムを 使用している場合は, これらの サンプルを ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/ から入手することができます. supfile には以下の cvsup に関する質問への答えを記述します: どのファイルを受け取りたいのか? どのバージョンのものが欲しいのか? どこから入手したいのか? 自分のマシンのどこに置きたいのか? どこに status ファイルを置きたいのか? 次のセクションで, これらの質問に順番に答えながら典型的な supfile を組み立てていきます. 最初に supfile の全体構造を説明します. supfile はテキストファイルです. コメントは # から行末までです. 空行とコメントだけの行は無視します. 残りの各行には, ユーザが受け取りたいファイル群について記述します. 行の始めは, サーバ側で定義した論理的なファイルのグループである “コレクション”の名称です. コレクションの名称を指定して, 欲しいファイル群を サーバに伝えます. コレクション名の後には, ホワイトスペースで区切られた 0個以上のフィールドが続きます. これらのフィールドが上記の質問に対する 答えになります. フィールドには 2種類あります: flag フィールドと value フィールドです. flag フィールドは delete や compress のような 単独のキーワードから成ります. また, value フィールドもキーワードで 始まりますが, キーワードの後にはホワイトスペースは入らず, = と 二つめの単語が続きます. 例えば, release=cvs は value フィールドです. 通常, supfile には受け取りたいコレクションを一つ以上指定します. supfile を組み立てる一つの方法として, コレクション毎にすべての関係の あるフィールドを明示的に指定する方法があります. しかし, これでは supfile のすべてのコレクションに対して ほとんどのフィールドが同じになるため, 行が非常に長くなってしまい不便になります. これらの問題を避けるため, CVSup ではデフォルトを指定することのできる メカニズムが提供されています. 特殊な擬似コレクション名 *default で始まる行は, supfile 中の後続の コレクションに対して使用する flag フィールドと value フィールドの デフォルトを設定するために利用できます. 個々のコレクションで固有の値を 指定すると, デフォルト値を無効にできます. また 行を追加すると, supfile の途中からデフォルト値の変更や追加が可能になります. これまでの予備知識を基に, FreeBSD-current のメインのソースツリーを受け取って更新するための supfile を 組み立ててみましょう. どのファイルを受け取りたいのか? CVSup を通して入手できるファイルは “コレクション” と呼ばれる名前の付けられたグループにまとめられています. 利用可能なコレクションについては ここ で説明しています. ここでは, FreeBSD システムのメインのソースツリー全体 を受け取るための設定例を紹介します. 輸出規制されている暗号化サポートの コード以外のすべてを含む src-all という 単一の大きなコレクションがあります. この例では私たちがアメリカ合衆国か カナダにいるものと仮定します. その場合, cvs-crypto という一つの付化的な コレクションで暗号化コードを入手することができます. supfile を組み立てる最初のステップとして, これらのコレクションを一行に一つづつ 記述します: src-all cvs-crypto どのバージョンのものが欲しいのか? CVSup を使用すると, かつて存在していたことのある, 事実上どのバージョンの ソースでも受け取ることができます. これは cvsupd サーバがすべてのバージョンを含む CVS リポジトリに基づいて動作することにより, 実現されています. tag= および の value フィールドを使用して, 欲しいバージョンの 一つを指定します. tag= のフィールドの指定は正確に行うように十分注意 してください. いくつかのタグは特定のコレクションに 対してのみ有効です. タグの綴りが違っていたり不適切なタグを指定すると, CVSupはユーザが消し たくないファイルまで削除してしまいます. 特に ports-* のコレクション に対しては tag=. だけ を指定するようにしてください. tag= フィールドはリポジトリ中のシンボリックタグを指定します. tag には revision tag と branch tag の二種類があります. revision tag は特定のリビジョンを指します. これは, 毎日同じ状態に保つことになります. 一方 branch tag は, ある時点での開発分流の最新のリビジョンを指します. branch tag は特定のリビジョンを指定している訳ではないので, 今日と明日では 異なるリビジョンを参照することになるかもしれません. 以下はユーザが興味を持っていると思われる branch tag です: tag=. メインの開発分流であり, FreeBSD-current として知られています. 注意: . は句読点ではありません. tag の名称です. このタグの指定は総ての コレクションに対して有効です. tag=RELENG_3 FreeBSD-3.x 用の開発分流であり, FreeBSD-stable として知られています. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_2 FreeBSD-2.2.x 用の開発分流であり, 2.2-stable として知られています. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_1_0 FreeBSD-2.1.x 用の開発分流です. この分流はほとんど利用されていません. このタグの指定は ports-* のコレクションに対しては無効です. 以下はユーザが興味を持っていると思われる revision tag です: + tag=RELENG_3_1_0_RELEASE + + FreeBSD-3.1. このタグの指定は ports-* + のコレクションに対しては無効です. + + + tag=RELENG_3_0_0_RELEASE FreeBSD-3.0. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_2_8_RELEASE FreeBSD-2.2.8. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_2_7_RELEASE FreeBSD-2.2.7. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_2_6_RELEASE FreeBSD-2.2.6. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_2_5_RELEASE FreeBSD-2.2.5. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_2_2_RELEASE FreeBSD-2.2.2. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_2_1_RELEASE FreeBSD-2.2.1. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_2_0_RELEASE FreeBSD-2.2.0. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_1_7_RELEASE FreeBSD-2.1.7. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_1_6_1_RELEASE FreeBSD-2.1.6.1. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_1_6_RELEASE FreeBSD-2.1.6. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_1_5_RELEASE FreeBSD-2.1.5. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_1_0_RELEASE FreeBSD-2.1.0. このタグの指定は ports-* のコレクションに対しては無効です. tag 名を示した通りにタイプされているか十分注意してく ださい. CVSup は tag 名が正しいかどうかを見分けることはできません. tag が間違っていた場合, たまたまファイルがまったく存在しない正しい tag が 指定されたものとしてCVSup は動作します. その場合は, 現在あるソースが削 除されるでしょう. branch tag を指定した際には, 通常はその開発分流の最新バージョンの ファイルを受け取ります. いくらか前のバージョンを受け取りたい場合は, の value フィールドを使って日付を指定することで, これを実現することが できます. &man.cvsup.1; のマニュアルページで, その方法を説明しています. 例として, FreeBSD-current を受け取りたいとします. 次の行を supfile の始めに追加します: *default tag=. tag= フィールドも date= フィールドも指定しなかった場合に 動き出す重要な特殊なケースがあります. そのケースでは, 特定のバージョンの ファイルを受け取るのではなく, サーバの CVS リポジトリから実際の RCS ファイルを直接受け取ります. 一般的に開発者はこの処理のモードが 好きなようです. 彼らのシステム上にリポジトリそのものの コピーを維持することで, リビジョン履歴を閲覧し過去のバージョンの ファイルを検査できるようになります. しかし, これには大きなディスクスペースが必要になります. どこから入手したいのか? 更新情報をどこから入手するかを cvsup に伝えるために host= フィールドを使用します.CVSup ミラーサイト のどこからでも入手できますが, ネット上での最寄りのサイトを選ぶべきでしょう. この例では, 仮想上の FreeBSD 配布サイト cvsup666.FreeBSD.org を使用します: *default host=cvsup666.FreeBSD.org CVSup を実行する前にホスト名を 実在のものに変更する必要があります. どのように cvsup を実行しても, この設定は を 使用してコマンドラインで変更することができます. 自分のマシンのどこに置きたいのか? prefix= フィールドは, cvsup に受け取ったファイルをどこに置くかを 伝えます. この例では, ソースファイルを直接メインのソースツリー /usr/src に置きます. src ディレクトリはすでにファイルを受け取るために 選択したコレクションで暗黙に指定しているので, これは正しい仕様となります: *default prefix=/usr どこに status ファイルを置きたいのか? cvsup クライアントは “base” ディレクトリと呼ばれる場所に, ある status ファイルを維持しています. すでに受け取った更新情報を追従し続け ることで, これらのファイルは CVSup がより効果的に動作することを支援し ます. 標準の base ディレクトリ /usr/local/etc/cvsup を使用します: *default base=/usr/local/etc/cvsup supfile に指定がない場合は, この設定をデフォルトで使用しますので, 実際には上の行は必要ありません. base ディレクトリが存在しない場合は作成しておきましょう. base ディレクトリが存在しない場合, cvsup クライアントは実行を拒否します. その他もろもろの supfile の設定: 通常 supfile に入れておくべき行がもう一つあります: *default release=cvs delete use-rel-suffix compress release=cvs は, サーバがメインの FreeBSD CVS リポジトリから その情報を取得するように指示します. ほとんどの場合はこのようにしておきますが, ここでの説明の範疇をこえるような 状況では他の指定をすることも可能です. delete は CVSup にファイルを削除することを許可します. CVSup が ソースツリーを完全に最新の状態に 保てるようにするためには, これは常に 指定しておくべきでしょう. CVSup は, これらの責任範囲のファイルだけを 慎重に削除します. たまたま存在する他の余分なファイルについては, まったく手をつけずに残しておきます. use-rel-suffix は ... 神秘的なものです. これについて本当に 知りたい人は, &man.cvsup.1; のマニュアルページをご覧ください. でなければ, 何も考えずに指定してみてください. compress は通信チャネルで gzip 形式の圧縮の使用を有効にします. ご使用のネットワーク接続が T1 speed 以上である場合, この圧縮を 使用しない方がよいかもしれません. そうでない場合は十分に役に立ちます. supfile の例のまとめ: 以下は supfile の例の全体です: *default tag=. *default host=cvsup666.FreeBSD.org *default prefix=/usr *default base=/usr/local/etc/cvsup *default release=cvs delete use-rel-suffix compress src-all cvs-crypto <application>CVSup</application> の実行 さて, 更新の準備ができました. これを実行するコマンドラインは 実に簡単です: &prompt.root; cvsup supfile もちろん, ここでの supfile は作成したばかりの supfile のファイル名です. X11 環境で実行するものと仮定して, cvsup は 通常の操作に必要なボタンを持つ GUI ウィンドウを表示します. “go” ボタンを押して, 実行を監視してください. この例では実際の /usr/src ツリーを更新しているので, cvsup にファイルを更新するのに必要なパーミッションを与えるために, ユーザ root で実行する必要があります. コンフィグレーションファイルを作ったばかりで, しかも以前にこのプログラムを実行したことがないので, 神経質になるのは 無理もない話だと思います. 大切なファイルに触らずに試しに実行する簡単な 方法があります. どこか適当な場所に空のディレクトリを作成して, コマンドラインの引数で指定するだけです: &prompt.root; mkdir /var/tmp/dest &prompt.root; cvsup supfile /var/tmp/dest 指定したディレクトリは, すべての更新されるファイルの 更新先ディレクトリとして使用します. CVSup は /usr/src の下の ファイルを検査しますが, 変更や削除はまったくおこないません. かわりに /var/tmp/dest/usr/src に更新されたすべてのファイルが 置かれるようになります. この方法で実行した場合は, CVSup は base ディレクトリの status ファイルを更新せずにそのままにします. これらのファイルの新しいバージョンは指定されたディレクトリ に書き込まれます. /usr/src の読み取り許可がある限り, このような 試し実行のためにユーザ root になる必要はありません. X11 を利用していないとか単に GUI が気に入らない場合は, cvsup 起動時にコマンドラインに 二つほどオプションを追加する必要があります: &prompt.root; cvsup -g -L 2 supfile オプションは cvsup に GUI を使用しないように伝えます. X11 を利用していない場合には自動的に指定されますが, そうでない場合は 明示的に指定します. オプションは cvsup にファイル更新中の詳細情報をプリントアウト するように伝えます. 冗長性には から までの三つのレベル があります. デフォルトは 0 であり, エラーメッセージ以外はまったく出力 しません. たくさんの他のオプション変数があります. それらの簡単な一覧は cvsup -H で表示されます. より詳しい説明はマニュアルページをご覧ください. 動作している更新の方法に満足したら, &man.cron.8; を使って cvsup を定期的に 実行させる準備をすることができます. cron から起動する際には, 明示的に cvsup が GUI を使わないようにする必要があります. <application>CVSup</application> ファイルコレクション CVSup 経由で入手できるファイルコレクションは 階層的に組織化されています. いくつか大きなコレクションがあり, それらは小さなサブコレクションに 分割されています. 大きなコレクションは, そのサブコレクション毎に 受信することと同じことになります. 下の一覧ではコレクション間の階層関係を 字下げして表現します. 最も一般的に使用するコレクションは src-all, cvs-crypto, そして ports-all です. 他のコレクションは特別な目的を持つ人達だけが 使用しており, ミラーサイトはそれらのすべてを 持っていないかもしれません. cvs-all release=cvs メインの FreeBSD CVS リポジトリであり, 輸出規制された暗号化コードは含まれていません. distrib release=cvs FreeBSD の配布とミラーに関連するファイルです. doc-all release=cvs FreeBSD ハンドブックおよびその他のドキュメントの ソースです. ports-all release=cvs FreeBSD の ports コレクションです. ports-archivers release=cvs アーカイビングのツール. ports-astro release=cvs 天文学関連の ports. ports-audio release=cvs サウンドサポート. ports-base release=cvs /usr/ports のトップにあるその他のファイル. ports-benchmarks release=cvs ベンチマークプログラム. ports-biology release=cvs 植物学関連のプログラム. ports-cad release=cvs CAD ツール. ports-chinese release=cvs 中国語サポート. ports-comms release=cvs 通信ソフトウェア. ports-converters release=cvs 文字コードコンバータ. ports-databases release=cvs データベース. ports-deskutils release=cvs コンピュータが発明される前に 卓上で使われていたものたち. ports-devel release=cvs 開発ユーティリティ. ports-editors release=cvs エディタ. ports-emulators release=cvs 他の OS のエミュレータ. ports-games release=cvs ゲーム. ports-german release=cvs ドイツ語サポート. ports-graphics release=cvs グラフィックユーティリティ. ports-japanese release=cvs 日本語サポート. ports-korean release=cvs 韓国語サポート. ports-lang release=cvs プログラミング言語. ports-mail release=cvs メールソフトウェア. ports-math release=cvs 数値計算ソフトウェア. ports-mbone release=cvs MBone アプリケーション. ports-misc release=cvs 色々なユーティリティ. ports-net release=cvs ネットワーキングソフトウェア. ports-news release=cvs USENET ニュースのソフトウェア. ports-plan9 release=cvs Plan9 からの色々なプログラム. ports-print release=cvs 印刷ソフトウェア. ports-russian release=cvs ロシア語サポート. ports-security release=cvs セキュリティユーティリティ. ports-shells release=cvs コマンドラインシェル. ports-sysutils release=cvs システムユーティリティ. ports-textproc release=cvs 文書処理ユーティリティ (デスクトップパブリッシングは含まない). ports-vietnamese release=cvs ベトナム語サポート. ports-www release=cvs World Wide Web 関連のソフトウェア. ports-x11 release=cvs X window システムをサポートする ports. ports-x11-clocks release=cvs X11 上で動作する時計の数々. ports-x11-fm release=cvs X11 上で動作するファイラ. ports-x11-fonts release=cvs X11 のフォントとフォントユーティリティ. ports-x11-toolkits release=cvs X11 のツールキット. ports-x11-wm release=cvs X11 のウィンドウマネージャ. src-all release=cvs メインの FreeBSD ソース群であり, 輸出規制された暗号化コードは 含まれていません. src-base release=cvs /usr/src のトップにあるその他のファイル. src-bin release=cvs シングルユーザモードで必要な ユーザユーティリティ (/usr/src/bin). src-contrib release=cvs FreeBSD プロジェクト外部からの ユーティリティおよびライブラリ, 比較的無修正 (/usr/src/contrib). src-etc release=cvs システムコンフィグレーションファイル (/usr/src/etc). src-games release=cvs ゲーム (/usr/src/games). src-gnu release=cvs GNU Public License 下にあるユーティリティ (/usr/src/gnu). src-include release=cvs ヘッダファイル (/usr/src/include). src-kerberosIV release=cvs KerberosIV セキュリティパッケージ (/usr/src/kerberosIV). src-lib release=cvs ライブラリ (/usr/src/lib). src-libexec release=cvs システムプログラムであり, 通常は他のプログラムから実行される (/usr/src/libexec). src-release release=cvs FreeBSD の release を構築するために必要なファイル (/usr/src/release). src-sbin release=cvs シングルユーザモード用の システムユーティリティ (/usr/src/sbin). src-share release=cvs 多様なシステム間で共有可能なファイル (/usr/src/share). src-sys release=cvs カーネル (/usr/src/sys). src-tools release=cvs FreeBSD の保守用の色々なツール (/usr/src/tools). src-usrbin release=cvs ユーザユーティリティ (/usr/src/usr.bin). src-usrsbin release=cvs システムユーティリティ (/usr/src/usr.sbin). www release=cvs World Wide Web のデータ用のソースです. cvs-crypto release=cvs 輸出規制された暗号化コードです. src-crypto release=cvs 輸出規制された FreeBSD プロジェクト外部からのユーティリティおよび ライブラリ, 比較的無修正 (/usr/src/crypto). src-eBones release=cvs Kerberos および DES (/usr/src/eBones). src-secure release=cvs DES (/usr/src/secure). distrib release=self CVSup サーバ自身のコンフィグレーションファイルです. CVSup ミラーサイトが使用します. gnats release=current GNATS バグトラッキングデータベースです. mail-archive release=current FreeBSD 関連メーリングリストのアーカイブ. www release=current インストールされた World Wide Web のデータです. WWW ミラーサイトが使用します. 詳細について CVSup の FAQ や CVSup に関するその他の情報については The CVSup Home Page をご覧ください. CVSup のほとんどの FreeBSD 関連の議論は &a.hackers; で おこなわれています. ソフトウェアの新しいバージョンは &a.announce; で アナウンスされます. 質問とバグ報告はプログラムの作者, cvsup-bugs@polstra.com へ 送ってください. <command>make world</command> でシステムを再構築する Contributed by &a.nik;. 訳: &a.jp.y-koga;. 16 March 1998. FreeBSD のどれか特定のバージョン (stable, current など) について, ローカルのソースツリーを同期させたら, そのソースツリーを使ってシステムを 再構築しなければなりません. その方法については, http://www.nothing-going-on.demon.co.uk/FreeBSD/make-world/make-world.html が今のところ一番よいチュートリアル資料です. このチュートリアルの次のバージョンは, ハンドブックに統合される予定です. diff --git a/ja/handbook/kerneldebug/chapter.sgml b/ja/handbook/kerneldebug/chapter.sgml index 4e1a45a5fb..8d6f36133c 100644 --- a/ja/handbook/kerneldebug/chapter.sgml +++ b/ja/handbook/kerneldebug/chapter.sgml @@ -1,689 +1,690 @@ カーネルデバッグ 原作 &a.paul; and &a.joerg; 訳: &a.jp.yoshiaki;. 18 March 1997. <command>kgdb</command> によるカーネルのクラッシュダンプのデバッグ ここではクラッシュダンプ (crash dump : 訳注 この文脈では kernel 自身 の異常によって停止した場合に出力されるイメージを指します) によるカー ネルデバッグの方法を示します. ここではダンプするための十分なスワップ (swap) の容量があるものとします. もし複数のスワップパーティションを持ち, 最初のパーティションがダンプ を保持するのに十分な大きさを持たない場合は 別のダンプデバイスを使うよ うに (config kernel 行で) カーネルのコンフィグをおこなうか, &man.dumpon.8; コマンドを使って別のデバイスを示すことができます. &man.dumpon.8; を使うもっともよい方法は変数 dumpdev を /etc/rc.conf で設定することです. 一般的には /etc/fstab で設定されているスワップデバイスが 使われるでしょう. スワップに使えないデバイスへのダンプ, 例えばテープへのダンプは現在サポートさ れていません. カーネルのコンフィグは config -g によって行ってください. FreeBSD カーネルのコンフィグレーション には FreeBSD のカーネルの設定の詳細がありますので 参照してください. &man.dumpon.8; コマンドを使ってどこへダンプするか カーネルに伝えてください (&man.swapon.8; によってそのパーティションが スワップとして設定された 後でなければならないことに注意してください). これは普通は /etc/rc.conf や /etc/rc で設定されます. あるいは 別の方法としてカーネルコンフィグレーションファイルの config 行の dump 節 で ダンプデバイスをハードコードすることができます. この方法はあまりよくは ありません. カーネルがブート時に crash する場合のクラッシュダンプを取り たい時だけ使うべきです. 以下では kgdbという用語は gdbを “カーネルデバッグモード” で動かしていることを意味します. gdbを オプションをつけて起動するか kgdbという名前でリン クして起動することでこのモードになります. デフォルトでは このリンク は作られていません. また, このアイデアは GNU関係者たちが彼らのツール を別の名前で呼び出した時に異なった動作をするということを 好まない, と いう点で不評です. あるいは将来この機能を廃止することになるかもしれません. カーネルを作った時にそのコピーを kernel.debug という名前で作 りましょう. また, オリジナルに対して strip -dを実行します. オリジナルを普通にインストールします. また strip していないカーネル も同様にインストールすることができますが, シンボルテーブルの参照時間 がいくつかのプログラムでは劇的に増加するでしょう. また, カーネル全体 はブート時に読み込まれ スワップアウトされないため数メガバイトの物理メ モリが無駄になります. 例えばブートプロンプトで 新しいカーネルの名前をタイプすることによって, 新しいカーネルをテストした場合で, 再びシステムを動かすのに別のカーネ ルで立ち上げることが必要な場合はブートプロンプトで フラグ を使いシングルユーザの状態にしてください. そして以下のような操作をおこな います. &prompt.root; fsck -p &prompt.root; mount -a -t ufs # /var/crash 用のファイルシステムを書き込み可能にする &prompt.root; savecore -N /kernel.panicked /var/crash &prompt.root; exit # ...マルチユーザモードへ移行 ここに示した &man.savecore.8; は (現在動いているものとは別の) カーネルのシンボル名の抽出をおこなうために使っています. 抽出はデフォルトで は現在動いているカーネルに対しておこなわれ, クラッシュダンプとカーネルシンボ ルのくい違いのためにまったく何もしません (訳注:そのためにオプション で実際にダンプをおこしたカーネルを指定します). クラッシュダンプの起きた後に /sys/compile/WHATEVERへ行き kgdbを動かします. kgdb より次のようにします. symbol-file kernel.debug exec-file /var/crash/kernel.0 core-file /var/crash/vmcore.0 こうすると, クラッシュダンプを使ってカーネルソースを他のプログラムと同様に デバッグすることができます. 次に kgdb での手順のセッションのログを示します. 長い行は読 みやすくするために改行しました. また, 参照のために行番号を入れてあり ます. ただし, これは実際の pcvtコンソールドライバの開発中の実際のエ ラーのトレースです. - 1:Script started on Fri Dec 30 23:15:22 1994 + 1:Script started on Fri Dec 30 23:15:22 1994 2:&prompt.root; cd /sys/compile/URIAH 3:&prompt.root; kgdb kernel /var/crash/vmcore.1 - 4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel...done. + 4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel +...done. 5:IdlePTD 1f3000 6:panic: because you said to! 7:current pcb at 1e3f70 8:Reading in symbols for ../../i386/i386/machdep.c...done. 9:(kgdb) where 10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767) 11:#1 0xf0115159 in panic () 12:#2 0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698) 13:#3 0xf010185e in db_fncall () 14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073) 15:#5 0xf0101711 in db_command_loop () 16:#6 0xf01040a0 in db_trap () 17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723) 18:#8 0xf019d2eb in trap_fatal (...) 19:#9 0xf019ce60 in trap_pfault (...) 20:#10 0xf019cb2f in trap (...) 21:#11 0xf01932a1 in exception:calltrap () 22:#12 0xf0191503 in cnopen (...) 23:#13 0xf0132c34 in spec_open () 24:#14 0xf012d014 in vn_open () 25:#15 0xf012a183 in open () 26:#16 0xf019d4eb in syscall (...) 27:(kgdb) up 10 28:Reading in symbols for ../../i386/i386/trap.c...done. 29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\ 30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\ 31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\ 32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\ 33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\ 34:ss = -266427884}) (../../i386/i386/trap.c line 283) 35:283 (void) trap_pfault(&frame, FALSE); 36:(kgdb) frame frame->tf_ebp frame->tf_eip 37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done. 38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\ 39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403) 40:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); 41:(kgdb) list 42:398 43:399 tp->t_state |= TS_CARR_ON; 44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */ 45:401 46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200) 47:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); 48:404 #else 49:405 return ((*linesw[tp->t_line].l_open)(dev, tp, flag)); 50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */ 51:407 } 52:(kgdb) print tp 53:Reading in symbols for ../../i386/i386/cons.c...done. 54:$1 = (struct tty *) 0x1bae 55:(kgdb) print tp->t_line 56:$2 = 1767990816 57:(kgdb) up 58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\ 59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126) 60: return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p)); 61:(kgdb) up 62:#2 0xf0132c34 in spec_open () 63:(kgdb) up 64:#3 0xf012d014 in vn_open () 65:(kgdb) up 66:#4 0xf012a183 in open () 67:(kgdb) up 68:#5 0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\ 69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\ 70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \ 71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \ 72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673) 73:673 error = (*callp->sy_call)(p, args, rval); 74:(kgdb) up 75:Initial frame selected; you cannot go up. 76:(kgdb) quit 77:&prompt.root; exit 78:exit 79: 80:Script done on Fri Dec 30 23:18:04 1994 上の出力についてのコメントをします. line 6: これは DDB (後述) からのダンプです. このため “because you said to!” という panicコメントがつき, ページフォルトのト ラップによって DDBに入ったことが原因の, やや長いスタックトレー スがあります. line 20: スタックトレースでのこれは trap()関数の位置で す. line 36: 新しいスタックフレームの使用を指定しています. これは現 在は必要ありません. trapの場合ではスタックフレームは正 しい場所を指していると考えられます. (私は新しいコアダンプ を持っていません. 私のカーネルは長い間 panicを起こしていま せん.) ソースコードの 403行を見ると,“tp”ポインタのアク セスが失敗しているか配列のアクセスが範囲外である可能性が高 いことがわかります. line 52: 怪しいポインタですが, アクセスは正常におこなえました. line 56: ところが, 明らかにポインタはゴミを指しています. これで エラーを見つけました! (ここのコードの部分からはよくわかり ませんが, tp->t_lineはコンソールデバイスの規定 する行を参照しているので, もっと小さな整数でなければなりませ ん. ) DDD によるクラッシュダンプのデバッグ カーネルのクラッシュダンプは ddd のようなグラフィカルなデバッガで調べることもできます. 通常はコマンドラインで オプションをつけて ddd を起動します. たとえば: &prompt.root; ddd -k /var/crash/kernel.0 /var/crash/vmcore.0 クラッシュダンプを ddd のグラフィカルなインターフェースを使って 見ることができます. 突然ダンプした場合の解析 カーネルが予想もしない時にコアダンプして config -g を行ってコンパイルされていなかった場合にはどうしたら よいでしょう. すべてが失われるわけではありません. パニックを起こさないでください. もちろん, クラッシュダンプを使えるようにする必要があります. 使い方は前述の部分を見てください. カーネルのコンパイルディレクトリで, (Makefileの) COPTFLAGS?=-O とある行を編集します. オプショ ンをここに加えます (オプティマイズオプションのレベルは 変更しな いでください ). もし大まかにコードのどこで問題が起きているか (例 えば, 上の例では pcvtドライバ) わかっているのでしたら, その部 分のコードについてのすべてのオブジェクトファイルを 消してください. カーネ ルを再構築しましょう. Makefileのタイムスタンプの変更により, 例えば trap.o などのいくつかの他のオブジェクトファイルも作り直さ れます. 少しの幸運があれば, オプションが追加されても作ら れるコードは変更されず, いくらかのデバッグシンボル以外には 問題を 起こしたコードとそっくりな新しいカーネルを手に入れることが できます. 少なくとも &man.size.1; コマンドで古い方と新しい方のサイズを比較すべ きです. これが食い違っていれば, 多分あきらめなければならないでしょう. ダンプを使って前述のように動かして調べます. デバッグシンボルは 必ずしも十分ではありません. 上の例ではスタックトレースでいくつかの関 数の行番号や引数リストが表示されないかもしれません. もしより多くのデ バッグシンボルが必要であれば,十分になるまで 適切なオブジェクトファイ ルを消して (makeして) kgdbセッションを繰り返してください. これは必ずしもうまく動くと保証はできません. しかしほとんどの場合でう まくいくでしょう. DDBを使ったオンラインカーネルデバッグ kgdb は非常に高レベルのユーザインタフェースを提 供するオフラインデバッガですが, いくつかのことはできません. (できないことの中で) 極めて重要なことはカーネルコードへのブレークポイ ントの設定とシングルステップ実行です. カーネルの低レベルデバッグが必要であれば, DDBと呼ばれる on-lineデバッ ガが使えます. ブレークポイントの設定, シングルステップのカーネルの実 行, 変数の検査と変更などができます. ただし,これはカーネルのソースファ イルにアクセスすることはできません. kgdbのようにすべてのデ バッグ情報にはアクセスできず, globalと staticのシンボルにアクセス することができるだけです. カーネルに DDB を含めるためにはコンフィグファイルに次のようなオプショ ンを加えて, options DDB 再構築をおこないます. ( FreeBSDのカーネルの設定の詳細については FreeBSD カーネルのコンフィグレーションを参照してくださ い. もしブートブロックが古いバージョンですと, デバッガのシンボルが完 全にはロードされないかもしれませんので注意してください. DDB シンボル がロードされるようにブートブロックを 最新の物にアップデートしてくださ い) DDB カーネルの実行において, DDBに入るいくつかの方法があります. 最初 の, 最も早い方法はブートプロンプトが出ている時に のブート フラグをタイプすることです. カーネルはデバッグモードで起動し, デバ イスのプローブ以前に DDBに入ります. したがって, デバイスのプローブ/初期 設定ファンクションのデバッグができます. 2つ目のシナリオはキーボードのホットキーで, 通常は Ctrl-Alt-ESCです. syscons ではホットキーは再設定することができ, 配付されているいくつかの キーマッピングでは別のキーに 再設定されていますので確認しておいてください. シリアルラインの BREAKを使って シリアルコンソールから DDBへ入ることを可 能にするオプションもあります (カーネルコンフィグレーションファイルの options BREAK_TO_DEBUGGER). これは 多くのつまらないシリ アルアダプタが, 例えばケーブルを引き抜いた時に BREAK状態を意味もなく 作り出してしまうのでデフォルトでは無効になっています. 3つ目は, DDB を使うようになっているカーネルがパニック状態になると DDB へ入るというものです. このため, 無人運転するマシンのカーネルにDDBを 入れるのは賢明ではありません. DDB のコマンドはおおまかには gdb のいくつかのコマンドと似て います. おそらく最初にブレークポイントを 設定する必要があるでしょう. b function-name b address 数値はデフォルトでは16進数で, シンボル名とはまったく異ります. 16進数で a-f の文字で始まる場合は, 先頭に 0x をつける必要があります(それ以外の数字の場合はどちらでもか まいません). function-name + 0x103のような単純な式を使うこ とができます. 割り込みされたカーネルから処理を続行するためには, c とタイプするだけです. スタックのトレースには trace とします. DDB にホットキーで入った場合は, カーネルはその (ホットキーの) 割り込み の処理を行っていますのでスタックトレースは あまり役にたたないことに注 意してください. ブレークポイントを削除したい場合は, del del address-expression とします. 最初の形式はブレークポイントにヒットしたすぐ後で使うことが でき, 現在のブレークポイントを削除します. 2番目の形式では任意のブレー クポイントを削除することができますが, 次の形式で得られるような正確な アドレスを与えることが必要です. show b カーネルをシングルステップ実行させるには s としてみてください. これは関数呼出し先までステップ実行 (step into function) するでしょう. 次のステートメントが終了するまでのDDBトレースは n によっておこなうことができます. これは gdb の next 命令とは異ります. gdbの finish命令と似ています. メモリ上のデータを調べるには (例として) 次のようにします. x/wx 0xf0133fe0,40 x/hd db_symtab_space x/bc termbuf,10 x/s stringbuf word/halfword/byte 単位でアクセスをおこない, hex (16進) /dec (10進) / char (文字) /string (文字列) で表示します. カンマの後ろの数字はオブジェク トカウントです. 次の 0x10個の要素を表示するには, 単純に x ,10 とします. 同様に次のように使うことができます. x/ia foofunc,10 foofunc の最初の 0x10個の命令語をディスアセンブルし, foofunc の先頭からのオフセットとともに表示します. メモリの内容を変更するには writeコマンドを使います. w/b termbuf 0xa 0xb 0 w/w 0xf0010030 0 0 コマンドモディファイアの (b/h/w) はデータを 書くサイズを定義し, これに続く最初の式は書き込むアドレス, 残りがこれ に続く連続するメモリアドレスに書き込まれるデータになります. 現在のレジスタ群の内容を知りたい場合は show reg とします. また, 単一のレジスタの値を表示するには, 例えば p $eax とします. また値の変更は set $eax new-value とします. DDBからカーネルの関数を呼び出す必要がある場合は, 単に call func(arg1, arg2, ...) とします. return 値が出力されます. 動いているプロセスの &man.ps.1; スタイルの概要は ps です. カーネルの失敗の原因の調査が終わったらリブートすべきです. それまでの 不具合によりカーネルのすべての部分が期待するような 動作をしているわけ ではないということを忘れないでください. 以下のうちいずれかの方法でシ ステムのシャットダウンおよびリブートを行ってください. call diediedie() カーネルをコアダンプしてリブートしますので, 後で kgdbによってコアの高 レベル解析をすることができます. このコマンドは通常 continue命令にエイリアスされています. panicにエイリアスされている call boot(0) は動いているシステムを `clean' に shut downするよい方法です. すべて のディスクを sync()して最後にリブートします. ディスクとカー ネルのファイルシステムインタフェースが破損していない限り, ほぼ完全 に `clean'にシャットダウンするよい方法でしょう. call cpu_reset() は大惨事を防ぐための最後の手段で 「赤い大きなボタン」 を押すのとほとんど 同じです.(訳注: リセットボタンを押すのとほぼ同じであるという意味です) 短いコマンドの要約は help をタイプします. ただし, デバッグセッションのために &man.ddb.4; の マニュアルページのプリントアウトを用意しておくことを 強くお奨めします. カーネルのシングルステップ中にオンラインマニュアルを 読むことは難しい ということを覚えておいてください. リモート GDB を使ったオンラインカーネルデバッグ この機能は FreeBSD 2.2 からサポートされました. これは本当にすばらし い機能です. GDB はすでにかなり以前より リモートデバッグ をサポートしてい ます. これはシリアル回線を使い非常に単純なプロトコルで行ないます. もちろん, この方法では今までに示した方法とは違い, 2台のマシンが必 要になります. 1台はデバッグ環境のためのホストで, すべてのソースとす べてのシンボルを含んだバイナリのコピーを持っています. もう 1台は ターゲットマシンで, 同一のカーネルのコピー (ただしデバッグ情報は 取り除いてあるもの) を単に実行するためのものです. この場合, カーネルのコンフィグレーションは config -g で行な い, を含めなくてはなりません. そうして通常通りコンパイルし ます. こうして作ったバイナリファイルはデバッグ情報のために非常に大き くなります. このカーネルをターゲットマシンにコピーして strip -x でデバッグシンボルを取り除きます. そして ブートオプションを使いブートします. ターゲットマシンの 1番目の シリアル回線をデバッグホストの いずれかのシリアル回線につないでおきま しょう. それからデバッグ(訳注:ホスト)マシン上で, ターゲットとなって いるカーネルのコンパイルディレクトリで gdb を起動します: &prompt.user; gdb -k kernel GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc... (kgdb) リモートデバッグセッションの初期化 (1番目のシリアルポートを使用する ことの設定) を以下のように行ないます. (kgdb) target remote /dev/cuaa0 次にターゲットマシン (デバイスのプローブ直前で DDB に入っています) で次のように入力します: Debugger("Boot flags requested debugger") Stopped at Debugger+0x35: movb $0, edata+0x51bc db> gdb DDB は次のような出力を返すでしょう. Next trap will enter GDB remote protocol mode gdbと入力するたびに リモート GDB とローカル DDB が交互に切り替わ ります. トラップをすぐに起こすために単に ``s'' (step) と入力して下 さい. そうするとホストの GDB はターゲットのカーネルの制御を行なうよ うになります. Remote debugging using /dev/cuaa0 Debugger (msg=0xf01b0383 "Boot flags requested debugger") at ../../i386/i386/db_interface.c:257 (kgdb) このセッションではソースコードへのフルアクセスや Emacs の window 上 の gud-mode (これは別の Emacs window に自動的にソースコードを表示し ます) で動かすなど, 通常の GDB セッションでできることのほとんどのこ とができます. リモート GDB は LKM のデバッグも行なうことができます. 最初に LKM を デバッグシンボルを含めた形で作ります. &prompt.root; cd /usr/src/lkm/linux &prompt.root; make clean; make COPTS=-g そしてターゲットマシン上で モジュールのこのバージョンをインストールし ます. これをロードしてから, modstat を使ってロードされている ことを確認してください: &prompt.root; linux &prompt.root; modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 4 f5109000 001c f510f010 1 linux_mod 示されたロードアドレスに 0x20 (a.outのヘッダはおそらくこの大きさでしょ う) を加えます. それがモジュールコードの再配置されるアドレスです. GDB の add-symbol-file コマンドを使ってデバッガにモジュールの 情報をつたえます. (kgdb) add-symbol-file /usr/src/lkm/linux/linux_mod.o 0xf5109020 add symbol table from file "/usr/src/lkm/linux/linux_mod.o" at text_addr = 0xf5109020? (y or n) y (kgdb) これで LKM のすべてのシンボルにアクセスできるようになります. コンソールドライバのデバッグ DDBを動かすためにはコンソールドライバが必要ですから, コンソールドラ イバ自身に不具合のある場合は複雑になります. シリアルコンソールを利 用する方法 (ブートブロックを変更するか Boot:プロンプトで と入力する) を思い出してください. そして標準ター ミナルを最初のシリアルポートに設定します. DDBは, もちろんシリアルコ ンソールを含むいずれの コンソールドライバの設定でも動作します. diff --git a/ja/handbook/ports/chapter.sgml b/ja/handbook/ports/chapter.sgml index 6390ba6298..1c343d7c23 100644 --- a/ja/handbook/ports/chapter.sgml +++ b/ja/handbook/ports/chapter.sgml @@ -1,5231 +1,5233 @@ アプリケーションのインストール : ports コレクション 原作: &a.jraynard;. 訳: &a.jp.masaki;, &a.jp.saeki;. 11 November 1996. FreeBSD の ports コレクションを利用すると, 最小限の労力で 非常に幅広くのアプリケーションのコンパイルとインストールがおこなえます. やってみたことのある方はよくご存知でしょうが, オープンな規格とは 全くの誇大広告であって, あるプログラムを異なるバージョンの Unix 上で 動作させることは退屈で手間のかかる仕事です. 求めているプログラムが自分のシステムでうまくコンパイルでき, 正しいところにインストールできて, 完璧に動作するとしたらとてもラッキーです. しかし, あいにくこれは滅多にないことなのです. ほとんどのプログラムについて, あなたは髪を掻きむしることになるでしょうし, かなりのプログラムでは, 白髪混じりの頭になってしまったり, あるいは慢性の 脱毛症にすら なってしまうかもしれません... いくつかのソフトウェアディストリビューションでは, 設定用のスクリプトを 配布することでこの問題を解決しようとしています. これらのスクリプトの中には非常に精巧なものもありますが, 残念ながら, 中にはこれまで 聞いたこともないようなシステムの名前をしゃあしゃあと 言い放ったうえに, まるでシステムレベルの Unix プログラミングに関する 最終試験のような, たくさんの質問をしてくる場合があります. (例えば, このシステムの gethitlist 関数は fromboz への const ポインタを 返しますか? それとも const fromboz へのポインタを返しますか?, このシステムには Foonix スタイルの, 容認できない例外処理をおこなう ルーチンがありますか? もしもないとしたら, それはなぜですか?) 幸いなことに, ports コレクションがあれば, これらのきつい作業はすべて 完了しています. make install とタイプするだけで, 動作するプログラムを 入手することができるのです. なぜ ports コレクションを作ったのか? FreeBSD の基本システムは, 非常に多くのツールやユーティリティから 構成されています. しかし, よく使われるプログラムのうち多くのものが, この基本システムには含まれていません. その理由は:- ある Lisp ベースのエディタのように, それがないと生きていけないと 言う人もいれば, ディスクの無駄だと言う人もいるようなプログラム. 基本システムに組み込むには特殊すぎるプログラム. (CAD やデータベースなど.) “時間のある時に, ちょっと見ておかなければ”というような類の, それがシステムに含まれていないことが 致命的とは言えないプログラム. (おそらく, 何らかの言語などでしょう.) FreeBSD のような真面目なオペレーティングシステムの一部として 供給するには遊びが過ぎるようなプログラム. ;-) たくさんのプログラムを基本システムに組み込んだとしても, もっともっと 組み込みたいという要求が出てくるので, どこかで制限を引かなくてはならないため. (そうしなければ FreeBSD の配布物は, とてつもなく膨大になってしまうでしょう.) すべての人が自分のお気に入りの プログラムを手作業で移植しなければ ならないとしたら, (途方もない膨大な作業の繰り返しをさておいたとしても) それは明らかに不合理な話です. そこで, FreeBSD プロジェクトでは, 標準のツールを使って移植のプロセスを 自動化する巧妙な方法を考え出しました. なお, これは単純ながら非常に柔軟なツールを組み合わせることで, 非常に強力な働きをさせるという“Unix 流”の作業の優れた実例です. ports コレクションはどのように動くのでしょうか? インターネットでは通常, tarball の形で プログラムが配布されています. これは, Makefile とソースコードで構成され, 普通は何らかの説明書 (あいにく, いつもわかりやすく書かれているとは 限りませんが) が付属しています. ことによるとコンフィグレーションスクリプトも 含まれているかもしれません. 標準的な手順では, FTP で tarball を入手して, 適当なディレクトリで展開します. 次に説明書を読んで, 必要な変更をおこないます. そして, 設定スクリプトを実行し, 標準の make コマンドを使ってソースのコンパイルとインストールを おこないます. FreeBSD の ports も tarball の仕組みを利用していますが, これはユーザが 苦労して作業することを期待したものではなく, どのようにすれば FreeBSD 上で そのプログラムが動くようになるかという「ノウハウ」を スケルトン を使用して収めているものです. スケルトンは, カスタマイズ済みの Makefile も 提供していますので, ほとんどすべての ports は同じ手順でインストールすることが できます. もしあなたが (あなたの FreeBSD システム または FTP サイト にある) ports スケルトンを見ていて, そこに潜んでいる あらゆる種類の先端的な ロケット工学的なものを見つけられると期待していると, つまらなそうなファイルやディレクトリがそこにあるだけなのを見て, がっかりするかもしれません. (ports を手に入れる方法については, すぐに FreeBSD ports コレクションの入手方法 の節でお話します.) “一体どうしたらいいんだ? ここにはソースコードが ないじゃないか?” というあなたの叫びが聞こえるようです. 心配いりません. おとなしく読んでいけば, すべてが (たぶん) 明らかに なるでしょう. 試しに ports をインストールして, 何が起きるのかを見てみましょう. ここではサンプルとして開発者向けの便利なツール, ElectricFence を選択します. このスケルトンを選んだ理由は, 他の ports に比べても素直で理解しやすく 書かれているからです. 自宅で試してみる場合には, root になる必要があるでしょう. &prompt.root; cd /usr/ports/devel/ElectricFence &prompt.root; make install >> Checksum OK for ElectricFence-2.0.5.tar.gz. ===> Extracting for ElectricFence-2.0.5 ===> Patching for ElectricFence-2.0.5 ===> Applying FreeBSD patches for ElectricFence-2.0.5 ===> Configuring for ElectricFence-2.0.5 ===> Building for ElectricFence-2.0.5 [大量のメッセージをコンパイラが出力します...] ===> Installing for ElectricFence-2.0.5 ===> Warning: your umask is "0002". If this is not desired, set it to an appropriate value and install this port again by ``make reinstall''. install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.a /usr/local/lib install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.3 /usr/local/man/man3 ===> Compressing manual pages for ElectricFence-2.0.5 ===> Registering installation for ElectricFence-2.0.5 ここではあなたが混乱しないように, コンパイル時の出力を すべて取り除いてあります. もしもあなた自身で実行されたら, 最初にこのような 出力結果が得られるはずです:- &prompt.root; make install >> ElectricFence-2.0.5.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://ftp.doc.ic.ac.uk/Mirrors/sunsite.unc.edu/pub/Linux/devel/lang/c/. make プログラムは, あなたの手元にソースコードがないことを検出し, 処理を続けられるようにソースを FTP でダウンロードしようとします. この例では, あらかじめ手動でソースコードを用意してあったので, 持ってくる必要はありませんでした. では, 続けて make プログラムが何をしているのか見てみましょう. ソースコード tarball のありかを 確認します. 手元にファイルが存在しなければ, FTP サイトから入手しようとします. チェックサム テストを実行して, その tarball が事故か何かで途中で切れていたり, ASCII モードで ダウンロードされていたり, 転送中にニュートリノによって傷められたりして 改変されたりしていないかどうかを確認します. tarball を一時的な作業用ディレクトリに展開します. FreeBSD 上でコンパイルしたり, 動作させるのに必要な すべての パッチ をソースコードに当てます. 構築のために必要な コンフィグレーションスクリプトを実行します. コンフィグレーションスクリプトの 質問には正確に答えてください. (いよいよ!) ソースコードをコンパイルします. 実行形式のプログラム, マニュアル, その他のサポートファイルを, システムのプログラムと混ざってしまわないように /usr/local 以下に インストールします. ports はすべて同じ場所にインストールされ, システムのあちこちにばらまかれることはありません. インストール結果はデータベースに登録されます. これにより, インストールしたプログラムがもしも気に入らなかったときも, システムから すべての痕跡をきれいに 消去 することができます. 以上のステップが make の出力と一致しているかどうか確認してください. 今まで確認していなかったのなら, 今からするようにしてください! FreeBSD ports コレクションの入手 あるプログラムの FreeBSD port を入手するには二つの方法があります. ひとつは FreeBSD CD-ROM を使う方法で, もうひとつは インターネット接続 を使う方法です. CD-ROM からコンパイルする FreeBSD CD-ROM がドライブに入っており, /cdrom にマウントされていると仮定すると (マウントポイントが /cdrom である必要があります), ただ普通に実行するだけで ports を構築できるようになり, tarball をネットワーク経由でダウンロードするのではなく /cdrom/ports/distfiles/ からさがすようになります (そこにあればの話ですが). CD-ROM にある port スケルトンを使いたければ, 他に /etc/make.conf の 変数を以下のようにセットする方法があります: PORTSDIR= /cdrom/ports DISTDIR= /tmp/distfiles WRKDIRPREFIX= /tmp (任意の十分な空きスペースの場所を /tmp とおいています). 次に, /cdrom/ports 下の適宜のサブディレクトリに cd して, 例のごとく make install とタイプします. WRKDIRPREFIX は port に /tmp/cdrom/ports の下でビルドさせようとします; 例えば, games/oneko は /tmp/cdrom/ports/games/oneko の下で ビルドされるでしょう. ライセンスの制限により, いくつかの ports でオリジナルのソースコードを CD-ROM に入れることができなかったものがあることに注意してください. この場合, インターネット経由で ports をコンパイルする の 節を参照してください. インターネット経由で ports をコンパイルする CD-ROM を持っていなかったり, その ports の最新バージョンを確実に入手したい 場合は, その ports の スケルトン を ダウンロードする必要があります. ところで, これは落し穴が たくさんある作業に見えるかもしれませんが, 実際には非常に簡単です. 初めに, あなたの動かしている FreeBSD がリリースバージョンなら ports ページ でその FreeBSD 用の “アップグレードキット” を手にいれてください. このパッケージには, 最新の ports をコンパイルするのに必要な, リリース以降に更新されたファイルが含まれています. FreeBSD の FTP サーバーがその場で tarball を作成できることを利用してスケルトンを入手すると 非常に便利です. ここでは例として databases ディレクトリにある gnats プログラムを使って説明します. (角型かっこの中の文はコメントなので, 実際に実行する場合には, これをタイプしないでください!):- &prompt.root; cd /usr/ports &prompt.root; mkdir databases &prompt.root; cd databases &prompt.root; ftp ftp.freebsd.org [ユーザ名 `ftp' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] > cd /pub/FreeBSD/ports/ports/databases > get gnats.tar [gnats スケルトンの tarballs を取得] > quit &prompt.root; tar xf gnats.tar [gnats スケルトンの展開] &prompt.root; cd gnats &prompt.root; make install [gnats の構築とインストール] さて何が起きるでしょうか? FTP サイトにいつも通りに接続して, データベースの サブディレクトリに移動します. get gnats.tar とコマンドを入力すると, FTP サイトでは gnats ディレクトリを tarred にしてくれるのです. gnats スケルトンを展開したら, gnats ディレクトリへ移動して ports を構築します. すでに 説明したように, make の過程で 手元にソースコードがないことを検出すると, ソースコードを取得してから 展開し, パッチ当てと構築をおこないます. それでは, 少し冒険をしてみましょう. 一つの ports スケルトンを 取得するかわりに, たとえば ports コレクションの中のデータベースの スケルトンをすべて, サブディレクトリ全体を取得してみましょう. やり方はほとんど同じです:- &prompt.root; cd /usr/ports &prompt.root; ftp ftp.freebsd.org [ユーザ名 `ftp' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] > cd /pub/FreeBSD/ports/ports > get databases.tar [データベースディレクトリの tarballs を取得] > quit &prompt.root; tar xf databases.tar [すべてのスケルトンを展開] &prompt.root; cd databases &prompt.root; make install [データベース ports 全部の構築とインストール] わずかばかりの簡単なコマンドで, この FreeBSD マシン上にデータベース プログラムを一揃い手に入れてしまいました! 一つの ports スケルトンを取ってきて それを構築する場合との違いは, すべてのディレクトリを一度に取得して, 全部を一度にコンパイルしたということだけです. かなり感動的だと思いませんか? たくさんの ports をインストールする つもりなら, おそらくすべての ports ディレクトリをダウンロードしておく 価値があるでしょう. スケルトン スケルトン (訳注: skeleton とは骸骨のことです) とは, 締め切りを守るため, 食事をするのを忘れるほど仕事にのめり込んだ ハッカーたちのなれの果ての ことでしょうか? FreeBSD の屋根裏に潜む, なにか気持ちの悪いものでしょうか? いいえ, ここでスケルトンの意味するところは, ports の魔術を実現するのに 必要とされるすべてのものを提供する最小の骨組みのことです. <filename>Makefile</filename> スケルトンのもっとも重要な要素は Makefile です. Makefile は ports を どのようにコンパイルし, インストールをおこなうかを指示する いろいろな命令を含んでいます. 以下に ElectricFence の Makefile を示します:- # New ports collection makefile for: Electric Fence # Version required: 2.0.5 # Date created: 13 November 1997 # Whom: jraynard # # $Id$ # DISTNAME= ElectricFence-2.0.5 CATEGORIES= devel MASTER_SITES= ${MASTER_SITE_SUNSITE} MASTER_SITE_SUBDIR= devel/lang/c MAINTAINER= jraynard@freebsd.org MAN3= libefence.3 do-install: ${INSTALL_DATA} ${WRKSRC}/libefence.a ${PREFIX}/lib ${INSTALL_MAN} ${WRKSRC}/libefence.3 ${PREFIX}/man/man3 .include <bsd.port.mk> "#" で始まる行は, 人間のためのコメント行です. (ほとんどの Unix のスクリプトと同じですね.) DISTNAME は tarball の名前から拡張子を取ったものです. CATEGORIES はこのプログラムの種類を示します. この場合, 開発者向けのユーティリティということになります. 完全なリストはこのハンドブックの カテゴリ をみてください. MASTER_SITES はマスタ FTP サイトの URL です. もしローカルシステムに tarball がない場合には, ここから取得します. これは信頼できると考えられているサイトで, 通常はそのプログラムを インターネット上で公式に配布しているサイトです. (そのソフトウェアがインターネット上で「公式に」 配布されているとしたら) MAINTAINER は, 例えば新しいバージョンのプログラムが出た場合に, 必要であれば スケルトンの更新をおこなう保守担当者の 電子メールアドレスです. 次の数行はとりあえず飛ばします. .include <bsd.port.mk> この行は, この ports に必要なその他の命令やコマンドは bsd.port.mk に 入っているということを示しています. これらはすべての ports で共通のものなので, それぞれの Makefile に書いておく必要はありません. そのため単一の標準ファイルに まとめられているのです. ここでは Makefile がどう働くかを詳細に調査するのが目的ではありませんので, MAN3 で始まる行は, インストールの後に ElectricFence のマニュアルを 圧縮するために使用される, と言っておくだけで充分でしょう. これにより, 貴重なディスクスペースが保護されているわけです. オリジナルの port では install ターゲットが用意されていないので, do-install からの 3 行が この ports によって生成されたファイルを 正しい場所に置くために使用されます. <filename>files</filename> ディレクトリ ports のチェックサム算出には MD5 アルゴリズムを使用しているので, この チェックサム を含んでいる ファイルは md5 と呼ばれます. ちょっと混乱するかもしれませんが, このファイルは files という 名前のディレクトリに置かれています. このディレクトリは, ports に必要だけれども, 他のどこにも属さない 雑多なファイルも含んでいます. <filename>patches</filename> ディレクトリ このディレクトリには, FreeBSD ですべてを正常に動作させるのに 必要な パッチ が含まれています. <filename>pkg</filename> ディレクトリ このディレクトリには, 非常に役立つ三つのファイルが含まれています:- COMMENT — プログラムについての 1 行の説明. DESCR — より詳細な説明. PLIST — プログラムのインストール時に作成される, すべてのファイルのリスト. ports が動かないのですが, どうしたらよいでしょう おやおや. では, 次の四つのどれかをやってみてください: 自分で修正する. ports の仕組みに関する技術的な詳細については, アプリケーションの移殖方法をご覧ください. 苦情をいう. これは電子メールで だけ にしてください! このようなメールの宛先は &a.ports; です. なお, 必ず port の名前やバージョン, その port のソースや distfile(s) を どこから入手したか, どんなエラーが発生したのかを書いておいてください. 忘れてしまう. これはほとんどの場合最も簡単な方法です. ports のプログラムのうち必要不可欠な物はごくわずかです. FTP サイトからコンパイル済みのパッケージを入手する. “マスター”パッケージコレクションは FreeBSD の FTP サイトの パッケージディレクトリ に置いてありますが, まずあなたの近くのローカルミラーサイトを確認してください! ソースからのコンパイルに挑戦するよりも, パッケージを使うほうが (全体的に見て) ずっと確実に動作するでしょうし, より手っ取り早い方法でもあります. システムにパッケージをインストールするには, &man.pkg.add.1; を使ってください. 質問と回答集 Q. 私はモデムについての議論を しているのかと思っていました??! A.なるほど, あなたはきっとコンピュータの背面についている シリアルポートのことだと思ってしまったのでしょう. あるバージョンの Unixから別のバージョンの Unix へとプログラムを 移殖することを “porting” というのですが, ここで我たちは “porting” の結果 という意味で “port” を使っています. (コンピュータに関わる人々の悪しき習慣として, ひとつの同じ言葉を複数の まったく違う意味として使うことがあるのです.) Q. 私は, 標準以外のプログラムのインストールには packages を使うと 思っていたのですが. A. そのとおり. 通常は packages が最も手早くて簡単な方法です. Q. それではどうして面倒な ports があるのですか? A. いくつかの理由があります:- いくつかのソフトウェアのライセンス条件には, バイナリではなくソースコードでの 配布を求めているものがあります. バイナリ配布を信用していない人もいます. 少なくともソースコード があれば, ソースコードを読んで, (理論的には) 潜在的な問題点を自分で 見つけ出すこともできるはずです. ローカルなパッチを入手した場合, それを自分で追加するために ソースコードが必要になります. プログラムがいかにコンパイルされるべきかについて, あなたはパッケージを作った人とは 異なる見解を持っているかもしれません. どんな最適化オプションをつけるべきかとか, デバッグバージョンを作ってから それを strip するべきだとか, いや, そうするべきでない, などなど, 確固たる見解を持っている人もいるでしょう. ソースコードを手元に置いておきたい人たちもいます. 彼らは, 退屈したときに眺めたり, あちこち解析してみたり, ソースコードを 借用したり (もちろん, ライセンスが許せばの話ですが) するのです. あなたがソースコードを持っていなければ, それはソフトウェアとは 言えませんね! ;-) Q. パッチとは何ですか? A. パッチとは, あるバージョンから他のバージョンへどのように変更するかを 示す, (通常は) 小さなファイルです. “23 行目を削除”, “468 行目の後に これらの 2 行を追加”, または“197 行目をこのように変更”というような 内容を含んでいます. これは, “diff” という名前のプログラムで生成されます. Q. tarball とは一体何ですか? A. .tar または .tar.gz という拡張子を持つファイルです. (.tar.Z のようなバリエーションも ありますし, DOS のファイルシステム用に .tgz と短縮される場合もあります.) これは基本的に, 一つのファイルに固めた (.tar) ディレクトリツリーです. 圧縮されている (.gz) 場合もあります. これは元々 Tape ARchives (訳注: テープアーカイブ) (このため tar という名前なのです) で使われていたものなのですが, インターネット上でプログラムのソースコードを配布するために 広く使われている方法です. これらのファイルの中身を見たり, 展開したりすることもできます. FreeBSD の基本システムに付属する Unix 標準の tar コマンドを使ってみると 次のようになります:- &prompt.user; tar tvzf foobar.tar.gz &prompt.user; tar xzvf foobar.tar.gz &prompt.user; tar tvf foobar.tar &prompt.user; tar xvf foobar.tar Q. チェックサムとは何ですか? A. これは, チェックしたいファイル中のすべてのデータを加えて生成した 数値です. 何か文字が書き換わっていたら, チェックサムが一致しなくなります. そのため, 単純な比較だけで違いを見つけることができるのです. (実際には, 文字の位置が入れ替わるなどの, 単純な加算ではわからない問題も 見つけることができる複雑な方法で計算されています.) Q. 私は, CD-ROM から ports をコンパイルする にしたがって ports をインストールしていました. kermit をインストールしようとするまではうまくいっていました:- &prompt.root; make install >> cku190.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://kermit.columbia.edu/kermit/archives/. なぜ cku190.tar.gz が見つからないのでしょうか? 不良品の CD-ROM を買ってしまったのでしょうか? A. Kermit の権利を持つチームは, 私たちの CDROM に kermit の tarball を 入れることを許可しませんでした. 申し分けありませんが, 手動でファイルを 入手してください. このようなエラーメッセージが出たのは, あなたがそのときインターネットに 接続していなかったためです. あらかじめ上記のサイトのいずれかからファイルを ダウンロードしておけば, プロセスを再開することができます. (ダウンロードの際には, あなたに最も近いサイトを選ぶようにしてください. そうすれば, 時間とインターネットの帯域の節約になります) Q. kermit の tarball を入手しましたが, /usr/ports/distfiles に ファイルを置こうとすると, 書き込み権がないというエラーがでます. A. ports のしくみは /usr/ports/distfiles から tarball を探します. しかし, これは read-only の CD-ROM へのシンボリックリンクなので, ここにファイルを置くことはできません. 次のようにすれば, 他の場所を探すよう ports に指示することができます. - &prompt.root; make DISTDIR=/where/you/put/it install + &prompt.root; make DISTDIR=/where/you/put/it install Q. ports では, すべてを /usr/ports に置いたときだけ動作するのでしょうか? システムの管理者によると, 私の個人的なファイルは /u/people/guests/wurzburger に入れなければならないのですが, これでは うまくいかないように思います. A. PORTSDIR 変数と PREFIX 変数を変更することで, 違うディレクトリを 使用することができます. 例えば, &prompt.root; make PORTSDIR=/u/people/guests/wurzburger/ports install とすると, ports は /u/people/guests/wurzburger/ports でコンパイルされ, すべて /usr/local 以下にインストールされます. &prompt.root; make PREFIX=/u/people/guests/wurzburger/local install この場合, コンパイルは /usr/ports でおこない, /u/people/guests/wurzburger/local にインストールします. もちろん, 以下のように両者を組み合わせることも可能です. &prompt.root; make PORTSDIR=.../ports PREFIX=.../local install (省略せずに記述したら, このページに収めるには長すぎるのですが, 考え方は理解していただけたと思います) もし ports をインストールするたびに, これらを毎回タイプするのが 気に入らないのであれば, (正直に言って, 誰もそう思わないでしょう) これらを環境変数にセットしてしまうという手があります. Q. 私は, FreeBSD の CD-ROM を持っていませんが, 私はすべての tarball を 私のシステムに置いておきたいのです. そうすれば, 私は ports をインストール するたびに, 毎回ダウンロードが終わるのを待たなくてすむでしょう. これを一度におこなう簡単な方法はありませんか? A. ports コレクション全体の tarball を持ってくるには, 次のようにしてください. &prompt.root; cd /usr/ports &prompt.root; make fetch ports の下のディレクトリひとつの tarball を持ってくるには, 次のように してください. - &prompt.root; cd /usr/ports/directory + &prompt.root; cd /usr/ports/directory &prompt.root; make fetch ports をひとつだけ持ってくる方法は, きっと既にご存知だと思います. Q. マスタ FTP サイトから tarball を持ってくるより, 近くにある FreeBSD の ミラーサイトから持ってきた方が速いはずです. MASTER_SITES に書かれている サイト以外から持ってくるように ports に指示する方法はありませんか? A. もちろんあります. 例えば ftp.FreeBSD.ORG が MASTER_SITES に書かれている サイトより近いとしたら, 以下のようにしてください. - &prompt.root; cd /usr/ports/directory + &prompt.root; cd /usr/ports/directory &prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/distfiles/ fetch Q. ダウンロードをする前に, どんなファイルが必要なのか知りたいのですが. A. make fetch-list とすると, ports に必要なファイルの一覧を表示できます. Q. ports のコンパイルを途中で止める方法はありますか? 私はインストールをする前に いろいろとソースコードを解析したいのですが, 毎回 control-C を打たなければならないのが少し面倒です. A. make extract を実行すると, ファイル転送とソースコードの展開まで おこなったところで停止します. Q. 自分で ports を作ろうとしています. 私の作ったパッチが 正しく処理できることを確認できるように, コンパイルを止めたいのです. パッチのための make extract のようなものはありませんか? A. あります. make patch があなたのお望みのものです. おそらく PATCH_DEBUG オプションも同様に お役に立つことでしょう. ところで, あなたの努力に感謝いたします!! Q. あるコンパイルオプションはバグの 原因になるという話を聞きました. 本当なのでしょうか? どうやったら正しい設定で ports をコンパイルできますか? A. 本当です. gcc の バージョン 2.6.3 (FreeBSDの 2.1.0 と 2.1.5 に付属している バージョン) では, オプションを オプションなしで 使うと, バグのあるコードを出力します (ほとんどの ports は オプションを 使いません). コンバイラオプションは次のように定義 すべき です. &prompt.root; make CFLAGS='-O2 -fno-strength-reduce' install これを /etc/make.conf に書いておくこともできますが, 残念なことに すべての ports がこの指定を尊重してくれる 訳ではありません. もっとも確実なのは make configure を実行し, ソースディレクトリの Makefile を見て手で修整することですが, ソースが 多くのサブディレクトリにわかれていて, 各々に Makefile がある場合は 大変な仕事になります. Q. ports がたくさんありすぎて, 私の欲しいものがなかなか見つけられません. どんな ports が使えるのか, リストはどこかにありませんか? A. /usr/ports の中にある INDEX ファイルを見てみましょう. あるキーワードで ports コレクションを検索したければ, それも可能です. たとえば, 以下のようにすればプログラミング言語 LISP に関連した ports を見つけることができます: &prompt.user; cd /usr/ports &prompt.user; make search key=lisp Q. foo ports をインストールしたいのですが, それのコンパイルは すぐに停止して, bar ports のコンパイルが始まってしまいます. 一体どうして? A. foo ports が, bar ports の提供する何らかの機能を必要としているからです. 例えば foo が画像を使うとすると, bar は画像処理に必要な ライブラリを持っている, などです. または, bar は foo をコンパイルするのに必要なツールなのかもしれません. Q. ports から grizzle プログラムをインストールしましたが, まったく ディスクスペースの浪費です. 削除したいのですが, すべてのファイルが どこへインストールされたのかわかりません. 何か手がかりはありませんか? A. 大丈夫, 次のようにしてください. &prompt.root; pkg_delete grizzle-6.5 Q. ちょっと待ってください. 削除しようとするコマンドのバージョン番号を 知っていなくてはならないのでしょうか? あなたは, 私がバージョン番号を 覚えていることを本気で当てにしているのでしょうか? A. そんなことはありません. バージョン番号は次のようにすればわかります. &prompt.root; pkg_info -a | grep grizzle Information for grizzle-6.5: grizzle-6.5 - the combined piano tutorial, LOGO interpreter and shoot 'em up arcade game. Q. ディスク容量のことなのですが, ports のディレクトリは非常に膨大な容量を 使うように見えます. 残しておいた方がよいのでしょうか? 削除してしまっても よいのでしょうか? A. はい. インストールが首尾よく終わり, もうソースコードが必要でないと思うなら, それらを残しておく理由はないでしょう. 一番よい方法は, 次の通りです. &prompt.root; cd /usr/ports &prompt.root; make clean これは, すべての ports のサブディレクトリを調べ, 各 ports のスケルトン以外の削除をおこないます. Q. これを試してみたのですが, tarball や ports で使われたファイルが distfiles ディレクトリに残っています. これも削除してしまっても大丈夫ですか? A. はい. それを使った作業が終わったのであれば, 削除してしまっても大丈夫です. Q. 私はとてもとてもたくさんのプログラムを楽しみたいのです. 一度にすべての ports をインストールする方法はありませんか? A. 次のようにしてください. &prompt.root; cd /usr/ports &prompt.root; make install Q. やってみました. 時間がとてもかかるだろうと思ったので, そのまま実行を 続けさせて, 私は寝ました. 翌朝コンピュータを見てみると, 三つ半の ports しか 処理が終わっていませんでした. なにか悪かったのでしょうか? A. これは ports の中には私たちの決められないこと (例えば, あなたが A4 の 用紙に印刷したいのか, US レターサイズの用紙に印刷したいのかなど) について 質問してくるものがあるからです. それらの質問には手動で答える必要があります. Q. 私は一日中モニタの前に座って過ごしたりしたくないのですが. 何かよいアイデアはありませんか? A. では, あなたが寝に / 仕事に / 公園にいく前に以下を実行してください:- &prompt.root; cd /usr/ports &prompt.root; make -DBATCH install これでユーザの入力を要求しないすべての ports をインストールします. そして, 戻ってきてから, 次のように実行してください. &prompt.root; cd /usr/ports &prompt.root; make -DIS_INTERACTIVE install そして, 残りの作業を実行してください. Q. 私たちは ports コレクションにある frobble を使っています. ですが, 私たちの必要に応じて ports を変更したところがあるのです. 自分でパッケージを作って, それを私たちのサイトのまわりに 簡単に配布できるような方法がありますか? A. もちろんあります. 変更点をパッチにする方法は知っていますよね:- - &prompt.root; cd /usr/ports/somewhere/frobble + &prompt.root; cd /usr/ports/somewhere/frobble &prompt.root; make extract &prompt.root; cd work/frobble-2.8 [あなたのパッチを当ててください] &prompt.root; cd ../.. &prompt.root; make package Q. この ports の技術は本当に賢いですね. どのようにして動いているのか 私はどうしても知りたいと思います. その秘密は何ですか? A. 秘密は一切ありません. Makefiles + URL="file://localhost/usr/ports/Mk/">Makefiles ディレクトリ にある bsd.ports.mk と bsd.ports.subdir.mk ファイルを見るだけです. 複雑なシェルスクリプトを嫌う読者は, このリンクを追いかけないほうが よいでしょう. 自分で port を作る 原作: &a.jkh;, &a.gpalmer;, &a.asami;, &a.obrien; and &a.hoek;. 28 August 1996. 訳: &a.jp.simokawa;, &a.asami;. 10 November 1996. 自分で port を作ることに興味がありますか, すばらしい! これから, FreeBSD 用のportを作る際の, いくつかのガイドラインを 説明します. 実際にportをコンパイルするときのほとんどの仕事は - /usr/share/mk/bsd.port.mk + /usr/ports/Mk/bsd.port.mk というファイルでおこないます. Portsコレクションについてのさらに細かい内部の働きについては, そちらの ファイルを参照してください. これにはコメントが細かく書いてありますので, Makefile を読むのにあまり慣れていない人でも, 得るものはとても大きいで しょう. ここでは, 変更可能な変数の一部についてのみ記述しています. ほとんどの変数はbsd.port.mk の始めに記述があります. また, このファイルは非標準のタブの設定になっています. Emacs や Vim はファイルのロード時にこれを認識しますが, viやexでは, ファイルをロードしたら :set tabstop=4 のようにして正しい値を設定する ことができます. 3分porting この節では, 簡単なportの方法について説明します. 多くの場合これ では不十分ですが, まあうまくいくかどうか試してみて損はないでしょ う. まず, 元のtarファイルをDISTDIRに置きます. デフォルトは/usr/ports/distfilesです. 以下では, ソフトウェアはそのままコンパイルされるとします. つまり, FreeBSDのマシンで動かすために, 変更がまったく必要ない とします. もしなにか変更が必要な場合には次の節も参照する必要 があります. <filename>Makefile</filename> の作成 最小限のMakefile は次のようなものです: # New ports collection makefile for: oneko # Version required: 1.1b # Date created: 5 December 1994 # Whom: asami # # $Id$ # DISTNAME= oneko-1.1b CATEGORIES= games MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ MAINTAINER= asami@FreeBSD.ORG MAN1= oneko.1 MANCOMPRESSED= yes USE_IMAKE= yes .include <bsd.port.mk> おわかりになりますでしょうか. $Id$があ る行の内容については, 気にしないでください. これはこのファイル がportsツリーに書き込まれるときにCVSによって自動的に書 き込まれます. もっと詳しい例が見たければ, Makefileのお手本 の節をご覧ください. Package記述ファイルの作成 どのようなportでも, packageにするしないに関わらず, 3つ の記述ファイルが必要です. pkgサブディレクトリにある, COMMENT, DESCR, それに PLISTです. <filename>COMMENT</filename> これには, そのportについての説明を1行で書きます. Package の名前, バージョン番号等は 含めないでください. たとえば, こんな具合です: A cat chasing a mouse all over the screen. <filename>DESCR</filename> これは, そのソフトウェアについての, すこし長い説明を記述します. その port が何をするのかについての数段落程度の 簡潔な解説があれば十分です. このファイルはマニュアルでもなければ, 使用方法やコンパイル方法についての細かい 説明書でもありません. 特に, READMEファイル manpage をコピーしようとしてしている場合には 注意してください. これらは多くの場合, そのポートの簡潔な説明に なっていなかったり, 扱いにくい形式(manpage の場合, 行を揃えるために空白が調整されます)になっていたりします. もしこのソフトウエアに公式の WWW のホームページがあれば, - ここに書いて下さい. + ここに書いて下さい. 自動化ツールが正しく動作するように, + Web サイトのうちの ひとつ には, 前に + WWW: を付け加えてください. このファイルの最後にあなたの名前を書くことが 推奨されています. たとえば, こんな具合です. This is a port of oneko, in which a cat chases a poor mouse all over the screen. : (うんぬん.) -http://www.oneko.org/ +WWW: http://www.oneko.org/ - Satoshi asami@cs.berkeley.edu <filename>PLIST</filename> このファイルには, このportによってインストールされるファ イルが列挙されます. このファイルはpackageを作る際のリス トとして使われるため, `packing list' とも呼ばれます. ここ に書かれているファイル名は, インストール時のプレフィックス (普通は /usr/local か /usr/X11R6) からの 相対パスです. MANn 変数を使用する場合(使用することが推奨されています)には, マニュアルはここに入れないでください. 簡単な例を載せておきましょう: bin/oneko lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpm @dirrm lib/X11/oneko 'Packing list'の詳細については, &man.pkg.create.1; の マニュアルを参照してください. すべてファイルを列挙しなければなりませんが, ディレクトリ名は必要ありません. また, ports がインストール時にディレクトリを作成する場合には, @dirrm の行を加えて, その port が削除されるとき, そのディレクトリも削除されるようにしてください. このファイルには, ファイル名をアルファベット順に並べるようにしてください. port のアップグレートのとき, 楽に確認ができるようになります. チェックサムファイルの作成 ただ, make makesum と入力するだけです. bsd.port.mk にルールがあるので, 自動的にfiles/md5が生成されます. Portのテスト そのportが正しく動くことを, package化を含めて確認してください. 以下の重要なポイントを確認してください. PLIST にその port がインストールしないものが含まれていないこと. PLIST にその port がインストールする全てのものが含まれていること. reinstall ターゲットを使うことによって, 何度でもインストールが可能こと. deintall の際に 後片付け をすること. 推奨されるテストの手順 make install make package make deinstall pkg_add `make package-name` make deinstall make reinstall make package package および deinstall の段階で, どんな警告(warning)も出力されないことを確認してください. ステップ3の後, 新しいディレクトリが全て正しく消去されているかを 確認してください. また, ステップ4の後にそのソフトウェアを使用してみて, package からインストールされた場合に正しく動作するかを 確認してください. <command>portlint</command> でチェック portlintを使って, あなたの port が我々のガイドラインそっているかを確認してください. portlint プログラムは ports コレクションに含まれています. 特に, Makefile が正しい形式になっているか, package の名前が正しいか, をチェックするのに良いでしょう. Portの送付 まず, やってよいことといけないこと についての節を読んでください. さあ, あなたのportに満足したら, あとはそれをFreeBSDのメイ ンのportsツリーに置いて, 皆に使ってもらうだけです. いまある work ディレクトリや pkgname.tgz パッケージは必要ありませんから, まず消去してください. あとは, バグレポートの中に shar `find port_dir` の出力を, &man.send-pr.1; プログラムを使用して送ってください. &man.send-pr.1; についての詳細は, バグ報告と一般的な論評 を参照してください.) もし, 圧縮していない状態で, 20KB以上あるようなポートであれば, 圧縮して tar ファイルにして, バグレポートに入れる前に &man.uuencode.1; を使用してください. (20KB以下のものでも, tar ファイルにして送ってもよいですが, あまり歓迎されません). バクレポートの category は ports, class は change-requestを必ず使用してください. (レポートを confidential (内密) にしないようにしてください!) もう一度, オリジナルのソースファイル, work ディレクトリ, make package で作成したパッケージが含まれていないこと を確認してください. 以前, 新しい port をわれわれの ftp サイト (ftp.freebsd.org) にアップロードするようにお願いしたことがありますが, 現在このサイトの incoming ディレクトリは読み出し不可になっており, いまでは推奨されていません. 沢山の海賊版ソフトウェアがそこに置かれたためです. 私たちは, 何か不明な点があったらあなたに確認したのち, それをツリーへ置きます. あなたの名前は, FreeBSD ハンドブックやその他のファイルの “Additional FreeBSD contributors” のリストにも載るでしょう. う〜ん, 素晴らし い. :) 本格的なport 残念ながら, 移植がそう簡単ではなく, 動かすために多少の変更が 必要な場合も多いでしょう. この節では, portsコレクション の方法論にのっとって, そのような場合にどのように変更を施し, 動 くようにしたらよいかを順を追って説明します. port構築の詳細 まず, あなたがportのディレクトリで make とタイ プしてから起こる一連の出来事について,順を追って説明しま す. ここを読むときには, 他のウィンドウで同時に bsd.port.mk も開いておくとよいかもしれません. しかし, bsd.port.mkが何をしているのか, 完全に理解 できなくても心配する必要はありません. そう多くの人が理解して いるわけではないですから... f(^_^;) まず, fetch というターゲットが実行されます. このfetchターゲットは ローカルディスクのDISTDIRに配布ファ イルがあるようにするのが役目です. もし, fetchが必要なファ イルをDISTDIRに見つけることが できなけ れば, Makefileに指定されているURL MASTER_SITES, そして私たちのFTPサイトで ある ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/ (ここ には, 私たちが取ってきたファイルを バックアップとして置いてあ ります) に探しにいきます. そして, ユーザのサイトがインター ネットに 直接接続されている場合には, FETCH を使って, その名前のファイルを取っ てきて, DISTDIRに保存します. 次に実行されるのは extract ターゲットです. これは, DISTDIRにある, 配布ファイル (普通は gzipされたtarファイル) を読み, ソースを一時的な作業ディレ クトリWRKDIR (デフォルトは work) に展開します. 次に, patch というターゲットが実行されます. まず, PATCHFILESに定義されている, すべてのパッ チをあてます. 次にもしPATCHDIR (デフォ ルトは patches サブディレクトリ) にパッチが存在す れば, これらをアルファベット順にあてます. 次に実行されるターゲットは configureです. これには, い ろいろな場合があります. もし存在すれば, scripts/configure が実行されます. もし, HAS_CONFIGURE あるいは GNU_CONFIGURE がセットされていれば, WRKSRC/configure が実行されます. もし, USE_IMAKE がセットされていれば, XMKMF (デフォルト: xmkmf -a) が実行されます. 最後に, build というターゲットが実行されます. これは, その port の専用の作業ディレクトリ (WRKSRC) にい き, コンパイルするのが役目です. もし USE_GMAKE がセットされていれば, GNU make が使用されます. さもなければFreeBSDの make が使用されます. 上記はデフォルトのルールです. さらに, pre-何とか や post-何とか というターゲット が定義してあった り,そのような名前のスクリプトが scripts サブディレクトリに置いてある場合には, それらはデフォルトの動作の前 後に実行されます. たとえば, post-extract というターゲットがMakefile で定義されていて, pre-build というファイルが, scripts サブディレクトリにあるとすると, post-extractターゲットは, 通常の展開動作のあとに呼 び出され, pre-build スクリプトはデフォルトのコンパイ ルのルールが実行される前に実行されます. もし動作が簡単であれ ば, Makefile のターゲットを使用することが推奨されています. な ぜならば, そのportが何らかのデフォルトではない動作を必要とす るのかどうかが一箇所にまとめて書いてあった方が他の人に 理解しやす いからです. デフォルトの動作は bsd.port.mk の do- 何とか というターゲットでおこなわれます. たとえば, portを展開するコマンドは, do-extract というターゲットにあります. もし, デフォルトのターゲットに 不満があれば, do- something というターゲッ トを再定義することによって, どのようにでも直すことができます. “メイン”のターゲット (例えば, extract, configure等) は, すべての前段階が実行されていること を確認して, 実際のターゲットやスクリプトを呼び出す以外のこと はしません. bsd.port.mkはこれらが変更されることは仮定してい ませんので, もし, 例えば, 展開の仕方を直したいときには, do-extract を直し, 絶対にextractには手を 触れないでください. これで, ユーザが make と入力したときに何が起こ るのかが理解できたと思います. では, 完璧なportを手順を追っ て作ってみましょう. オリジナルのソースの入手 オリジナルのソースを, (普通は) 圧縮されたtarファイルの形 ( foo.tar.gz あるいは foo.tar.Z) で入手して, それを DISTDIR にコピーします. 可能なかぎり, 広 く使われている主流の ソースを使用するようにしてください. もし, ネットワークへの接続のよい FTP/HTTP サイトを見つけるこ とができなかったり, 頭にくるような非標準的な形式しか持ってい ないサイトしか見つけられないときには, 自分で管理する確実な ftp か http サーバ (たとえば, あなたのホームページ)に置くこと ができます. MASTER_SITES に正しく反映されていることを確認してください. もしも, そのような都合の良く, 安心な置き場所が見つけられない 場合(あなたが FreeBSD の committer であれば, 自分の public_html ディレクトリに置けます), 私たちが, ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/distfiles/LOCAL_PORTS/ に置き場所を提供できます. この場所は, 変数 MASTER_SITE_LOCAL を使って参照してください. これについての問い合わせのメールは &a.ports へお願いします. その port の配布ファイルが特に理由もなく, しょっちゅう変る場合には, 配布ファイルをあなたのホームページに置いて MASTER_SITESの最初に入れてください. こうすることによって, ユーザ利用する場合に checksum mismatch エラーが起るのを防ぎ, 我々の ftp サイトの保守の負担を減らすことができます. もし, master site がたった一つしかない場合には, あなたのサイトにバックアップを置いて MASTER_SITES の2番目に加えてください. もし, あなたのportに必要ないくつかの追加パッチがインター ネット上で手に入るのならば, それらも取ってきて, DISTDIR に置きます. もし, それらがメイン のソースのtarファイルとは別のサイトにあっても, 心配する必要 はありません. そのような状況にはちゃんと対応できるようになっ ています. (以下のPATCHFILESの記述 をご覧ください). Portの修正 適当なディレクトリにtarファイルを展開して, FreeBSDの最新の バージョン上で, 正しくコンパイルできるために必要なあらゆる変 更を施します. 最終的に処理は自動化するわけですから, 何をおこなっ たかを注意深く記録しておきましょう. あなたのport が完成した暁には, ファイルの削除, 追加, 修正を含むすべての処 理が, 自動化されたスクリプトやパッチファイルで おこなえるようになっ ていないといけません. もし, あなたの port のコンパイルやインストールのために必要 な手作業があまりに多いようならば, Larry Wall の模範的な Configure スクリプトでも参考にしたほうがいいかもしれませ ん. 新しいportsコレクションは, 最小のディスクスペースで, 個々のportがエンドユーザにできるだけ“プラグ & プレ イ”の状態でmakeできることをめざしています. あなたが作成し FreeBSD の ports に寄付されたパッチファイル, スクリプトおよびその他のファイルは, 明示的に記述されている場合 を除いては, BSDの標準的な著作権条件によりカバーされていると見な されます. パッチをあてる port の過程で追加されたり変更されたファイルは再帰的diffで変 更点を取り出すことができます. パッチは適当にまとめて, patch-xx という名前のファイルに入れてくだ さい. xx はパッチが適用される順番を示します — これらは, アルファベット順, つまり aa が 最初, つぎに ab などとなります. これらのファイル をPATCHDIRに置いておくと, 自動的に適用さ れるようになっています. すべてのパッチは WRKSRC (通常は, portのtarファイルが展 開されるところで, makeが実行されるところと同じです) からの相 対パスになります. 修正やアップグレードを容易にするため, 2つ 以上のパッチが同じファイルを修正するのは避けてください. (例, patch-aaとpatch-abが共にWRKSRC/foobar.c を修正する, など.) コンフィグレーション カスタマイズのために追加したいコマンドがあれば, configure という名前のスクリプトに入れて scripts サブディレクトリに置きます. 上で述べたよ うに, pre-configure あるいは post-configure という Makefile のターゲットおよび/あるいはスクリプトで処理す ることもできます. ユーザからの入力の扱い もし, そのportがビルド, コンフィグレーション, インストー ルの際にユーザからの入力を必要とするならば, Makefileで IS_INTERACTIVEをセットしてください. これによって, 深夜, 自動的にたくさんのportをコンパイルすることが可能にな ります. 環境変数BATCHがセットされていると IS_INTERACTIVE の定義されているportはスキップされ ます (そして, ユーザがINTERACTIVEという変数をセッ トすると入力を必要とする port のみコンパイルされま す). もし, 適切なデフォルト設定があるのであれば, PACKAGE_BUILDING 変数をチェックして,それが設 定されて いる場合には, ユーザ入力のスクリプトを起動しないように してください. こうすることによって, CD-ROM や ftp に 置く packageを我々が作成することができます. Makefileの作成 Makefileの作成は非常に単純です. 繰り返しになりますが, 始める まえに, すでにある例を見てみることをお奨めします. またこのハ ンドブックにはMakefileのお手本 があります. それを見て, Makefile内の変数の順番や空行を入れると ころなどの参考にしてください. そうすると他の人々にも読みやすい ものとなります. では, Makefileをデザインするときに問題となるところを順に追っ て見てみましょう. オリジナルのソース ソースはDISTDIRに, 標準的なgzipされた tarファイルとして置かれていますか? そうであれば, 次のステッ プに進めます. そうでなければ, 変数 EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX, DISTFILES を適当に書き換えないといけません. どれだけ変更しないといけないかは, あなたのportの 配布ファイルがどの程度標準からかけはなれているかによりま す. (最もよくある場合は, gzipではなく普通のcompressコマンド でtarファイルが圧縮されている場合で, EXTRACT_SUFX=.tar.Z とするだけです.) 最悪の場合には, 自分で do-extract ターゲットを作 成して, デフォルトを上書きすることもできます. しかし, そこま でする必要があることはめったにないでしょう. <makevar>DISTNAME</makevar> DISTNAME には port の名前の基幹部分を入れ ます. デフォルトのルールでは, 配布ファイルのリスト (DISTFILES) は DISTNAME EXTRACT_SUFX という名前 になっています. 例えば, foozolix-1.0.tar.gzの場 合, 通常のtarファイルだと, DISTNAME=foozolix-1.0 のようになります. さらにデフォルトのルールでは, tarファイルは work/DISTNAME というサブディレクトリ に展開されることを仮定しています, 例えば work/foozolix-1.0/ といった具合いです. これらの動作はもちろんすべて変更可能です. デフォルトのルー ルは最も標準的な場合を仮定しているだけです. まず, port が複 数の配布ファイルを必要とするときには, 単に明示的に DISTFILESを設定してください. もし, DISTFILES の一部だけが実際に展開される場合 には, それらをEXTRACT_ONLY に設定してくだ さい. この変数が定義されている場合には, 展開時に DISTFILESに優先して利用されます. 残りのファ イルもDISTDIRに取ってきますが, 展開時に はなにもせずに後で使うためにそのまま置いておかれます. <makevar>PKGNAME</makevar> もし, DISTNAME が我々の package の名前についてのガイドライン に沿ったものでない場合には, PKGNAME にもっと良い名前を設定してください. 詳細は上記のガイドラインを参照してください. <makevar>CATEGORIES</makevar> (分類) 完成した package の実体は /usr/ports/packages/All に置かれます. また, 1つかそれ以上の /usr/ports/packages のサブディレクトリからのシンボリッ クリンクが作られます. それらのサブディレクトリの名前が CATEGORIES という変数によって指定されます. これは, ユーザがFTPサイトやCD-ROMのpackageの山を渡り歩 くことを容易にするためです. 現在存在する カテゴリを見て, そ のportに適したもを選んでください. このリストは, この port が port tree のどこに import されるかも決定します. 2つ以上のカテゴリを指定した場合には 最初のカテゴリで指定されるサブディレクトリに置かれること になります. 適切なカテゴリを選ぶ方法については, カテゴリ の節を参照してください. もしその port が本当に現在存在するすべてのものとは異なって いる場合には, 新しいカテゴリ名を作ることもできます. その際には, &a.ports 宛てに新しいカテゴリ名を提案する メールを送ってください. カテゴリ名については, なんのエラーチェックも行なわれません.ミスタイプがあっても make package はなにも考えずに 新しいディレクトリを作ってしまいますので, 注意してください. <makevar>MASTER_SITES</makevar> オリジナルの配布ファイルを指し示す FTP または HTTP の URL のディ レクトリ部分までを MASTER_SITES に記録しま す. スラッシュ (/) を最後につけることをお忘れなく. 配布ファイルがシステム上に存在しないときに, makeマクロは FETCH でこの変数に指定されたサイトから取っ てきます. 複数の, できれば異なる大陸のサイトをこのリストに入れておく ことが推奨されています. これによって, 広域ネットワークにトラ ブルがあった場合でも成功する可能性が高くなります. 私たちはさら に, 自動的に最も近いマスタサイトを検出して, そこから取って くるメカニズムの導入を計画しています. オリジナルのtar ファイルが, X-contrib, GNU, Perl CPAN, TeX CTAN または Linux Sunsite などの有名なアーカイブにある場合には, MASTER_SITE_XCONTRIB, MASTER_SITE_GNU, MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN および MASTER_SITE_SUNSITE を利用することで, 簡単にこれらのサイトを 指定することができます. あとは MASTER_SITE_SUBDIR にアーカイ ブ内でのパスを指定するだけです. 以下に例を示します. MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications ユーザは/etc/make.conf中で MASTER_SITE_* 変数を設定 することによって, デフォルトの FTP サイトではなく, これらの 有名なアーカイブの ミラーの中で好みのものを使用することが可能 です. <makevar>PATCHFILES</makevar> もし, オリジナルの配布ファイル以外にもFTPかHTTPで手に入る パッチが必要な場合には, PATCHFILESにファ イル名を, PATCH_SITESにサイトとディレクト リの名前を MASTER_SITES と同様に設定してく ださい. そのパッチ内のファイル名ががソースツリーの 一番上のディレク トリ (WKRSRC) からの相対パスになっていな い場合には, PATCH_DIST_STRIPを指定してく ださい. 例えば, パッチ内のファイル名にすべて余計な foozolix-1.0/ がついている場合には, PATCH_DIST_STRIP=-p1としてください. これらのパッチは圧縮されていても大丈夫です. ファイル名が .gz か .Z で終わる場合には自動的に復元 されるようになっています. もしパッチが, 文書などその他のファイルと一緒に gzip された tarファイルで配布されている場合には，単純に PATCHFILES を使うことはできません. このような場合には, このパッチの tar ファイルの名前と場所を DISTFILES と MASTER_SITES に加えます. それから, pre-patch ターゲットで, パッチコマンドを走らせるか, パッチファイルを PATCHDIR ディレクトリに patch-xx という名前でコピーするかして, パッチを適用するようにします． 普通の gzip か compress された tar ファイルであれば, 通常のソースファイルと一緒にその時までに 展開されていますので, 明示的に展開する必要はありません. もし, 後者の方法を使用する場合には, すでにそのディレクトリにある なにかを上書きしないように, 注意する必要があります. さらに, pre-clean ターゲットにコピーしたパッチファイル を削除するコマンドを追加するのを忘れないでください. <makevar>MAINTAINER</makevar> あなたのメールアドレスをここに入れてください. お願いします. :) 保守担当者(maintainer)の責任についての詳細は， Makefile 中の MAINTAINER の節をご覧ください． 依存関係 このプログラムが他のportに依存する場合には, 必要なものが 自動的に作られるようにすることができます. そのために, 以下の 5つの変数が用意されています. よくあるケースのためにあらかじめ設定された依存変数や, いくつかの依存関係の制御のための変数があります. <makevar>LIB_DEPENDS</makevar> Port が必要とする非標準の共有ライブラリを この変数で指定 します. これは lib: dir: target という組のリストで, うち lib が共有ライブラリの名前, そして dir がそのライブラリが見つからない場合にインストールする port のあるディレクトリで, target はそのディレクトリで呼ばれるターゲットです. 例えば, LIB_DEPENDS= jpeg.9:${PORTSDIR}/graphics/jpeg:install と指定してあれば, まずメジャーバージョンが9のjpegライブ ラリがあるかどうか確認し, ない場合にはportsツリーの中の graphics/jpeg というサブディレクトリに移動し, そこ でコンパイルとインストールを行ないます. target の 部分は, DEPENDS_TARGET (デフォルトは install) と等しいときには省略できます. 前半の lib 部分は ldconfig -r | grep -wF への引数になります. この変数には正規表現を入れられません. この依存関係は2度チェックされます. まず extract ターゲットで, 次に install でチェックされます. (これは, その port を作成するマシンとインストールする マシンが違う場合でも, きちんとそのライブラリが利用できる ことを確認するためです.) また, 依存するもの名前は package の中にも含まれますので, ユーザのシステムに存在しなければ, pkg_add が自動的にインストールします. <makevar>RUN_DEPENDS</makevar> Port を使用する際に必要となるファイルまたはプログラムがある ときにはこの変数で指定します. これは path: dir :target とい う組のリストで, path がファイルまたはプログラムの 名前, そして dir がそれが見つからない場合に作成する ためのディレクトリ名で target はそのディレクトリで呼ばれるターゲットです. path の最初の文字がスラッ シュ (/) の場合にはファイルかディレクトリ とみなし, その存在を test -e でチェックします; そうでない場合には 実行可能であると仮定し, which -s を使って そのプログラムがユーザのサーチパス上に あるかどうか確認します. 例えばMakefileに以下のように書いてあるとします. RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \ wish8.0:${PORTSDIR}/x11-toolkits/tk80 まず, /usr/local/etc/innd というファイルかディレクトリが存在 するか確認し, ない場合にはportsツリーの中の news/inn というサブディレクトリから作られます. ま た, wish8.0 というプログラムがユーザのサーチパス中 にあるかどうか探し, ない場合には同じくportsツリーの x11-toolkits/tk80 というサブディレクトリから作られます. この例で, innd は実際にはプログラムです; この ように, プログラムであっても標準のサーチパス以外のところに あるようなものの場合には, 絶対パスで指定してください. この依存関係はinstall ステージのはじめでチェック されます. また, packageを作る際に必要となるportのpackage名 が記録され, pkg_addを使用すると ユーザのシステムに存在しない場合には自動的にそちら のpackageもインストールされるようになります. target の部分は, DEPENdS_TARGET と同じ場合には省略可能です. <makevar>BUILD_DEPENDS</makevar> Port のコンパイルに必要なファイルまたはプログラムがある ときは, この変数で指定してください. RUN_DEPENDSと同 様に, これは path: dir :target という組のリストです. 例 えば, BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip は unzip という名前のプログラムを探し, 見つから ない場合にはarchivers/unzip サブディレクトリで作 れという意味になります. ここでは “コンパイル” と一口にいいましたが, この変数は実際 にはファイルの展開から実際のコンパイル・リンクまで 全部をま とめて面倒を見てくれます. この依存関係は extract ステージからチェックされます. target の部分は DEPENDS_TARGET と同じ場合には省略可能です. <makevar>FETCH_DEPENDS</makevar> この変数は, portを取ってくるのに必要なファイルまたはプロ グラムを指定するのに使います. 上の二つと同様に, これは path: dir :target という組のリストです. 例えば, FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2 としておけば, ncftp2 という名前のプログラムを探 し, 見つからない場合にはnet/ncftp2 サブディレク トリにいってインストールします. この依存関係は fetch ステージからチェックされます. target の部分は DEPENDS_TARGET と同じ場合には省略可能です. <makevar>DEPENDS</makevar> 上記の四つのいずれにもあてはまらないような 依存関係がある場 合, または他の port がインストールされれているだけではなく, ソースが展開されている必要がある場合にはこの変数 を使います. これは dir :target という形式のリスト になります. 上記の四つと違って特に “確認”するものがありませんので. よくある依存関係を表す変数 もし ports が X Window System を必要とするのであれば, USE_XLIB=yes を定義してください. (これは USE_IMAKEも意味します) BSD make の代りに GNU make を必要とする場合には, USE_GMAKE=yes を定義. 動作するのに GNU autoconf を必要とする場合には, USE_AUTOCONF=yes を定義. 最新の qt toolkit を使用 する場合には USE_QT=yes を定義. perl 言語のバージョン5 を必要とする場合には, USE_PERL5=yes を定義してください. (特に最後のは重要で, FreeBSD のいくつかの バージョンでは基本システムに perl5 を含みますが, 他のものは含んでいません.) 依存関係に関する注意 上で述べたように, 依存する ports が必要になったときに呼ばれるデフォルトのターゲットは DEPENDS_TARGET で, そのデフォルトは install です. これは, ユーザの使用する変数で, port の Makefile で定義されるものではありません. もし, あなたのportが特別な方法で, 依存関係を扱う必要が ある場合には, DEPENDS_TARGET を再定義するのではなく, *_DEPENDS 変数の :target の部分を利用してください. make clean とタイプしたときには, 依存する port も自動的に clean されます. もしそうしたくない場合には, NOCLEANDEPENDS を環境変数として設定してください. 無条件に他の port に依存させるには, 特別に nonexistent という文字列を BUILD_DEPENDS あるいは RUN_DEPENDS の最初のフィールドに使用してください. これは, 他の port のソースが必要なときのみ使用してください. target も指定することによって, コンパイルの時間を節約することができます. 例えば, BUILD_DEPENDS= /nonexistent:${PORTSDIR}/graphics/jpeg:extract これは, 常に JPEG port の directory に行きソースの展開を行ないます. あなたがやりたいことが他の方法ではできない場合以外は, DEPENDS を使わないでください. これは常に 他の port の作成を行い(さらにデフォルトでインストール を行い), package も作成します. もし本当にこれがあなたの やりたいことでしたら, 代りにこれを BUILD_DEPENDS と RUN_DEPENDS で書くことをお勧めします — 少なくとも意図が明確になります. コンパイル時の特別な指定 GNUのmakeを使う場合には, USE_GMAKE=yes と指定してください. Port に GNU の configure が含まれ ている場合には, GNU_CONFIGURE=yes を使います(これは, HAS_CONFIGURE も意味します). configure に追加の引数 (デフォルトでは, GNU の configure では --prefix=${PREFIX}, GNUでない configure では空) を渡したい場合には追加部分を CONFIGURE_ARGS で指定してください. そのパッケージが autoconf を使用する場合には, USE_AUTOCONF=yes を使います. これは, GNU_CONFIGURE も意味し, configure の前に autoconf を実行します. X Window Systemのアプリケーションなど, imakeを 使って Imakefile から Makefile を作成するportの場合には USE_IMAKE=yes を指定してください. コンフィグレー ションステージで自動的にxmkmf -a が実行されます. も し フラグが問題をもたらすなら, さらに XMKMF=xmkmfとしてください. もし, port が imake を使用するけれども, install.man ターゲットがない場合には, NO_INSTALL_MANPAGES=yes を指定してください. ついでに, その port のオリジナルの作者を探し出して八つ裂きにすると いいでしょう.:> Portの Makefile が all 以外のものをメインのター ゲットとしている場合には, ALL_TARGET でそ れを指定してください. install と INSTALL_TARGET も同様です. もし, port の元の Makefile が all 以外のターゲットをメインのターゲットとしている場合には, ALL_TARGET をそれに合わせて設定してください. install と INSTALL_TARGET についても同様です. <makevar>NO_INSTALL_MANPAGES</makevar> あなたの port がimakeは使うものの install.man ターゲットを持っていない場合, NO_INSTALL_MANPAGES=yes を指定してください. つい でに, 作者を探し出して八つ裂きにするといいでしょ う. (-_-#) 特別な配慮 Portを作成する場合, 考慮しなくてはいけないことがさらにいくつかあります. この節では, それらのうちもっともありがちなものについて説明します. ldconfig 共有ライブラリをインストールするときには, 共有ライブラリのキャッシュを更新するために port の Makefile の post-installtarget から${LDCONFIG} -m を走らせてください. このコマンドの引数は共有ライブラリのインストールしてある ディレクトリ (通常 PREFIX/lib) です. また, pkg/PLIST に @exec /sbin/ldconfig -m と @unexec /sbin/ldconfig -R の組を入れて, package をインストールした場合にも共有ライブラリがすぐ使え, 削除の際にも, システムがまだライブラリが存在すると 誤認しないようにしてください. この行は共有ライブラリを指定する行のすぐ後に 書くのがよいでしょう: lib/libtvl80.so.1 @exec /sbin/ldconfig -m %D/lib @unexec /sbin/ldconfig -R 絶対に引数なしでただ ldconfig とだけ書いてある行を Makefile や pkg/PLIST ファイルに入れないでください. このコマンドを実行すると, 共有ライブラリのキャッシュが /usr/lib の内容のみとなり, ユーザのマシンにさまざまな問題をもたらします (「ぎゃぁ! このportをインストールしたら xinit が使えなくなっちゃった!」). この掟を破った者は, 永久に地獄の底で苦しみ続けるように, 閻魔様に頼んでおきます. ELF 対応 FreeBSD は 3.0-RELEASE で ELF に移行しましたので, シェアードライブラリを作成するたくさんの port を ELF 対応 にする必要があります. 3.0 システムは ELF としても a.out としてmも 動作しますし, 我々は非公式ではありますが, できるだけ長い間 2.2 システムのサポートをしたいと思っていますので, 複雑な状況です. 以下は a.out のみに対応している port をどのように a.out と ELF 両方に対応させるかのガイドライ ンです. このリストの一部は, 移行時にしかあてはまらないものもありますが, 古い port をアップグレードしたい場合に参考になるように, しばらくのあいだは残しておきます. a.out ライブラリの退避 a.out ライブラリは, /usr/local/lib から, aout サブディレクトリ に移動しなくはなりません. (もし移動しないと, ELF ports がそれらをあっさり上書きして しまいます.) 3.0-CURRENT の src/Makefile にある move-aout-libs ターゲット (aout-to-elf から呼ばれます) がその移動をしてくれます. a.out ライブラリを移動するだけなので, ELF と a.out の両方のライブラリが標準的な ディレクトリにあるシステムでは, このターゲットを実行しても安全です. フォーマット port ツリーは package をそのマシンのフォーマットで作成します. つまり, 2.2 では a.out, また 3.0 では `objformat` の結果によって, a.out か ELF になります. また, いったん a.out ライブラリをサブディレクトリに移動すると a.out ライブラリの作成はサポートされません. (つまり, あなたがにをすれば良いのかを理解しているのならば, うまく作成できるかもしれませんが, 自力でやらなければならないということです) もし port が aout でしか動作しないのなら, BROKEN_ELF に原因を説明する文字列を設定してください. この変数が設定された port は, ELF システム上でのビルドの際スキップされます. PORTOBJFORMAT bsd.port.mk において PORTOBJFORMAT は aout か elf に設定され, 環境変数 CONFIGURE_ENV, SCRIPTS_ENV, MAKE_ENV の中で export されます. (2.2-STABLE では常に aout になります). また, PORTOBJFORMAT=${PORTOBJFORMAT} として PLIST_SUB に渡されます. (以下にある ldconfig に関するコメントを参照して下さい.) この変数は, 以下のようにして bsd.port.mk 中で設定されます. PORTOBJFORMAT!= test -x /usr/bin/objformat && /usr/bin/objformat || echo aout この変数を使って, port の make の過程で何をすべきかを決定すべきですが, もし port の configure スクリプトが元々, ELF システムを自動的に検出するのであれば, PORTOBJFORMAT を参照する必要はありません. 共有ライブラリの作成 以下は, a.out と ELF での共有ライブラリの扱いの違いです. 共有ライブラリのバージョン ELF の共有ライブラリは, libfoo.so.M という名前になっていなければなりません. ここで M は単一の バージョン番号を表します. 一方 a.out のライブラリは libfoo.so.M. N という名前で, M はメジャーバージョン番号, N はマイナーバージョン番号になっている必要があります. これらを混同しないでください. libfoo.so.N. M という名のELF 共有ライブラリや libfoo.so.N という名の a.out 共有ライブラリ (あるいはシンボリックリンク) は 絶対にinstallしないでください. リンカコマンドライン 直接 ld を使用せずに, cc -shared を使用してください. たった一つの違いは, ELF には, コマンドラインにを加える必要があることです. ELF のリンカを満足させるためには, libfoo.so から libfoo.so.N へのシンボリックリンクを作る必要があります. これは, PLIST にも加えなくては いけませんし, a.out の場合でも害にはならないので (一部の port ではダイナミックリンクローディングのために 必要でもあります), PORTOBJFORMAT の設定を気にせずに, ただ単純にリンクを作成してください. <makevar>LIB_DEPENDS</makevar> すべての port の Makefile を編集して, LIB_DEPENDS からマイナー番号を除去する必要があり, 正規表現のサポートも除去する必要があります. (例えば, foo\\.1\\.\\(33|40\\) から foo.2) マッチングは grep -wF を使って行われます. <filename>PLIST</filename> PLIST は, a.out のマイナー番号が0であれば, 短い (ELFの) 共有ライブラリの名前を含み, さもなくば長い (a.outの) 名前を含んでいる必要があります. bsd.port.mk は 自動的に, PORTOBJFORMAT が aout であれば, .0 を 短い共有ライブラリの名前の行に付け加え, PORTOBJFORMAT が elf であれば, マイナー番号を 長い共有ライブラリの名前から削除します. ELF システムで 2 つのバージョン番号を持つ共有ライブラリを インストールしたり, aout システムで 1 つのバージョン番号しか持たない共有ライブラリを インストールするのが避けられない場合 (例えば他のオペレーティングシステム用の 互換ライブラリをインストールする port など), NO_FILTER_SHLIBS 変数を定義すれば, 前節で説明されている PLIST 編集の機能が停止されます. <literal>ldconfig</literal> Makefile 中の ldconfig の行は以下のようになります. ${SETENV} OBJFORMAT=${PORTOBJFORMAT} ${LDCONFIG} -m .... また PLIST 中では: @exec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -m ... @unexec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -R となります. これは, システムのデフォルトフォーマットではなく パッケージのフォーマットに応じて, 正しい ldconfig が呼ばれることを保証するためのものです. <makevar>MASTERDIR</makevar> もし, あなたの port が 変数(例えば 解像度とか紙のサイズなど)を変えたりした, ちょっと違うバージョンを作成する必要があるときには, ユーザが分りやすいように, package ごとに別々のサブディレクトリを作成し, ただし, できるだけ port 間でファイルを共有するようにしてください. 典型的な例では, うまく変数を使えば, とても短いMakefileだけ, 1つ以外のすべてのディレクトリに置くだけで済みます. その短い Makefile には MASTERDIR を使って, 残りのファイルがあるディレクトリを指定できます. また PKGNAME の一部に変数に使って, package が別々の名前を持つようにしてください. 以下が, とても良い例になるでしょう. これは japanese/xdvi300/Makefile の一部です: PKGNAME= ja-xdvi${RESOLUTION}-17 : # default RESOLUTION?= 300 .if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \ ${RESOLUTION} != 300 && ${RESOLUTION} != 400 @${ECHO} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\"" @${ECHO} "Possible values are: 118, 240, 300 (default) and 400." @${FALSE} .endif japanese/xdvi300 は通常のパッチ, package ファイルももっています. そこで, make と入力すると, デフォルトの解像度(300)を使って, 普通に port の作成を行います. 他の解像度に関してですが, これが, xdvi118/Makefile の(コメントを除いた) すべてです. RESOLUTION= 118 MASTERDIR= ${.CURDIR}/../xdvi300 .include ${MASTERDIR}/Makefile (xdvi240/Makefile と xdvi400/Makefile も同様です). MASTERDIR が bsd.port.mk に PATCHDIR や PKGDIR などの通常のサブディレクトリが xdvi300 にあることを教えます. RESOLUTION=118 の行が, xdvi300/Makefile の RESOLUTION=300 の行を無効にし, port は解像度を118として作成されます. 共有ライブラリのバージョン まず, 共有ライブラリのバージョンについての指針 を読んで, 共有ライブラリのバージョンを 一般的にどうすれば良いかを理解してください. 盲目的に, ソフトウエアの作者がちゃんと理解していると 信じててはいけません, 多くの場合違います. 細い点まで考慮することは大変重要なことです, なぜなら我々は互換性がないかもしれない大量の ソフトウェアを共存させようとする, 特殊な状況にあるからです. 不注意な port の導入が共有ライブラリに関して, 多大な問題を引き起したことが過去にあります (今まで, jpeg-6b がなぜ 9.0 といバージョン番号を持っているか不思議に 思ったことはありませんか?). もし, 疑問があれば, &a.ports; にメールを送ってください. ほとんどの時間は, 正しいシェアードライブラリのバージョンを決めることと, それを実現するためのパッチを作成することに終始します. しかしながら, が同じソフトウェアの違ったバージョンの ソフトウェアが既にツリーにあるばあいには, 状況は非常に複雑です. つまり, FreeBSD では, ユーザがリンカにどのバージョンの共有ライブラリを 使用するかを指定できないからです (リンカは常にもっとも高いバージョンを選びます). これは, もし, libfoo.so.3.2 と libfoo.so.4.0 がシステムに存在するときには, リンカに特別なアプリケーションだけ libfoo.so.3.2 をリンクするように指示する方法がないことを意味します. これは, コンパイル時のリンクという意味では完全に見劣りします. この場合の唯一の解決方法は, 共有ファイルの名前の ベース 部分を変えることです. 例えば, libfoo.so.4.0 を libfoo4.so.1.0 へ変えることによって, バージョン 3.2 とバージョン 4.0 共に他の port からリンクされることができるようになります. マニュアル MAN[1-9LN] 変数を使用すると, 自動的にすべてのマニュアルを pkg/PLIST に加えます (つまり, マニュアルを PLIST に加えては いけません — PLIST の生成 を参照してください). またマニュアルを /etc/make.conf 中の NOMANCOMPRESS の設定に応じて, install時に自動的に圧縮したり伸長したりします. マニュアルをインストール時に圧縮するかどうかを 指定するには, MANCOMPRESSED 変数を使用します. この変数は, 3つの値をとることができます, yes, no そして maybe です. yes はマニュアルが既に圧縮されて インストールされている, no はされていない, maybe はそのソフトウェアがすでに, NOMANCOMPRESS に合わせており bsd.port.mk が特別なにもする必要がないことを意味します. USE_IMAKE がセットされていて, NO_INSTALL_MANPAGES がセットされていなければ, MANCOMPRESSED は自動的に yes に設定され, それ以外の場合には, no になります. デフォルトがあなたの port に合わない場合以外は明示的に設定する必要がありません. PREFIX 以外のディレクトリの下に マニュアルを置くような port では MANPREFIX を指定することができます. さらに, 特定のセクションのマニュアルだけ, 標準ではない場所にインストールする場合, 例えばいくつかの Perl のモジュールの ports など, には個々のマニュアルのパスを MANsectPREFIX (sect は, 1-9, または, L か N を表わします) によって指定できます. ができます. マニュアルが, 言語特有のサブディレクトリに 置かれる場合には, 言語名を MANLANG に設定してください. この変数のデフォルト値は, "" になっています (つまり, 英語のみ). これは, 全部をまとめた例です. MAN1= foo.1 MAN3= bar.3 MAN4= baz.4 MANLANG= "" ja MAN3PREFIX= ${PREFIX}/share/foobar MANCOMPRESSED= yes 以下の6個のファイルがこの port でインストールされます. ${PREFIX}/man/man1/foo.1.gz ${PREFIX}/man/ja/man1/foo.1.gz ${PREFIX}/share/foobar/man/man3/bar.3.gz ${PREFIX}/share/foobar/man/ja/man3/bar.3.gz ${PREFIX}/man/man4/baz.4.gz ${PREFIX}/man/ja/man4/baz.4.gz Motifを必要とするport 最近はコンパイルに Motif を必要とするアプリケーションが増えて きました. (Motif自体は有料のものがいくつかの会社から手に入りま すし, 多くのアプリケーションがコンパイル可能な無料の互換ライブラリ が x11-toolkits/lesstifにあります) Motifはかなり広く使われていますし, 製品のライ センスではライブラリを静的にリンクした 実行形式は再配布が認めら れている場合が多いので, Motifを必要とするソフトウェアを簡単に 動的(port からコンパイルする人々のために)/静的(package を配布 する人々のために)にリンクできるような しくみが用意されています. <makevar>REQUIRES_MOTIF</makevar> Motif がないとコンパイルできないportのMakefileではこの変 数を指定してください. これによって, Motifを持っていない人が このportをコンパイルしようとするのを未然に防ぎます. <makevar>MOTIFLIB</makevar> この変数は bsd.port.mk によって Motif ライブラリの指 定に置き換えられます. ソース内のMakefileやImakefileで Motif ライブラリを指定しているところをこの変数に置き換えるよ うにパッチをあててください. 代表的な例としては以下の二つがあげられます: MakefileかImakefileの中でMotifライブラリが として使われている場合には, かわりに MOTIFLIB と書いてください. Imakefileの中で XmClientLibs が使われている 場合には, それを ${MOTIFLIB} ${XTOOLLIB} ${XLIB} と書きかえてください. MOTIFLIB は通常 -L/usr/X11R6/lib -lXm か /usr/X11R6/lib/libXm.a に置き換えら れます. したがって前に や をつけ る必要はありません. X11 のフォント もし, あなたの port が X window system のフォントをインストールするのであれば, それらを X11BASE/lib/X11/fonts/local に置くようにしてください. このディレクトリは XFree86 release 3.3.3 で新設されたものです. もし, それが存在しなければ作成し, ユーザに XFree86 を 3.3.3 かそれより新しいものに更新か, すくなくとも, このディレクトリを /etc/XF86Config の font path に加えるように促すメッセージを出力するようにしてください. Info ファイル 新しい版の texinfo(2.2.2-RELEASE およびそれ以降に入っています) には, install-info というコマンドが含まれており, dir ファイルに項目を追加したり, 削除したりすることがで きます. もし, あなたの port が info ドキュメントをインストー ルするのであれば, 以下の指示に従って, その port および package が正しく, ユーザの ${PREFIX}/info/dir ファイル を更新するようにしてください. (この節は, とても長くてすいません, しかし info ファイルを作りあげるためには, これらは不可欠 です. 正しく行なえば, 美しい リストができますので, 辛抱してください! :) まず, これを知っておかなければなりません: &prompt.user; install-info --help install-info [OPTION]... [INFO-FILE [DIR-FILE]] Install INFO-FILE in the Info directory file DIR-FILE. (訳注: Info ディレクトリの INO-FILE を DIR-FILE にインストールする) Options: --delete Delete existing entries in INFO-FILE; don't insert any new entries. (訳注: INFO-FILE の中の項目を削除, 新しい項目は一切追加しない.) : --entry=TEXT Insert TEXT as an Info directory entry. (訳注: TEXT を Info ディレクトリの項目として追加する.) : --section=SEC Put this file's entries in section SEC of the directory. (訳注: このファイルの項目を Info ディレクトリの SEC という節に置く.) : このプログラムは, 実際には info ファイルをインストール しません, 単に dir ファイルにエントリーを挿入したり削除し たりするだけです. これから, install-info を使用するように, ports を変換す る7段階の工程を示します. 例として editors/emacsを 使用します. まず, texinfo のソースを見て, @dircategory と @direntry 文がないファイルについて, それらを追加するパッチを作成します. 以下は, ここでの例での patchの一部です: --- ./man/vip.texi.org Fri Jun 16 15:31:11 1995 +++ ./man/vip.texi Tue May 20 01:28:33 1997 @@ -2,6 +2,10 @@ @setfilename ../info/vip @settitle VIP +@dircategory The Emacs editor and associated tools +@direntry +* VIP: (vip). A VI-emulation for Emacs. +@end direntry @iftex @finalout : フォーマットについては見ればわかると思います. dir というファイルに必要な項目を書いておいてくれる作者 も多いので, まず自分で書く前にさがしてみてください. また, 関係 する ports も調べて, 節(section)の名前や, インデントなどが きちんと合っているかどうかを確認してください (項目のテキスト は, すべて4つめのタブ・ストップ(tab stop)から始めることを推 奨します). 1つのファイルに対して1つの info の項目しか書けないことに注 意してください, これは, install-info --delete が, そのバグにより, @direntry セクションに複数の項目を書 いても, 初めの1つの項目しか削除してくれないからです. texinfo のソースにパッチをあてるかわりに, dir の項目 を install-info の 引数((, ) として与えることもできます. これはあまり良い方法とは 思えません, なぜなら, 同じ情報を3ヶ所(Makefile, PLIST の @exec/@unexec: 以下参照) に重複して, 書く必要があるからです. しかしながら, もし日本語(あるいは, 他のマルチバイト文字)の info ファイルがあるのならば, install-info の特別な引数を使用する必要があるでしょう, なぜならば, makeinfo がこのような texinfo ソースファイル を扱えないからです. (このようなものをどう扱うかの例としては, japanese/skk の Makefile と PLIST を見て ください.) portのディレクトリに戻って, make clean; make をして, info ファイルが texinfo ソースファイルから再び生成さ れることを確認してください. texinfo ソースファイルのほうが info ファイルよりも新しいので, make とタイプすれば, info ファイルは再構築されるはずですが, 多くの Makefile には info ファイルの正しい依存関係が書かれていません. emacs の場合, info ファイルの再構築ため, man サブディレクトリ に降りていくようにするために, メインの Makefile.in にパッ チをあてる必要がありました. --- ./Makefile.in.org Mon Aug 19 21:12:19 1996 +++ ./Makefile.in Tue Apr 15 00:15:28 1997 @@ -184,7 +184,7 @@ # Subdirectories to make recursively. `lisp' is not included # because the compiled lisp files are part of the distribution # and you cannot remake them without installing Emacs first. -SUBDIR = lib-src src +SUBDIR = lib-src src man # The makefiles of the directories in $SUBDIR. SUBDIR_MAKEFILES = lib-src/Makefile man/Makefile src/Makefile oldXMenu/Makefile lwlib/Makefile --- ./man/Makefile.in.org Thu Jun 27 15:27:19 1996 +++ ./man/Makefile.in Tue Apr 15 00:29:52 1997 @@ -66,6 +66,7 @@ ${srcdir}/gnu1.texi \ ${srcdir}/glossary.texi +all: info info: $(INFO_TARGETS) dvi: $(DVI_TARGETS) man サブディレクトリでのデフォルトターゲットは, info で呼ばれるのに対して, メインの Makefile では, all で呼びたいので, 2つめのpatchが必要でした. また, info info ファイルのインストールも削除しました, なぜなら, 同じものが同じ名前で既に /usr/share/info にあるからです. (このパッチはここにはありません.) もし, Makefile に dir ファイルをインストールす る個所があれば, 削除します. あなたの port がインストー ルしてはいけません. また, dir ファイルを壊してしまうよう なコマンドの類も削除します. --- ./Makefile.in.org Mon Aug 19 21:12:19 1996 +++ ./Makefile.in Mon Apr 14 23:38:07 1997 @@ -368,14 +368,8 @@ if [ `(cd ${srcdir}/info && /bin/pwd)` != `(cd ${infodir} && /bin/pwd)` ]; \ then \ (cd ${infodir}; \ - if [ -f dir ]; then \ - if [ ! -f dir.old ]; then mv -f dir dir.old; \ - else mv -f dir dir.bak; fi; \ - fi; \ cd ${srcdir}/info ; \ - (cd $${thisdir}; ${INSTALL_DATA} ${srcdir}/info/dir ${infodir}/dir); \ - (cd $${thisdir}; chmod a+r ${infodir}/dir); \ for f in ccmode* cl* dired-x* ediff* emacs* forms* gnus* info* message* mh-e* sc* vip*; do \ (cd $${thisdir}; \ ${INSTALL_DATA} ${srcdir}/info/$$f ${infodir}/$$f; \ chmod a+r ${infodir}/$$f); \ (これは, 既存のportを修正するときのみ必要です.) pkg/PLIST を見て, info/dir にパッチをあて ようとするものすべてを削除します. これらは, pkg/INSTALL やその他のファイルにもあるかもしれない ので, いろいろさがしてみてください. Index: pkg/PLIST =================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v retrieving revision 1.15 diff -u -r1.15 PLIST --- PLIST 1997/03/04 08:04:00 1.15 +++ PLIST 1997/04/15 06:32:12 @@ -15,9 +15,6 @@ man/man1/emacs.1.gz man/man1/etags.1.gz man/man1/ctags.1.gz -@unexec cp %D/info/dir %D/info/dir.bak -info/dir -@unexec cp %D/info/dir.bak %D/info/dir info/cl info/cl-1 info/cl-2 post-install ターゲットを Makefile に加えて, dir ファイルが存在しなければ作成するようにします. また, インストールされた info ファイルについては, install-info を実行するようします. Index: Makefile =================================================================== RCS file: /usr/cvs/ports/editors/emacs/Makefile,v retrieving revision 1.26 diff -u -r1.26 Makefile --- Makefile 1996/11/19 13:14:40 1.26 +++ Makefile 1997/05/20 10:25:09 1.28 @@ -20,5 +20,11 @@ post-install: .for file in emacs-19.34 emacsclient etags ctags b2m strip ${PREFIX}/bin/${file} .endfor + if [ ! -f ${PREFIX}/info/dir ]; then \ + ${SED} -ne '1,/Menu:/p' /usr/share/info/dir > ${PREFIX}/info/dir; \ + fi +.for info in emacs vip viper forms gnus mh-e cl sc dired-x ediff ccmode + install-info ${PREFIX}/info/${info} ${PREFIX}/info/dir +.endfor .include <bsd.port.mk> 新しい info ファイルを作成するのに, /usr/share/info/dir と上のコマンド, 以外は使用しな いでください. 実際のところ, もし port する人がこれに関して PLIST に自らまったく手を加える必要がないのであれば, 上 のパッチのはじめの3行を bsd.port.mk に加えたでしょう. PLIST を編集して, 同じ働きをする @exec 文, そ れにpkg_delete のために @unexec 文を加えてくださ い. @unexec を使用して info/dir を削除する必 要はありません. Index: pkg/PLIST =================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v retrieving revision 1.15 diff -u -r1.15 PLIST --- PLIST 1997/03/04 08:04:00 1.15 +++ PLIST 1997/05/20 10:25:12 1.17 @@ -16,7 +14,15 @@ man/man1/etags.1.gz man/man1/ctags.1.gz +@unexec install-info --delete %D/info/emacs %D/info/dir : +@unexec install-info --delete %D/info/ccmode %D/info/dir info/cl info/cl-1 @@ -87,6 +94,18 @@ info/viper-3 info/viper-4 +@exec [ -f %D/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > %D/info/dir +@exec install-info %D/info/emacs %D/info/dir : +@exec install-info %D/info/ccmode %D/info/dir libexec/emacs/19.34/i386--freebsd/cvtmail libexec/emacs/19.34/i386--freebsd/digest-doc @unexec install-info --delete コマンドは, info ファイル自身より先に置き, コマンドがファイルを読めるようにし ておかなければならないことに注意してください. また, @exec install-info コマンドは info ファイルおよび dir ファイルを作る @exec コマンドより後に おかなければなりません. テスト をして出来栄えに感服しましょう :) 各段階の前後に, dir ファイルをチェックしましょう. <filename>pkg/</filename> サブディレクトリ まだ触れていない, いくつかのこつが pkg/ サブディレクトリにはあり, 時として便利でしょう. <filename>MESSAGE</filename> もし, インストールする人にメッセージを表示する 必要がある場合には, そのメッセージを pkg/MESSAGE に置けます. この機能は, pkg_add の後の追加のインストール手続きを表示するときなどに, 重宝します. pkg/MESSAGE ファイルは pkg/PLIST に加える必要はありません. また, もしユーザが package ではなく port を使用して いる場合には自動的には表示されませんので, 明示的に post-install で表示するようにするべきでしょう. <filename>INSTALL</filename> バイナリパッケージが pkg_add でインストールされるときに, 実行される必要がある コマンドがあれば, pkg/INSTALL スクリプトを使って実行することができます. このスクリプトは自動的に package に加えられ, pkg_add によって2度実行されます. はじめは INSTALL ${PKGNAME} PRE-INSTALL と実行され, 2度目には, INSTALL ${PKGNAME} POST-INSTALL と実行されます. どちらのモードで実行されているかは, $2 を調べることによってわかります. 環境変数 PKG_PREFIX には package がインストールされるディレクトリが設定されます. 詳細は &man.pkg.add.1; を見てください. port を make install で インストールするときには, このスクリプトは自動的に実行されません. もし, 実行される必要があるならば, port の Makefile から明示的に呼ぶ必要があります. <filename>REQ</filename> port が(インストールされるシステムの状態によって) インストールされるべきか, されないべきか区別する必要が あるときには, “要件(requirements)” スクリプト pkg/REQ を作ることができます. これは, インストール及びデインストール (package の削除)の時に自動的に実行され, それらが処理されるべきかを決定します. make の変数にあわせた <filename>PLIST</filename> の変更 いくつかの port, 特に p5- portsなど, は configure のオプション (あるいは, p5- ports の場合は perl のバージョン)によって, PLIST を変える必要があります. これを容易に実現するために, PLIST 中の %%OSREL%%, %%PERL_VER%%, %%PERL_VERSION%% は, 適切に置き換えられるようになっています. %%OSREL%% の値は, オペレーティングシステムの数字で表されたリビジョンです (例えば, 2.2.7). %%PERL_VERSION%% は perl のバージョン番号全体(例えば, 5.00502 )で, %%PERL_VER%% はバージョン番号から, パッチレベルを引いてものです(例えば, 5.005). 他の置き換えが必要であれば, PLIST_SUB 変数に VAR=VALUE という形式のペアのリストを設定することによって, PLIST 中の %%VAR%% は VALUE に置き換えられます. 例えば, バージョンに固有の沢山のファイルを インストールする場合には, Makefile に OCTAVE_VERSION= 2.0.13 PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} と書いて, PLIST 中のバージョン番号が表われるすべてのところに, %%OCTAVE_VERSION%% と書きます. このようにしておけば, port をアップグレードするときに, 何十行(ときとして, 何百行)も PLIST を書き替えないですみます. この書き換えは ( マニュアル の追加も) do-install と post-install ターゲット のあいだに, PLIST を読み TMPPLIST (デフォルトは, WRKDIR/.PLIST.mktmp ) に書き込むことによって行なわれます. もし, あなたの port が PLIST を実行時に生成するのであれば, do-install のあいだか, その前に行うようにしてください. また, 書きかえられたあとのファイルを編集する必要がある場合には, post-install で, TMPPLIST を書きかえてください. <filename>pkg</filename> サブディレクトリにあるファイル名の変更 pkg サブディレクトリにあるファイルは全て, 変数を 使用して定義されていますので, 必要であれば Makefile 中で 変更可能です. いくつかの ports で 一つの pkg サブディレクトリを共有する場合や, 上記のファイルに書き込む 必要があるときなど, 特に便利です. (pkg サブディレクトリに直接書き込むのが良くない理由に ついては WRKDIR 以外への書きこみ を参照してください.) 以下が変数名とそのデフォルト値の表です. Variable Default value COMMENT ${PKGDIR}/DESCR DESCR ${PKGDIR}/DESCR PLIST ${PKGDIR}/PLIST PKGINSTALL ${PKGDIR}/PKGINSTALL PKGDEINSTALL ${PKGDIR}/PKGDEINSTALL PKGREQ ${PKGDIR}/REQ PKGMESSAGE ${PKGDIR}/MESSAGE PKG_ARGSを上書きせずに, これらの変数を変更 するようにしてください. PKG_ARGSを変更すると これらのファイルは port から正しく /var/db/pkg にインストールされなくなります. ライセンス上の問題 ソフトウェアによっては制限の厳しい ライセンスがついてきたり, 法律的に問題があるかもしれません. (PKPの公開鍵暗号化, ITAR (暗 号化ソフトウェアの輸出) などが例としてあげられます). それらを どう扱えばいいかはライセンスの文面によって さまざまな場合があり ます. ソフトウェア移植者として, あなたにはライセンスをよく読み, FreeBSD プロジェクトが FTP または CD-ROM で配布してはいけないソフ トウェアを配布してしまうことのないよう, 注意する義務があります. なにか疑問がある場合には, &a.ports;に聞いてみてください. よく見られるケースに対処するために, 二つの変数が用意されてい ます: ソフトウェアに “有償再配布を禁ずる” という趣旨のライセン スがついてきた場合には NO_CDROM という変数にその理由を記述して ください. 私たちはこれがついているportはCD-ROMリリースに入 れないようにしますが, オリジナルのソースファイルとpackage はFTPでは取れるようにしておきます. もしも, 生成される package が個々のサイトで独自に構築さ れる必要があったり, ライセンスによって生成されるバイナリが 配布できない場合には, NO_PACKAGE 変数にその理由を記述してくだ さい. そのような package が FTP サイトに置かれたり, リリース 時の CD-ROM へ入らないようにします. ただし, いずれの場合も distfile は(FTP や CD-ROM に)含まれるようになります. Portが, 使用者によっては法律上の問題が生じる時 (暗号化ソフ トウェアなど), または“商用利用を禁ずる”とライセンスに書い てある場合には RESTRICTEDという変数にその理由を入れ てください. この場合には, ソースファイルやpackageは私たちの FTPサイトにも置かれません. GNU一般公有使用許諾書 (GPL) はバージョン1, 2とも port作成上は何ら問題にはなりません. もしあなたが，ソースツリー管理者 (committer) であれば， ソースツリーにこのようなportを入れる際に, ports/LEGAL ファイルを書き換えるのを忘れないようにし てください. アップグレード Port のバージョンが原作者からのものに比べて古いことに気がつ いたら, まずはあなたの持っているportが私たちの最新のもの (ミラー サイトの ports/ports-current というディレクトリにあります) であることを確認してください. 次に, portの Makefile にMAINTAINER (保守担当者) の アドレスが書いてある場合には, その人にメールを出してみましょう. 保守担当者の人がすでにアップグレードの準備を しているかもしれま せんし, (新しいバージョンの安定度に問題があるなど) あえてアッ プグレードをしない理由があるのかもしれません. 保守担当者にアップグレードをしてくれと頼まれた場合, あるいは そもそもportのMakefileに保守担当者が書いてない場合などは, あ なたがアップグレードをしてくださると助かります. その場合にはアッ プグレードをしたのち, 変更前と変更後のディレクトリの再帰的diff (unified diff と context diff のどちらでもいいのですが, port のコミッター達は unified diff のほうを好むようです) をとって送ってください. (例えば, 変更前のディレクトリが superedit.bak という名前でとってあり, 変更後のもの が superedit に入っているなら, diff -ruN superedit.bak superedit の結果を送ってください. ) diff の出力を見て, すべての変更が正しくなされているか確認して ください. 変更箇所については, &man.send-pr.1; (カテゴリーは, ports)に diff の出力結果を添えて, 私たちに送ってもらうのが一 番よいです. commit する際に CVS に明確に記述しなければならない ので, 付け加えたり削除したりしたファイルがあったら, それについ て書いておいてください. もし diff の大きさが 20 KB 程度を 超えるようであれば, 圧縮したものを uuencode して下さい. そうでなければそのまま PR に入れるだけでいいです. 繰り返しになりますが, ports の変更を送るときには, &man.shar.1; ではなく &man.diff.1; を使用してください. やっていいことといけないこと この節では, ソフトウェアをportする上でよくある落し穴などにつ いて説明します. このリストを使って, あなた自身が作成した port のチェックはもとより, PR データベースにある, 他の人が作成した port のチェックもできます. あなたがチェックした port について のコメントを バグ報告と一般的な論評 にしたがって, 送ってください. PR データベースにある port を チェックすることによって, 私達がそれらを commit するのを早くし, あなたが何をしているか理解していることも示します. バイナリのstrip バイナリは strip してください. オリジナルのソースがバイナリを strip してくれる場合は良いですが, そうでない場合には post-install ターゲットを指定して strip するようにするとよいでしょう. 例えば, こんな風になります: post-install: strip ${PREFIX}/bin/xdl インストールされた実行形式がすでに strip されているかどうかは file コマンドで確認できます. これが`not stripped'と言わなければ, stripされているということです. <makevar>INSTALL_*</makevar> マクロ あなた自身の *-install ターゲットでファイルの正しいモードと オーナを保証するために, 必ずbsd.port.mkで提供されて いるマクロを使用してください. マクロは以下のようなものがあります. ${INSTALL_PROGRAM} は実行可能なバイナリを インストールするコマンドです. ${INSTALL_SCRIPT} は実行可能なスクリプトを インストールするコマンドです. ${INSTALL_DATA} は共有可能なデータを インストールするコマンドです. ${INSTALL_MAN} はマニュアルとその他のドキュメ ントをインストールするコマンドです. (圧縮はしません) これらは基本的に install コマンドに適当なフラグを与え たものです. どのようにこれらを使用するかは以下の例を見てください. <makevar>WRKDIR</makevar> WKRDIR の外のファイルにはなにも書き込まないように してください. WRKDIR は ports のビルド中に書き込こめる ことが保証されている唯一の場所です( CDROM から ports をコンパイルを参照). PKGDIR にあるファイルを修正する必要がある ときには, 変数の再定義 によって行ない, 上書きはしないでください. <makevar>WRKDIRPREFIX</makevar> WRKDIRPREFIX を尊重していることを確認してください. 特に, 別の port の WRKDIR を参照している ときには気を付けてください. 正しい場所は, WRKDIRPREFIX PORTSDIR /subdir/ name/work, です, PORTSDIR/subdir/ name/work とか .CURDIR/../../subdir /name/work とかではありません. また, 自分で WRKDIR 定義するときには, 頭に ${WRKDIRPREFIX}${.CURDIR} が付いている 事を確認してください. OS や OS のバージョンの区別 Port の過程で, 修正や, どのバージョンの UNIX で動くかによる条件つきコンパイルなどが 必要なコードに出会うかもしれません. そのような条件つきコンパイルなどのための 変更をおこなうときには, FreeBSD 1.x システムへの移植や, CSRGの4.4BSD, BSD/386, 386BSD, NetBSD, OpenBSD などの他のBSDシステムへの移植が可能なように, できるだけ普遍的な変更をおこなうことを 心がけてください. 4.3BSD/Reno (1990) およびそれより新しい BSD 版を古いバージョンと区別するには BSD マクロを利用するのがよいでしょう. これは <sys/param.h> で定義されています. このファイルがすでにインクルードされていればよいのですが, もしそうでない場合には以下のコードを, その .c ファイルの適当な場所に加えてください. #if (defined(__unix__) || defined(unix)) && !defined(USG) #include <sys/param.h> #endif これらの 2 つのシンボルが定義されているすべてのシステムには sys/param.h があるはずです. もし, そうでないシステムを発見したら我々にも教えてください. &a.ports; までメールを送ってください. あるいは, GNU の Autoconf のスタイルを使用することもできます, #ifdef HAVE_SYS_PARAM_H #include <sys/param.h> #endif この方法を使用するときには, Makefile 中の CFLAGSに -DHAVE_SYS_PARAM_H を加えることを忘れないようにしてください. いったん sys/param.h がインクルードされると, #if (defined(BSD) && (BSD >= 199103)) このようにしてそのコードが 4.3 Net2 コードベース, またはそれより新しいもの (例: FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1とそれ以前) の上でコンパイルされているかを検出できます. #if (defined(BSD) && (BSD >= 199306)) これは, 4.4コードベース, またはそれより新しいもの (例: FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0とそれ以後) の上でコンパイルされているかどうかを 検出するために使用します. 4.4BSD-Lite2 コードベースでは, BSD マクロの値は 199506 になっています. これは参考程度の意味合いしかありません. 4.4-Lite ベースの FreeBSD と 4.4-Lite2 での変更がマージされたバージョンとを 区別するのに使用するべきものではありません. この目的のためには, __FreeBSD__ マクロをかわりに使用してください. 以下は控え目に使ってください. __FreeBSD__ はFreeBSDのすべての版で定義されています. 変更が FreeBSD だけに適用されるとき以外は使用しないでください. Portでよくある, strerror() ではなく sys_errlist[] を使うなどは, FreeBSDでの変更ではなく, BSD の流儀です. FreeBSD 2.xでは __FreeBSD__ が 2 と定義されています. それ以前の版では 1 になっています. その後の版では, そのメジャー番号に合うように上がっていきます. もし, FreeBSD 1.x システムと FreeBSD 2.x あるいは FreeBSD 3.x システムを区別する必要があれば, 上で述べた BSDマクロを使用するのが, 大抵の場合において正しい答です. もし, FreeBSD特有の変更であれば (ld を使うときのシェアードライブラリ用のなオプションなど), __FreeBSD__を使い #if __FreeBSD__ > 1 のようにFreeBSD 2.x および, それ以降のシステムを検出するのはかまいません. もし, 2.0-RELEASE以降のFreeBSDシステムを細かく検出したけれ ば, 以下を使用することができます. #if __FreeBSD__ >= 2 #include <osreldate.h> # if __FreeBSD_version >= 199504 /* 2.0.5+ release specific code here */ # endif #endif Release - _FreeBSD_version + __FreeBSD_version 2.0-RELEASE 119411 2.1-CURRENT's 199501, 199503 2.0.5-RELEASE 199504 2.1 以前の 2.2-CURRENT 199508 2.1.0-RELEASE 199511 2.1.5 以前の 2.2-CURRENT 199512 2.1.5-RELEASE 199607 2.1.6 以前の 2.2-CURRENT 199608 2.1.6-RELEASE 199612 2.1.7-RELEASE 199612 2.2-RELEASE 220000 2.2.1-RELEASE 220000 (2.2-RELEASE と同じです) 2.2.1-RELEASE 以後の 2.2-STABLE 220000 (これも同じです) texinfo-3.9 以後の 2.2-STABLE 221001 top 導入以後の 2.2-STABLE 221002 2.2.2-RELEASE 222000 2.2.2-RELEASE 以後の 2.2-STABLE 222001 2.2.5-RELEASE 225000 2.2.5-RELEASE 以後の 2.2-STABLE 225001 ldconfig -R 以後の 2.2-STABLE 225002 2.2.6-RELEASE 226000 2.2.7-RELEASE 227000 2.2.7-RELEASE 以後の 2.2-STABLE 227001 semctl(2) 変更後の 2.2-STABLE 227002 2.2.8-RELEASE 228000 2.2.8-RELEASE 以後の 2.2-STABLE 228001 mount(2) 変更以前の 3.0-CURRENT 300000 mount(2) 変更以後の 3.0-CURRENT 300001 semctl(2) 変更以後の 3.0-CURRENT 300002 ioctl 引数変更後の 3.0-CURRENT 300003 ELF 移行後の 3.0-CURRENT 300004 3.0-RELEASE 300005 3.0-RELEASE 以後の 3.0-CURRENT 300006 3/4 の分岐後の 3.0-STABLE 300007 3.1-RELEASE 310000 3.1-RELEASE 以後の 3.1-STABLE 310001 3/4 の分岐後の 4.0-CURRENT 400000 (2.2-STABLE は, 2.2.5-RELESE 以後, “2.2.5-STABLE” と呼ばれることがあります.) 見ての通り, これは年・月というフォーマットになっていましたが, バージョン 2.2 から, より直接的にメジャー/マイナー番号を使う ように変更になりました. 並行していくつかのブランチ(枝分かれし たバージョン)を開発する場合には, リリースされた日付でそれらの リリースを分類することが不可能だからです. (あなたが今 port を作成するときに, 古い -CURRENT 達について心配 する必要はありません. これは参考のために挙げられているにすぎま せん.) これまで, 何百ものportが作られてきましたが, __FreeBSD__ が正しく使われたのは, 1つか2つの場合だけでしょう. 以前のportが誤った場所でそのマクロを使っているからと いって, それをまねする理由はありません. <filename>bsd.port.mk</filename> の後に書くこと .include <bsd.port.mk> の行の後には なにも書かないようにしてください. 大抵の場合は Makefile の 中程のどこかで, bsd.port.pre.mk を include して, 最後に bsd.port.pre.mk を include することによって避けることができます. pre.mk/post.mk のペアか bsd.port.mk だけのどちらかだけを include してください. 2つを混ぜないでください. 前者は, いくつかの変数の定義だけ をして, Makefile でのテストに使用し, 後者は残りを定義します. 以下は bsd.port.pre.mk で定義される重要な変数です. (これは, すべてではありません. 完全なリストは bsd.port.mk を参照してください.) 変数名 解説 ARCH uname -m で返される アーキテクチャ. (例, i386). OPSYS uname -s で返される オペレーティングシステム (例, FreeBSD). OSREL オペレーティングシステムの リリースバージョン (例., 2.1.5, 2.2.7). OSVERSION 数字形式のオペレーティングシステム のバージョン, 上記の __FreeBSD_version と同じです. PORTOBJFORMAT システムのオブジェクト フォーマット (aout あるいは elf). LOCALBASE “local” ツリーのベース. (例, /usr/local/). X11BASE “X11” ツリーのベース. (例, /usr/X11R6/). PREFIX portsのインストール先 ( PREFIXについてを参照). USE_IMAKE, USE_X_PREFIX あるいは MASTERDIR などの変数を定義する必要がある場合には, bsd.port.pre.mk を include する前に定義してください. 他のものは, bsd.port.pre.mk の前でも後でもかまいません. 以下は bsd.port.pre.mk の後に書けるものの例です: # no need to compile lang/perl5 if perl5 is already in system .if ${OSVERSION} > 300003 BROKEN= perl is in system .endif # only one shlib version number for ELF .if ${PORTOBJFORMAT} == "elf" TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR} .else TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR} .endif # software already makes link for ELF, but not for a.out post-install: .if ${PORTOBJFORMAT} == "aout" ${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so .endif 付加的ドキュメント 普通のマニュアルや info ファイルのほかにユーザにとって有用だ と思えるようなドキュメントがある場合には, PREFIX/share/doc の下にインストールしてく ださい. これは前記と同様, post-installターゲットの 中からするのがいいでしょう. まず, あなたのportのために新しいディレクトリを作りま す. どのportのドキュメントか簡単にわかるような名前にする必 要がありますので, 普通は PKGNAME からバージョ ン番号を除いた部分を使うといいでしょう. もちろん, ユーザが異 なるバージョンのものを同時に使うことが予想される port の場合 には, PKGNAME をそのまま使ってかまいません. ユーザが /etc/make.conf でこの部分を禁止するために NOPORTDOCS という変数をセットしている場合には， これらのドキュメントが インストールされないようにしてください. こんな具合です. post-install: .if !defined(NOPORTDOCS) ${MKDIR}${PREFIX}/share/doc/xv ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv .endif これらのファイルを pkg/PLIST に入れるのを忘れないよ うにしてください. (packageが/etc/make.conf内の 変数を読む方法は今のところ存在しませんので, NOPORTDOCS については気にしないでください.) インストール時に pkg/MESSAGE ファイルを利用して, メッセージを表示することができます. 詳細は pkg/MESSAGE を使う の節を参照してください. MESSAGE ファイルは pkg/PLIST に加える必要はありま せん. <makevar>DIST_SUBDIR</makevar> /usr/ports/distfiles ディレクトリ内をあまり散らかさ ないようにしてください. たくさんのファイルを取ってくるport や, 数は少なくてもほかのportのファイルと混同されるおそれが あるファイル (Makefile など) がある場合には, DIST_SUBDIR に port の名前 (PKGNAME からバージョン番号を取った部分を 使うといいでしょう) を入れてください. すると, DISTDIRがデフォルトの /usr/ports/distfiles から /usr/ports/distfiles/DIST_SUBDIR に変更され, 取ってきたファイルはすべてそのサブディレクトリの中に置か れるようになります. また, ファイルを取ってくるときにバックアップサイトとして使わ れる ftp.freebsd.org のディレクトリ名にもこの変数の 値が使われます. (DISTDIRを明示的に指定し た場合には, ローカルのファイルを置くところは変わりますが, こ のサイトのディレクトリ名は変わりませんので, 必ず DIST_SUBDIRを使うようにしてください.) この変数はMakefile中で明示的に指定された MASTER_SITES には影響しないことに注意して ください. RCS文字列 RCS が特別な意味を与えている文字列をパッチ内に入れないように してください. ファイルを私たちのソースツリーに入れる時にこれら の文字列はCVSによって書き換えられてしまい, あとでまたパッチ を使おうとした時にうまくいかないことがあります. RCS文字列は ドル記号 ($) で囲まれており, $Id や $RCS などで始まり ます. パッチ作成上の注意 diffの再帰 () フラグを使って再帰的なパッ チを作るのは大変結構なのですが, でき上がったパッチは必ず目で チェックして余計なゴミが入っていないことを確認してくださ い. よくあるのはバックアップファイル同士の変更点, あるいは Imake や GNU configure を使うソフトウェアの Makefile の変更点が入っている場合などです. また, configure.in を編集して, autoconf を使って configure を作り直す ときには, configure の diff は含めずに (それらは, 数千行になることもしばしばです), USE_AUTOCONF=yes を定義して, configure.in の diff をとってください. ファイルをまるごと消す場合にはパッチを使わずに post-extract ターゲットで消す方が簡単です. できあがった 差分に満足したら, それらをソースのファイルごとに別々の パッチファイルに分割してください. <makevar>PREFIX</makevar> なるべく port は PREFIX に対する相対パス にインストールすることができるように心がけてください. (この変数の値は USE_X_PREFIXか USE_IMAKEが指定してある時には X11BASE (デフォルト/usr/X11R6), そうでない場合にはLOCALBASE (デフォルト/usr/local) にセットされます.) サイトによってフリーソフトウェアが インストールされる場所が 違いますので, ソース内で /usr/local や /usr/X11R6 を明示的に書かないようにしてください. X のプログラムで imake を使うものについては, これは問題に はなりません. それ以外の場合には, ソース中のMakefileやスク リプトで /usr/local (imakeを使わないXのプログラ ムは /usr/X11R6) と書いてあるところを PREFIX に書き換えてください. この値は portのコンパイル, およびインストール時に自動的に環境変数として 下位makeに渡されます. USE_X_PREFIXは本当に必要な時 (つまり, X のライブラリなどとリンクしたり, X11BASE 以下にある ファイルを参照したりする必要がある時) 以外には設定しないでください. 変数 PREFIX の値は port の Makefile やユーザの環境で変更することもできます. しかし, 個々の port が Makefile でこの変数の値を明示的に設定することはなるべくしない でください. また, 他の port からインストールされるプログラムやファイル を指定するときには, 上で述べた変数を使用してください. 例えば, less のフルパスを PAGER というマクロに入れた い場合は, コンパイラに -DPAGER=\"/usr/local/bin/less\" と渡すかわりに -DPAGER=\"${PREFIX}/bin/less\" (Xを使うportの時は -DPAGER=\"${LOCALBASE}/bin/less\" ) を渡し てください. こうしておけば, `/usr/local' がまるごとどこか他 の場所に移してあるサイトでも, あなたのportがそのまま使える 可能性が高くなります. ディレクトリ構成 インストール時には PREFIX の正しいサブディ レクトリにファイルを置くように心がけてください. ソフトウェア によっては新しいディレクトリを 一つ作ってファイルを全部それに 入れてしまうものがありますが, それはよくありません. また, バ イナリ, ヘッダファイルとマニュアル以外のすべてを lib というディレクトリに入れてしまうportもあります が, これもBSD的なファイルシステム構成からいうと正しくありま せん. これは以下のように分散すべきです. etc にセッ トアップ/コンフィグレーションファイル, libexec に 内部で使用されるプログラム (コマンドラインから呼ばれることの ないコマンド), sbin に管理者用のコマンド, info に GNU Info 用のドキュメント, そして share にアーキテクチャに依存しないファイルが入り ます. 詳細については man &man.hier.7; を見てくださ い. /usrの構成方針はほとんどそのまま /usr/localにもあてはまります. USENET “ニュース”を 扱う ports は例外です. これらは, ファイルのインストール先として PREFIX/news を使用します. 空のディレクトリの除去 ports は デインストール(削除) の際には, 自分自身を消去したあとに, (ディレクトリの) 除去をするようにしてください. これは, 大抵の場合 @dirrm の行を ports が作成するすべてのディレクトリについて 加えることによって実現できます. 親ディレクトリは, 子ディレクトリを先に消さないと 消せないことに気をつけて下さい. : lib/X11/oneko/pixmaps/cat.xpm lib/X11/oneko/sounds/cat.au : @dirrm lib/X11/oneko/pixmals @dirrm lib/X11/oneko/sounds @dirrm lib/X11/oneko といった感じです. しかし, ときとして, 他の port をディレクトリを共有しているために @dirrm がエラーを返すことがあります. rmdir を @unexec から呼びだすことによって, 警告(warning)なしで 空のディレクトリのみを削除することができます: @unexec rmdir %D/share/doc/gimp 2>/dev/null || true これを使えば, たとえ, 他の port がファイルを インストールしていて, PREFIX/share/doc/gimp が空でない場合でも エラーメッセージは表示されませんし, pkg_delete が異常終了することもありません. UID もしあなたの portがインストールされるシステム上に特定のユー ザを必要とする場合は, pkg/INSTALL スクリプトから pw コマンドを実行して自動的にそのユーザを追加するよ うにしてください. net/cvsup-mirror の portが参考になるでしょう. もしあなたの port が, バイナリのパッケージとしてとして インストールされるときにも, コンパイルされたときと同じユーザー/グループ ID を使わなければならないのなら, 50 から 99 の間で空いている UID を選んで登録してください. japanese/Wnn の port が参考になるでしょう. 既にシステムや他の portで利用されている UIDを使わないように 十分注意してください. 現在の 50から 99までの間の UIDは以下の とおりです. majordom:*:54:54:Majordomo Pseudo User:/usr/local/majordomo:/nonexistent cyrus:*:60:60:the cyrus mail server:/nonexistent:/nonexistent gnats:*:61:1:GNATS database owner:/usr/local/share/gnats/gnats-db:/bin/sh uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67:X-10 daemon:/usr/local/xten:/nonexistent pop:*:68:6:Post Office Owner (popper):/nonexistent:/nonexistent wnn:*:69:7:Wnn:/nonexistent:/nonexistent ifmail:*:70:66:Ifmail user:/nonexistent:/nonexistent pgsql:*:70:70:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh ircd:*:72:72:IRCd hybrid:/nonexistent:/nonexistent alias:*:81:81:QMail user:/var/qmail/alias:/nonexistent qmaill:*:83:81:QMail user:/var/qmail:/nonexistent qmaild:*:82:81:QMail user:/var/qmail:/nonexistent qmailq:*:85:82:QMail user:/var/qmail:/nonexistent qmails:*:87:82:QMail user:/var/qmail:/nonexistent qmailp:*:84:81:QMail user:/var/qmail:/nonexistent qmailr:*:86:82:QMail user:/var/qmail:/nonexistent msql:*:87:87:mSQL-2 pseudo-user:/var/db/msqldb:/bin/sh このリストを最新の状態に保つためにも, この範囲の UID や GID を予約するような port を作ったり, 既存の port にそのような改変を行って我々に送るときには, UID の予約に関する注意書きをつけてください. 合理的な port Makefile は単純かつ適切であるべきです. もし, Makefile を数行短かくできたり, もっと読みやすくできるのであれば, そうしてください. 例えば, shell の if 構文を使う代りに, make の .if 構文を使う, EXTRACT* の再定義で代用できるのであれば, do-extract を再定義しない, CONFIGURE_ARGS += --prefix=${PREFIX} とするかわりに, GNU_CONFIGURE とする, などです. <makevar>CFLAGS</makevar> の尊重 CFLAGS 変数は尊重すべきです. その port がこれを無視するのであれば, NO_PACKAGE=ignores cflags を Makefile に加えてください. コンフィグレーション(設定)ファイル もしあなたの port が設定ファイルを PREFIX/etc に置く必要がある場合には, それを単純にインストールしたり, pkg/PLIST に加えてはいけません. こうしてしまうと, pkg_delete が ユーザが苦労して作ったファイルを消してしまったり, 新しく インストールすると上書きされてしまったりします. 代りに, 見本となるファイルを suffix ( filename.sample が良いでしょう) を付けて インストールして, message を表示して, ソフトウエアを動かす前に, ユーザがそのファイル をコピーして編集をしなければならないことを知らせましょう. Portlint 送付や commit をする前に portlint を使ってチェックしましょう. フィードバック Portを作るためにソフトウェアに変更を加えたら, なるべく原作者にその旨を伝えてパッチ等を送ってください. これらが次のリリースに取り入れられれば, アップグレードが楽になります. その他諸々 pkg/DESCR, pkg/COMMENT, pkg/PLIST などのファイルは, それぞれ2重にチェックしてください. 再検討してもっと良い記述があれば, それに置きかえてください. GNU General Public License (GNU一般公有使用許諾)のコピーは (すでにあるので)コピーしないでください, おねがいします. 法律に関することには, 十分注意をはらってください. 私達に法律に反するような形でソフトフェアの配布をさせない でください! 困ったら.... 私たちに質問を送る前に, 既存のportの例とbsd.port.mkを ちゃんと読んでください! ;) それでもわからないことがあったら, 一人で悩まないでどんどん 質問してください! :) <filename>Makefile</filename> のお手本 これはportの Makefile を作る際のお手本です. かぎかっこ ([])内のコメントは忘れずに取ってください. 変数の順番, 段落の間の空行など, Makefile を作るときはなるべくこ の形式にしたがってください. この形式は重要な情報が簡単に見つけられるように 設計されています. portlint を使って Makefile をチェックすることが 推奨されています. [ヘッダ -- どのようなportのMakefileかすぐにわかるようになっています] # New ports collection makefile for: xdvi # Version required: pl18 ["1.5alpha" みたいなのでも結構です] [この Makefile の最初の版が作成された日付です. この port をアップグ レードするときには変えないでください.] # Date created: 26 May 1995 [このソフトウェアを最初に FreeBSD に port した人の名前, つまり, この Makefile の最初の版を書いた人です. この port をアップグレー ドするとき, この行も変えないでください.] # Whom: Satoshi Asami <asami@FreeBSD.ORG> # # $Id$ [ ^^^^ この部分は, CVS ツリーに入れる時に自動的に RCS の ID 文字列に 置き換えられます.] # [Port自体, およびオリジナルのソースを取ってくるところを記述する部分. 最初は必ずDISTNAME, そして必要ならPKGNAME, CATEGORIES, 続いて MASTER_SITESがおかれ, さらに MASTER_SITE_SUBDIR がおかれることもあり ます. そのあと, EXTRACT_SUFX か DISTFILES を指定することも可能です] DISTNAME= xdvi PKGNAME= xdvi-pl18 CATEGORIES= print [MASTER_SITE_* マクロを使用しない場合は, 最後のスラッシュを忘れないように ("/")!] MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications [ソースファイルが標準の ".tar.gz" 形式でない時にこれを使いましょう] EXTRACT_SUFX= .tar.Z [配布パッチのセクション -- ない場合もあります] PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/ PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz [保守責任者 -- これは *必ず* 必要です. 担当者 (あなた) 自身, あるいは 担当者に素早く連絡をとれる人のアドレスを書いてください. どうしてもこ こに自分のアドレスを書くのがいやな人は "ports@FreeBSD.ORG" と書いて もいいです] MAINTAINER= asami@FreeBSD.ORG [依存するport -- ない場合もあります] RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript LIB_DEPENDS= Xpm.5:${PORTSDIR}/graphics/xpm [ここには標準のbsd.port.mkの変数で, 上のどれにもあてはまらないものを 書きます] [コンフィグレーション, コンパイル, インストールなどの時に質問をする なら...] IS_INTERACTIVE=yes [${DISTNAME}以外のディレクトリにソースが展開されるなら...] WRKSRC= ${WRKDIR}/xdvi-new [配布されているパッチが ${WRKSRC} に対する相対パスで作られてい い場合にこの変数の指定が必要かも...] PATCH_DIST_STRIP= -p1 [GNU autoconfによって生成された "configure" スクリプトを走らせたいなら...] GNU_CONFIGURE= yes [/usr/bin/makeでなく, GNU makeを使わないといけないなら...] USE_GMAKE= yes [これがXのアプリケーションで "xmkmf -a" を走らせたいなら...] USE_IMAKE= yes [などなど] [下の方のルールで使う非標準の変数] MY_FAVORITE_RESPONSE= "yeah, right" [そして, 特別なターゲット, 使用順に] pre-fetch: i go fetch something, yeah post-patch: i need to do something after patch, great pre-install: and then some more stuff before installing, wow [最後には必ず] .include <bsd.port.mk> Packageの名前 Package の名前は以下のルールにしたがってつけてください. こ れは package のディレクトリを見やすくするためで, 無秩序な名前 がたくさん並んでいるとユーザが使いづらくなるのでは という心配か らです. (FTPサイトなどにはたくさんpackageがありますからね.) Packageの名前は以下のようにしてください. 言語-名前-オプション バージョン.番号 DISTNAME が上記の形式になっていない場合に は, PKGNAME をそのようにしてください. FreeBSD はユーザの慣れ親しんだ言語のサポートに力を入れて います. 特定の言語のためのportのpackage名には 言語- に ISO-639 で定義されている言語名の略称を入れ てください. 例えば, 日本語なら ja, ロシア語なら ru, ベト ナム語なら vi, 中国語なら zh, 韓国語ならば ko, ドイツ 語なら de, といった具合です. 名前 の部分は原則的にはすべて英小文字 を使います. 例外はたくさんのプログラムが入っている巨大なport の場合で, XFree86 (ほんとにあるんですよ) やImageMagickな どがこれにあたります. そうでない場合には, 名前の大文字を小文 字に (少なくとも最初の一字だけは) 変えてください. もし, 大文字であることが重要な場合(例えば, 1文字の名前, R とか V)には, あなたの裁量で大文字を使うのも良いでしょう. Perl 5 のモジュールでは, 頭に p5- を付け, 2重コロン (::) のセパレータをハイフン( - ) に置きかえるしきたりになっています. 例えば, Data::Dumper は p5-Data-Dumper になります. また, その ソフトウェアの名前として通常使われるものに番号, ハイフン, あ るいは下線が入っている場合には, それらを使うことも構いません (kinput2 など). コンパイル時に環境変数や make の引数などで ハードコードされたデフォルト を変えてコンパイルできる場合, -compiled.specifics にそのコンパイル時のデフォルトを入れてください (ハイフンはあってもなくてもかまいません). 用紙のサイズ, あるいはフォントの解像度などがこれにあたります. バージョン番号は数字とアルファベットからなり, ピリオド (.) で区切ります. アルファベットは二文字以上続けてはいけませ ん. ただ一つの例外は「パッチレベル」を意味する pl で, それ 以外にバージョン番号が まったくついていない場合にのみ使うことがで きます. では, DISTNAMEを正しい PKGNAMEに直す例を見てみましょう: DISTNAME PKGNAME 理由 mule-2.2.2. mule-2.2.2 まったく問題なし XFree86-3.1.2 XFree86-3.1.2 同上 EmiClock-1.0.2 emiclock-1.0.2 プログラム一つだけの時は小文字のみ gmod1.4 gmod-1.4 `<名前>' のあとにハイフンが必要 xmris.4.0.2 xmris-4.0.2 同上 rdist-1.3alpha rdist-1.3a alphaのような文字列は使えない es-0.9-beta1 es-0.9b1 同上 v3.3beta021.src tiff-3.3 なんなんでしょう ;) tvtwm tvtwm-pl11 バージョン番号は必ず必要 piewm piewm-1.0 同上 xvgr-2.10pl1 xvgr-2.10.1 pl が使えるのは他にバージョン番号がない場合のみ gawk-2.15.6 ja-gawk-2.15.6 日本語バージョン psutils-1.13 psutils-letter-1.13 コンパイル時に用紙のサイズを指定 pkfonts pkfonts300-1.0 300dpiフォント用のpackage オリジナルのソースにまったくバージョン情報が見当たらず, また原作 者が新しいバージョンをリリースする可能性が低いときには, バージョ ン番号として 1.0 を使えばいいでしょう (上記のpiewmの例がこ れにあたります). そうでない場合には, 原作者に聞くか, 日付 ( 年.月 .日) を使うなどしてください. カテゴリ すでに御存知のように, ports はいくつかのカテゴリに 分類されています. これを有効に利用するためには, port を 行う人々とユーザが, そろぞれのカテゴリが何であるか, どのようにしてカテゴリに分類するかを理解する必要が あります. 現在のカテゴリのリスト まず, これが現在の port のカテゴリーのリストです. アスタリスク(*) が付いているものは, バーチャル(virtual) カテゴリです -- これらには対応するサブディレクトリが port ツリーにはありません. バーチャルカテゴリでないものは, そのサブディレクトリ内の pkg/COMMENT に1行の記述があります (例, archivers/pkg/COMMENT). Category Description afterstep* Ports to support AfterStep window manager archivers Archiving tools. astro Astronomical ports. audio Sound support. benchmarks Benchmarking utilities. biology Biology-related software. cad Computer aided design tools. chinese Chinese language support. comms Communication software. Mostly software to talk to your serial port. converters Character code converters. databases Databases. deskutils Things that used to be on the desktop before computers were invented. devel Development utilities. Do not put libraries here just because they are libraries—unless they truly don't belong to anywhere else, they shouldn't be in this category. editors General editors. Specialized editors go in the section for those tools (e.g., a mathematical-formula editor will go in math). elisp Emacs-lisp ports. emulators Emulators for other operating systems. Terminal emulators do not belong here—X-based ones should go to x11 and text-based ones to either comms or misc, depending on the exact functionality. games Games. german German language support. graphics Graphics utilities. japanese Japanese language support. kde* Ports that form the K Desktop Environment (kde). korean Korean language support. lang Programming languages. mail Mail software. math Numerical computation software and other utilities for mathematics. mbone MBone applications. misc Miscellaneous utilities—basically things that doesn't belong to anywhere else. This is the only category that should not appear with any other non-virtual category. If you have misc with something else in your CATEGORIES line, that means you can safely delete misc and just put the port in that other subdirectory! net Miscellaneous networking software. news USENET news software. offix* Ports from the OffiX suite. palm Software support for the 3Com Palm(tm) series. perl5* Ports that require perl version 5 to run. plan9* Various programs from Plan9. print Printing software. Desktop publishing tools (previewers, etc.) belong here too. python* Software written in python. russian Russian language support. security Security utilities. shells Command line shells. sysutils System utilities. tcl75* Ports that use tcl version 7.5 to run. tcl76* Ports that use tcl version 7.6 to run. tcl80* Ports that use tcl version 8.0 to run. tcl81* Ports that use tcl version 8.1 to run. textproc Text processing utilities. It does not include desktop publishing tools, which go to print/. tk41* Ports that use tk version 4.1 to run. tk42* Ports that use tk version 4.2 to run. tk80* Ports that use tk version 8.0 to run. tk81* Ports that use tk version 8.1 to run. vietnamese Vietnamese language support. windowmaker* Ports to support the WindowMaker window manager www Software related to the World Wide Web. HTML language support belong here too. x11 The X window system and friends. This category is only for software that directly support the window system. Do not put regular X applications here. If your port is an X application, define USE_XLIB (implied by USE_IMAKE) and put it in appropriate categories. Also, many of them go into other x11-* categories (see below). x11-clocks X11 clocks. x11-fm X11 file managers. x11-fonts X11 fonts and font utilities. x11-toolkits X11 toolkits. x11-wm X11 window managers. 適切なカテゴリの選択 多くのカテゴリに重なるので, どれを '第一' カテゴリにするかを決めなければならないことが たびたびあるでしょう. これを うまく決めるルールがいくつかあります. 以下はその優先順のリストで, 優先度の高いものから 低いものの順に書いてあります. 言語特有のカテゴリがまず最初です. 例えば日本語の X11 のフォントをインストールする port の場合, CATEGORIES 行は japanese x11-fonts となるでしょう. より特徴的なカテゴリが, 一般的なカテゴリより 優先されます. 例えば, HTML エディタの場合は www editors となり, 逆順にはしないでください. また, port が mail, mbone, news, security, www のいづれかに属するとには, net は必要ありません. x11 を第2カテゴリにするのは, 第1カテゴリが自然言語の場合のみにしてください. 特に X のアプリケーションには x11 を指定しないでください. もし, あなたの port が他のどのカテゴリにも 属しないばあいには, misc にしてください. もし, あなたがカテゴリについて自信が持てない場合には, そのことを send-pr するときに 書き加えてください. そうすれば import するまえに それについて議論できます. (もしあなたが commiter であれば, そのことを &a.ports に送って, 先に議論 するようにしてください — 新しい port が間違ったカテゴリに import されて, すぐ移動されることが多いので.) このドキュメントと ports システムの変更 もしあなたが, たくさんの ports の保守を しているのであれば, &a.ports メーリングリストの内容を フォロウすることを考えてください. Ports のしくみについての重要な変更点はここに アナウンスされます. 最新の変更点については, いつでも, the bsd.port.mk CVS log で詳細な情報を得ることができます. + url="http://www.FreeBSD.ORG/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk"> the bsd.port.mk CVS log で詳細な情報を得ることができます. やっとおしまい! いやはや, 長い文章ですみません. ここまで読んでくださった方に は感謝, 感謝でございます. (_ _) さあ, portの作り方がわかったところで, 世界中のソフトウェア をport化しましょう. FreeBSDプロジェクトに貢献するには, それ がもっとも簡単な方法です! :) diff --git a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml index 690d88d88b..4955acad22 100644 --- a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml @@ -1,2528 +1,2569 @@ 開発の最前線: FreeBSD-current と FreeBSD-stable あるリリースから次のリリースまでの期間にも, FreeBSD の開発は 休みなく続けられています. この開発の最前線に興味を持っている人のために, 手元のシステムを最新の開発ツリーに同期させておくための, とても使いやすい仕掛けが何種類も用意されています. 注意: 開発の最前線は, 誰でもが扱えるという性質のものではありません! もしもあなたが, 開発途中のシステムを追いかけようか, それともリリース バージョンのどれかを使い続けようかと迷っているのなら, きっとこの章が参考になるでしょう. 最新のFreeBSDを追いかける 原作: &a.jkh;. 訳: &a.hanai; 6 November 1996. FreeBSD-current ってなに? FreeBSD-current とは，文字通りに，日々変更されている FreeBSD のソース のスナップショット以外の何ものでもありません． 中には現在開発途上の ソフトウェア, 実験的な変更, あるいは過渡的な機能などが含まれています. また, この中に入っている機能がすべて次の公式リリースに 入るとはかぎりません. FreeBSD-current をソースからほとんど毎日コンパイルしている人はたくさん いますが, 時期によっては FreeBSD-current はコンパイルさえできない状態に なっていることもあります. これらの問題は一般的には可能な限り素早く解決 されますが, FreeBSD-current のソースが不幸をもたらすか, それとも非常に 素晴らしい機能をもたらすかというのは文字通り, ある与えられた24時間の間 のどの部分であなたがソースを手に入れたか, による場合もあります. 誰が FreeBSD-current を必要としてるの? FreeBSD-current は, 主に次の三つの重要なグループを対象としています. ソースツリーのある部分に関して活発に作業している FreeBSD グループのメンバー. 彼らにとっては “最新のもの” にしておくのが 絶対に必要なことなのです． 活発にテストをする FreeBSD グループのメンバー. 彼らは, FreeBSD-current を “健全である” ことを出来るだけ確認するために種々の問題と戦うのに 時間を費やすのを厭わない人々です. 彼らはまた, 様々な変更に関する提案や FreeBSD の大まかな方向付けを行ないたいと思っている 人々でもあります. 単に, 様々な事に目を向け, 参考のために (例えば，動かすためではなく 読むため に) 最新のソースを使いたいと思って いる FreeBSD (または他の) グループのまわりにいるメンバー. これらの人々はまた, 時々コメントやコードを寄稿してくれます. FreeBSD-current に期待しては<emphasis>いけない</emphasis>ことは? なにか新しくカッコイイモノがあると聞き, 自分の周囲では 一番にそれを持ちたいがためにリリース前のコードの断片を 追いかけること. バグを修正するための素早い方法. 我々によって “公式にサポートされている” こと. 私たちは 3 つの “公式な” FreeBSD-current のグループの一つに実際に属する 人々を助けるのにベストを尽くしますが, 技術的なサポートを行なうには 単に「時間が足りない」のです. これは我々が外の人を助けるの好まない, ケチで意地悪い人間だと いうことではなく (もしそうなら FreeBSD なんかやっていません), 文字通り 我々は一日に 400 ものメッセージに答え かつ FreeBSD の作業をする ことなど出来ない! ということなのです. もし, たくさんの質問に答えるか, それとも FreeBSD を良くする作業を続けるかという選択が与えられた場合, あなた方のほとんどは後者を支持する, と私は確信しています. FreeBSD-current を使う &a.current;と&a.cvsall;に加わって下さい. これは単に良い考えであるというだけでなく, 必須のことなのです. もし FreeBSD-current メーリングリストに入っていなければ, 様々な人がシステムの現在の状態について 述べているコメントを決して見ることは ありませんし, 従って他の人が既に見つけて解決している多くの問題に 戸惑っ てあきらめてしまうでしょう. さらに言うと, システムを正常に保つための 重要な情報を見逃してしまう可能性もあります. cvs-all メーリングリストでは, それぞれの変更についての commit ログを見ることができますし, それに関して起こり得る副作用の情報を得ることができ, もう一つの加わるに値するメーリングリストです. これらのメーリングリストに入るには, &a.majordomo; へ subscribe freebsd-current subscribe cvs-all と書いたメールを送って下さい. オプションとして本文に help と書けば, Majordomo はあなたへ我々がサポ ートする様々なメーリングリストに参加 / 脱退する方法に関する詳しい ヘルプを送ります. ftp.FreeBSD.ORG からのソースの入手. 以下の3つの方法で行なうこと が出来ます. 下に述べられているCTMを用いる. 均一なレートの, 良質の TCP/IP 接続を持っていない人には, これが一番いい方法でしょう. cvsup を この supfile を用いて使用する. これは 2 番目に推薦される方法です. なぜなら, cvsup によって一度全体 を入手し, 後は変更されたところだけを入手することが 出来るからです. たくさんの人が自動的にソースを最新のもに保つために cvsup を cron から起動しています. これを行なうための非常に簡単な 方法は, 単に - &prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz +
&prompt.root; pkg_add -f \ +ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
とタイプすることです. ftp を使う. FreeBSD-current のソースツリーは常に ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current に “公開” されています. 我々はまた全体を compress/tar して入手できる wu-ftpd を使ってい ます. 例えば, usr.bin/lex があったとすると, ftp> cd usr.bin ftp> get lex.tar.Z とすることにより, ディレクトリ全体(この場合, usr.bin/lex以下全体) を compress された tar ファイルとして入手することができます. 以上のことをまとめると, 必要に応じて迅速なアクセスをする必要があり, 接続のバンド幅が問題ではなければ cvsup か ftp を使いましょう. そうではなければ CTM を使いましょう. もしソースを, 眺めるだけでなく走らせるために入手しているので あれば, 一部だけ選ぶのではなく, current の全体を手に入れてください. なぜなら, ソースの様々な部分が他の部分の更新に依存しており, 一部のみを コンパイルしようとすると, ほぼ間違いなくトラブルを起こすからです. current をコンパイルする前に /usr/src にある Makefile をよく読んでください. アップグレードの処理の一部として, 少なくとも一回は最初に make world を行なうべきでしょう. &a.current; を読めば, 次のリリースへ向けて, 時々必要になる 他のブートストラップの方法に関して 常に最新情報を得ることが出来ます. アクティブになって下さい! もし FreeBSD-current を走らせているなら 我々はそれに関するコメント, 特に拡張やバグ潰しに関する提案, を欲して います. コードを伴う提案はもっとも歓迎されるものです! FreeBSD の安定状態の持続 原作: &a.jkh;. 訳: &a.jp.iwasaki;. FreeBSD-stable ってなに? FreeBSD-stable は, 次の本流のリリースを目指した新機能をあまり採り入 れない保守的な変更のための開発の支流です. 実験的またはテスト未完の変更 はこの支流には取り入れられません (最新の FreeBSD を追いかける 参照). 誰が FreeBSD-stable を必要としているの? もしあなたが仕事で使用しているとか, なによりも FreeBSD システムの安 定性を最重要視するなら, stable を追いかけることを考えるべきで しょう. stable の支流は前のリリースに関して効果的にバグフィッ クスされた流れであるため, 最新のリリース ( &rel.current;-RELEASE 執筆時点) をインストールしているのであれば, 特に そうです. stable ツリーが常に完全に互換性があり安定するように努力し ていますが, たまに間違いがあることに注意してください (結局, 内容が吟味 されずに素早く送られた変更を含むソースがまだあるのです). また, current を stable へ移行する前に完璧なテストフィック スに最善を尽くしますが, 私たちのテストはすべてのケースを十分に網羅して いるとは限りません. もし何か stable で不具合があるようでした ら, 私たちにすぐに教えてください (次の節参照). FreeBSD-stable を使う &a.stable; へ加わってください. このメーリングリスト では, stable の構築に関連する事柄や, その他の注意すべき点 に関する情報が流れています. また開発者は議論の余地がある修正や変更 を考えている場合に, このメーリングリストで公表し, 提案された変更に 関して問題が生じるかどうかを返答する機会を ユーザに与えます. また, cvs-all メーリングリストでは, それぞれの変更がなされると 起こりうる副作用に関するすべての適切な情報と一緒に commit log を 読むことができます. subscribe しておきたいもう一つのメーリングリストです. メーリングリストに参加するには, &a.majordomo へメッセージの本文に 次のように書いたメールを送ってください: subscribe freebsd-stable subscribe cvs-all オプションとして本文に `help' と書けば, Majordomo は私たちがサポー トする様々なメーリングリストに参加 / 脱退する方法に関する詳しいヘ ルプを送付します. もし, あなたが新しいシステムを可能な限り -stable に近いものにインストールしようとする場合には, 最新のブランチの snapshot を ftp://releng3.freebsd.org/pub/FreeBSD から取得し, これを一般のリリースのものと同様に インストールしてください. もし, 既に 2.2 系列の前のリリースが動いている場合で, これをソースからアップグレードしようとするならば, ftp.FreeBSD.ORG より簡単に これを行う事が出来ます. これには次の 3つの方法があります. CTM 機能を使用する. 転送レートが 安定している TCP/IP 接続でない場合は, この方法が適して います. cvsup を この supfile を用いて使用する. 一度コレクション全体を入手してしまえば, 前回からの変更部分だけですむので, 2 番目に推奨される方法です. 多くの人が cron から cvsup を実行し, 自動的にソースコー ドを最新の状態に保っています. これを簡単に扱うには次のようにタイプしてください. - &prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz +
&prompt.root; pkg_add -f \ +ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
 ftp を使用する. FreeBSD-stable 用のソースツリーは 常に次のところで“公開”されています : ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-stable 私たちはまた, tar/compress でツリー全体を入手できる wu-ftpd を使用しています. 例えば : usr.bin/lex に対して: ftp> cd usr.bin ftp> get lex.tar.Z とすることにより, ディレクトリ全体を compress された tar ファイルとして入手することができます. 基本的には, ソースに迅速でオンデマンドなアクセスが必要で, 接続のバンド幅が問題でなければ, cvsup か ftp を使いましょう. そうで ない場合は CTM を使いましょう. stable をコンパイルする前に, /usr/src にある Makefile をよ く読んでください. 少なくとも一回はアップグレードの処理の一部として 最初に make world を実行するべきでしょう. &a.stable; を読めば, 次のリリースに移行する に当たって時々必要となる既存システムからの 新システムの構築手順に ついての最新情報が得られるでしょう. インターネットを通じたソースツリーの同期 原作: &a.jkh;. 訳: &a.jp.iwasaki;. 13 September 1997. インターネット接続 (または電子メール) を使用して, あなたの興味の対 象によって FreeBSD プロジェクトのソースのある一部分または全体の最新を 追いかける方法は色々あります. 私たちが提供している基本的なサービスは Anonymous CVS, CVSup と CTM です: Anonymous CVS と CVSup は pull 同期モデルを採用しています. CVSup の場合, ユーザ (または cron スクリプト) が cvsup 起動し, どこかにある cvsupd サーバとやりとりしてファイルを 最新状態にします. 届けられる更新情報はその時点の最新のものであり, また必要な時にだけ取り寄せられます. 興味のある特定のファイルやディレクトリに 限定して更新することも簡単にできます. クライアント側のソースツリーの状態・ 設定ファイルの指定に従い, サーバによって更新情報が 素早く生成されます. Anonymous CVS は, このプログラムがリモートの CVS リポジトリから直接変更点を pull できるようにした &man.cvs.1; への拡張であるという点で, CVSup よりもずっと単純です. CVSup は効率の点ではるかにまさっていますが, Anonymous CVS の方が簡単に利用できます. 一方, CTM はあなたが持っているソースとマスタアーカイブ上に あるそれとの対話的な比較をおこないませんし, あるいは向こう側から変更点を pull したりもしません. そのかわりに, 前回の実行時からの変更を認識するスクリプトが マスタ CTM マシン上で一日に数回実行され, すべての変更を compress して通し番号を振り, さらに電子メールで転送できるようにエンコードします (印字可能な ASCII キャラクタのみです). 受信した後は, これらの “CTM のデルタ” は自動 的にデコード, 検査してユーザのソースのコピーに変更を適用する &man.ctm.rmail.1; によって処理可能となります. この処理は CVSup や Anonymous CVS よりずっと効率 的であり, pull モデルというよりむしろ push モデルで あるため, 私たちのサーバ資源の負荷は軽くなります. もちろん他のトレードオフもあります. うっかりアーカイブ の一部を消してしまっても, CVSup は壊れた部分を検出して再構築してくれます. CTM はこれをやってくれませんし, Anonymous CVS はおそらく他の何よりも深く混乱してしまうことが多いでしょう. もしソースツリーの一部を消してしまったら, (最新の CVS “ベースデルタ”から) 一からやり直し, CTM か anoncvs を使って悪い部分を消去し, 再同期させることによって すべてを再構築しなければなりません. Anonymous CVS, CTM, CVSup についての 詳しい情報については, 以下の節を参照してください: Anonymous CVS 原作: &a.jkh; 訳: &a.jp.sugimura;. 19 July 1998. <anchor id="anoncvs-intro">導入 Anonymous CVS (もしくは, anoncvs として知られています) は離れたところにある CVS リポジトリと同期を取るために FreeBSD に付属している CVS ユーティリティに含まれている機能です. 他にもありますが, それは FreeBSD のユーザが, 特別な権限なしに FreeBSD プロジェクトの公式な anoncvs サーバに読み取り専用で CVS の操作をすることができるようにするためのものです. それを使うには, 単に CVSROOT 環境変数を設定して適切な anoncvs サーバを指定し, そして &man.cvs.1; コマンドを使って手元にある リポジトリのようにアクセスするだけです. CVSup と anoncvs のサービスは本質的に同じ機能ではないか ということも言われていますが, ユーザが同期を取る方法を選ぶときに影響を与えるような さまざまなトレードオフが存在します. 要約して言えば, CVSup はネットワーク資源の使い方においては非常に効率がよく, またはるかに技術的に洗練されたものですが, 相当な手間がかかります. CVSup を使うには, 特別なクライアントをまずインストールして設定しなくては 1bit も取ってくることができず, またそのとき CVSup では collections と呼んでいるかなり大きなかたまりだけからしか 取ってこれません. それに対して anoncvs では, CVS モジュールの名前を指定することで特定のプログラムの (ls や grep のような) 個々のファイルから調べることができます. もちろん, anoncvs は CVS リポジトリの読み取り専用の操作に対してのみ適しているので, もしあなたが FreeBSD プロジェクトのものと共有されたなにか ローカルなリポジトリを作ってそこでの開発を 行おうというときには, CVSup だけが唯一の手段となってしまいます. <anchor id="anoncvs-usage">Anonymous CVS を使う &man.cvs.1; を設定して Anonymous CVS リポジトリを使うには単に CVSROOT 環境変数を設定して FreeBSD プロジェクトの anoncvs サーバを指定するだけのことです. この文書を書いているときには, 次のサーバが利用できるようになっています. USA: anoncvs@anoncvs.freebsd.org:/cvs CVS はかつて存在した (もしくは, 時にはこれから存在するものも :) ほとんどどんなバージョンの FreeBSD のソースを “check out” することができますが, あなたは &man.cvs.1; の リビジョン () のオプションや FreeBSD プロジェクトのリポジトリの中で それをどのように指定したらいいものかということを よく知っておく必要があります. タグには 2 種類あって, リビジョンタグとブランチタグがあります. リビジョンタグは特定の改訂版を指しており, それはいつも同じものを意味しています. 一方ブランチタグは, 指定されたときの指定された開発の流れにおける 最も新しい改訂版を示しています. ブランチタグは特定の改訂版を指していないために, その意味はきょうと明日では違うものになっているでしょう. ユーザが興味を持つであろうブランチタグの一覧です. HEAD 主要部をなす流れ, すなわち FreeBSD-current のための名前です. また, どのリビジョンも 指定されなかったときにはこれになります. RELENG_3 FreeBSD-3.x の開発のための流れです. FreeBSD-stable としても知られています. ports コレクションには無効です. RELENG_2_2 FreeBSD-2.2.x の開発のための流れです. 2.2-stable - としても知られています. ports + としても知られています. このブランチは大部分が + すたれています. ports コレクションにはふさわしくありません. RELENG_2_1_0 FreeBSD-2.1.x の開発のための流れです - このブランチは大部分がすたれています. ports コレクションにはふさわしくありません. ユーザが興味を持つであろうリビジョンタグの一覧です. + + RELENG_3_1_0_RELEASE + + FreeBSD-3.1. ports + コレクションにはふさわしくありません. + + + + + RELENG_3_0_0_RELEASE + + FreeBSD-3.0. ports + コレクションにはふさわしくありません. + + + + + RELENG_2_2_8_RELEASE + + FreeBSD-2.2.8. ports + コレクションにはふさわしくありません. + + + + + RELENG_2_2_7_RELEASE + + FreeBSD-2.2.7. ports + コレクションにはふさわしくありません. + + + RELENG_2_2_6_RELEASE FreeBSD-2.2.6. ports コレクションにはふさわしくありません. RELENG_2_2_5_RELEASE FreeBSD-2.2.5. ports コレクションにはふさわしくありません. RELENG_2_2_2_RELEASE FreeBSD-2.2.2. ports コレクションにはふさわしくありません. RELENG_2_2_1_RELEASE FreeBSD-2.2.1. ports コレクションにはふさわしくありません. RELENG_2_2_0_RELEASE FreeBSD-2.2.0. ports コレクションにはふさわしくありません. RELENG_2_1_7_RELEASE FreeBSD-2.1.7. ports コレクションにはふさわしくありません. RELENG_2_1_6_1_RELEASE FreeBSD-2.1.6.1. ports コレクションにはふさわしくありません. RELENG_2_1_6_RELEASE FreeBSD-2.1.6. ports コレクションにはふさわしくありません. RELENG_2_1_5_RELEASE FreeBSD-2.1.5. ports コレクションにはふさわしくありません. RELENG_2_1_0_RELEASE FreeBSD-2.1.0. ports コレクションにはふさわしくありません. ブランチタグを指定したときには, 普通はその開発の流れにおける 最も新しいバージョンのファイルを受け取ることができます. もし以前のバージョンのものが欲しいときには, 日付を オプションを使って指定すればよいです. 例 本当はなにかする前には &man.cvs.1; のマニュアルページの全体を ちゃんと読んでからのほうがいいのですが, Anonymous CVS の使い方の本質的なところを簡単に例を挙げて説明します. -current (ls(1)) をちょっと確認してから消してみます. &prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs &prompt.user; cvs co ls &prompt.user; cvs release -d ls ls(1) のバージョンを 2.2-stable ブランチから調べてみます. &prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs &prompt.user; cvs co -rRELENG_2_2 ls &prompt.user; cvs release -d ls - FreeBSD 2.2.2 と FreeBSD 2.2.6 とで ls(1) - の変更点のリストを (unidiff で) 作ってみます. + ls(1) の変更点のリストを (unidiff で) 作ってみます. &prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs &prompt.user; cvs rdiff -u -rRELENG_2_2_2_RELEASE -rRELENG_2_2_6_RELEASE ls 他のどんなモジュールの名前が 使われているか検索してみます. &prompt.user; setenv CVSROOT anoncvs@anoncvs.freebsd.org:/cvs &prompt.user; cvs co modules &prompt.user; more modules/modules &prompt.user; cvs release -d modules 他の資料 次の資料は CVS を学ぶのに役に立つでしょう. CVS チュートリアル. Cal Poly によります. Cyclic Software, 商用として CVS を維持しています. CVSWeb は FreeBSD Project の CVS のための web インターフェースです. <application>CTM</application> 原作: &a.phk;. 更新: 19-October-1997. 訳: &a.hanai; 13 September 1997. CTM はリモートのディレクトリツリーを中央のツリーに同期させるための 手段です. これはFreeBSDのソースツリーの配布を行なうために開発されまし たが, 時が経つにつれて別の目的にも有用であることがわかるかも しれません. デルタを作り出す処理に関するドキュメントは現在ほとんど ありません. 従って, もしあなたがCTM を他のことに使いたいなら &a.phk;にさらなる情報を問い合わせてください. なぜ<application>CTM</application>を使うの? CTM を使うことにより FreeBSD ソースツリーのローカルコピー を手にいれることができます. ソースツリーが使えることの魅力は数多くあります. 完全な cvs ツリーを追いかけるにしても, ひとつのブランチを追いかける にしても CTM は必要な情報を与えてくれます. もしあなたがFreeBSDのアクティブな開発者であるにもかかわらず お粗末なTCP/IP接続しか持っていなかったり, またはTCP/IP接続が 行なえないとしたら, あるいは単に変更が自動的に送られてきて ほしいというのであれば CTM はそんなあなたのために 作られたのです. アクティブなブランチでは 1 日に最大三つまでのデルタを受け取る必 要があります. これが自動的に e-mail で送られてくるという方法を ぜひ検討してみてください. デルタのサイズは常にできるだけ小さく保たれています. 大抵の場合5KBよりも小さく, たまに(10回に1回程度)10-50KBになり, ときおり100KBかもっと大きくなる でしょう. 開発ソースから直接に得られたものを使うことについては, あらかじめ パッケージにされたリリースとは違い, いろいろと注意することが あります. これは特に “current” のソースを選んでいるときは 重要です. 最新の FreeBSD を追いかけるを読むことを お勧めします. <application>CTM</application>を使うには何が必要? 二つのものが必要でしょう: CTM プログラムとそれに与える (“current” レベルを得るための)最初のデルタです. CTM プログラムはバージョン2.0のリリース以来FreeBSDの一部にな りました. もしソースのコピーを持っているなら /usr/src/usr.sbin/CTMにあります. もしFreeBSDの2.0以前のバージョンなら, 最新のCTMのソースを直接 ftp://ftp.FreeBSD.ORG/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm から入手できます. CTM に与える “デルタ” は二つの方法, FTPまたはe-mail, で得ること ができます. もしインターネットにFTPアクセスできるなら, 次のFTPサイト: ftp://ftp.FreeBSD.ORG/pub/FreeBSD/CTM または, その ミラーサイト が CTM へのアクセスをサポートします. 適切なディレクトリに FTP して README ファイルを入手し, そこから スタートしてください. e-mail によってデルタを得たいという場合は: CTM 配布メーリングリストのいずれかに参加するために &a.majordomo; へ subscribe のメールを送ってください. “ctm-cvs-cur” は完全な cvs ツリー をサポートします. “ctm-src-cur” は開発先端ブランチをサポートします “ctm-src-2_2” は 2.2 リリースのブランチのサポートです. (もしmajordomoを使って参加する方法を知らない のであれば, 最初にhelp という語を含むメッセージを送ってください. — 使い方の説明が送られてくるでしょう.) メールで CTM による更新ファイルを受け取り始めると, 中身を取り出して使用 するために ctm_rmail プログラムを使うかもしれません. それを完全 に自動で行ないたいなら, /etc/aliases から ctm_rmailプロ グラムを直接使うこともできます. さらに詳しいことはctm_rmail manページを御覧ください. CTM デルタを得るためにどの方法を使うのであっても, ctm-announce@FreeBSD.ORG メーリングリストに参加するべきです. このメーリングリストは将来的には CTMシステムの操作に関する アナウンスがポストされる唯一の場になるでしょう. メーリングリストに加わるためにはsubscribe ctm-announce と書いた一行だけのメールを &a.majordomo; へ送ってください. はじめて<application>CTM</application>を使い始める CTM デルタを使い始めるためには, これは以降作られる全ての デルタの出発点を手にいれる必要があります. 最初にあなたが何をすでに持っているかをはっきりさせましょう. すべての人は “空”のディレクトリから始めなければなりません. ツリーをサポートしてるあなたの CTM を稼働するためには 指定した“空” のデルタを使う必要があります. いくつかの分岐点 では, あなたの都合により CD 内に分配されている“スタータ” デルタを使用できるようになっています. しかしながら, これは 頻繁に行われることではありません. 適切な出発点が決まれば, その出発点を CTM が 維持するツリーへ変換するための “スタータ” 初期デルタを使う必要が あります. 移行デルタは番号の後ろに X をつけたものがそうです (たとえばsrc-cur.3210XEmpty.gz). X の後ろは最初の開始ポイントに対応します. Empty は 空のディレクトリです. ルールとして Empty からの移行デルタは 100 デルタごとに 作られます. ところで, これらは非常に大きいです! XEmptyのデルタは 数十MBの gzip で圧縮されたデータというのが普通です. 一度スタートするためのベースデルタを得ると, それに続く多数の 全てのデルタも必要になるでしょう. <application>CTM</application>を日常で使う デルタを適用するためには, 単に &prompt.root; cd /where/ever/you/want/the/stuff &prompt.root; ctm -v -v /where/you/store/your/deltas/src-xxx.* とします. CTM はどれがgzipされているか理解します. 従って最初に gunzipしておく必要はありません. ディスクの節約にもなります. 全体の処理に関して確信するまでは CTM は(ソース)ツリーに対して 何もしません. また, デルタを確かめるためには フラグを使うことができます. このフラグがあると CTM はツリーに対して実際には何も行ないません. 単にデルタの完全性を確認し, 現在のツリーに問題なく使用できるかを確認 するだけです. CTM には他にもオプションがあります. 詳細に関しては マニュアルページを参照するかソースを見てください. もし誰かが “ユーザ インターフェース” の部分に関して助けてくれるなら 私はとても嬉しいです. なぜならどういうオプションが何を, どのよう に, いつ行なうようにするべきか決めかねているからです. 以上でやることは本当に全部です. 新しいデルタを入手した時には, ソースを最新のものにするためにそれを CTMに通すだけです. もしデルタを再ダウンロードするのが 骨の折れる作業であれば, デルタを 消さないでおいてください. なにかおかしなことが起こった場合には置いておけば良かった と思うかもしれません. もしフロッピーディスクしか持っていない状況 であってもコピーを取るのに fdwriteを使うことを考えてください. ローカルの変更を保存する 開発者としてはソースツリー中のファイルを 使って実験したり変更したく なるものです. CTM はローカルの変更を制限つきでサポートします: ファイル foo の存在をチェックする前に, foo.ctm を参照しにいきます. このファイルが存在する場合, CTM は foo の代りにこれを処理します. この動作はローカルの変更を保持する簡単な手段を 提供します: 単に変更したいファイルを拡張子 .ctm 付きのファイル名で コピーするだけです. あとは自由にコードをハックでき, .ctm ファイルの方は CTM が最新状態に保ってくれます. <application>CTM</application> のその他の面白いオプション 更新で変更されるファイルを正確に知る CTM のソースリポジトリに対する変更のリストを オプションを使って決定することができます. これは, 変更のログを保存したい, 変更されたファイルをなんらかの方法で 前・後処理したい, または単にこだわりたい :-) 場合には, 役に立つでしょう. 更新前にバックアップを取る CTM の更新によって変更されるファイルすべてのバックアップを 取りたくなることがあります. オプションを指定すると CTM は デルタで変更されるファイルすべてを backup-file としてバックアップするようになります. 更新で変更されるファイルを制限する CTM の更新の範囲を制限したり一連のデルタのから ほんの数ファイルを 抽出したくなることがあります. と オプションを用い正規表現を 指定することで, CTM が処理するファイルのリストを制御することが できます. 例えば, lib/libc/Makefile の最新のコピーを保存してある CTM デルタのコレクションから抽出するには, 以下のコマンドを実行します. &prompt.root; cd /where/ever/you/want/to/extract/it/ &prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* CTM デルタで指定されたファイルごとに, そして オプションがコマンドラインで指定された順序で 適用されます. すべての そして オプションが適用された後に更新対象と選択された場合に限り, CTM はそのファイルを処理します. <application>CTM</application>の将来計画 重要なもの なんらかの CTM システムへの認証機構を用い, 不正な CTM の更新の 検出を可能とする. CTM へのオプションを整理する. さもないと混乱し, 直観に反したもの になります. 残念なことに私は非常に忙しいです. 従ってこれを行なうどんな手助け でも歓迎します. その際, 自分が何をやりたいかを私に 言うのを忘れずに. その他 “DESに染まった” (例えば, 国外への持ち出しが規制された)ソースは まったく含まれません. 手に入るのは“国際”バージョンだけです. もし興味のある人が多いようであれば, 我々はsec-curシーケンスも セットアップするつもりです. ports コレクションに対するデルタのシーケンスもあります. しかし, まだあまり興味は持たれていないようです. もしこれに対するメーリング リストが欲しい時も私に言ってください. 我々はセットアップすることを 考えます. ありがとう! &a.bde; - 辛辣なペンと価値のないコメントに対して. + 鋭い記述とすばらしいコメントに対して. &a.sos; よく辛抱してくれました. Stephen McKay ctm_[rs]mailを書いてくれました. とても感謝して います. &a.jkh; 彼が頑固として譲らなかったため, 私もこの CTM をもっと良いものに しないわけにはいきませんでした. 彼の頑固さに感謝します. ユーザの人みんな 気に入ってくれることを願っています... <application>CVSup</application> 原作: &a.jdp;. 訳: &a.jp.iwasaki;. 27 February 1997. <application>CVSup</application> の紹介 CVSup は, リモートのサーバホストにあるマスタ CVS リポジトリから ソースツリーを配布し更新するための ソフトウェアパッケージです. FreeBSD のソースは, カリフォルニアにある中心的な開発マシンの CVS リポジトリの 中でメンテナンスしています. CVSup を使用することで, FreeBSD ユーザは 簡単に自分のソースツリーを最新の状態に しておくことができます. CVSup は pull モデルとよばれる更新のモデルを採用しています. pull モデルでは, 各クライアントが更新したい場合に更新したい時点で, サーバに更新の問い合わせをおこないます. サーバはクライアントからの 更新の要求を受け身の状態で待ちます. したがって, すべての更新は クライアント主導でおこなわれます. サーバは頼まれもしない更新情報を 送るようなことはしません. ユーザは CVSup クライアントを手動で実行して 更新をおこなうか, cron ジョブを設定して定期的に自動実行する必要があります. 用語 CVSup のように大文字で表記しているものは, ソフトウェアパッケージ 全体を指します. 主な構成物は, 各ユーザマシンで実行するクライアントである cvsup, FreeBSD の各ミラーサイトで実行するサーバ cvsupd です. FreeBSD の文書やメーリングリストを読んだ際に, sup についての言及を 見かけたかもしれません. sup は CVSup の前に存在していたもので, 同様の 目的で使われていました. CVSup は sup と同じように使用されており, 実際, sup と互換性のあるコンフィグレーションファイルを使用します. CVSup の方がより高速で柔軟性もあるので, もはや sup は FreeBSD プロジェクトでは使用されていません. <application>CVSup</application> のインストール FreeBSD 2.2 以降を使用している場合, CVSup をインストールするもっとも 簡単な方法は, FreeBSD ports コレクション の port または対応する バイナリ package を使うことです. どちらを使うかは, CVSupを自分で作りたいかどうかによります. FreeBSD-2.1.6 または 2.1.7 を使用している場合は, 残念ながら FreeBSD-2.1.{6,7} には存在しないバージョンの C ライブラリが必要となるため バイナリ package は使用できません. しかし, port は FreeBSD 2.2 とまったく同じように 簡単に使うことができます. 単に tar ファイルを展開し, cvsup ディレクトリへ cd して make install とタイプするだけです. CVSup は Modula-3 で書かれているため, package と port 両方とも Modula-3 ランタイムライブラリが インストールされていることが必要です. これらは port の lang/modula-3-lib および package の lang/modula-3-lib-3.6 にあります. これらのライブラリの port や package に対して cvsup と同じ管理方法を取っていれば, CVSup の port や package をインストールする際に, これらのライブラリも自動的に コンパイルそして/またはインストールされます. Modula-3 ライブラリはかなり大きく, これらの転送やコンパイルはすぐに 終わるものではありません. この理由から, 三つめの選択肢が提供されています. 以下のアメリカ合衆国にある配布サイトのどちらからでも, FreeBSD 用の スタティックリンクされた CVSup 実行形式が入手可能です: ftp://ftp.freebsd.org/pub/FreeBSD/development/CVSup/cvsup-bin-16.0.tar.gz (GUI 込みのクライアント). ftp://ftp.freebsd.org/pub/FreeBSD/development/CVSup/cvsup.nogui-bin-16.0.tar.gz (GUI なしのクライアント). ftp://ftp.freebsd.org/pub/FreeBSD/development/CVSup/cvsupd-bin-16.0.tar.gz (サーバ). また, 世界中にあるたくさんの FreeBSD FTP ミラーサイト からも入手可能です. : ほとんどのユーザはクライアントのみが必要になるでしょう. これらの 実行形式は完全に自己完結しており, FreeBSD-2.1.0 から FreeBSD-current までの, どのバージョンでも動作します. まとめると, CVSup をインストールするための選択肢は以下の通りです: FreeBSD-2.2以降: スタティックバイナリ, port, package FreeBSD-2.1.6, 2.1.7: スタティックバイナリ, port FreeBSD-2.1.5 以前: スタティックバイナリ <application>CVSup</application> のコンフィグレーション CVSup の動作は, supfile と呼ばれるコンフィグレーションファイルで 制御します. FreeBSD-2.2 からは, supfile のサンプルがディレクトリ /usr/share/examples/cvsup の下にあります. 2.2 以前のシステムを 使用している場合は, これらの サンプルを ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/share/examples/cvsup/ から入手することができます. supfile には以下の cvsup に関する質問への答えを記述します: どのファイルを受け取りたいのか? どのバージョンのものが欲しいのか? どこから入手したいのか? 自分のマシンのどこに置きたいのか? どこに status ファイルを置きたいのか? 次のセクションで, これらの質問に順番に答えながら典型的な supfile を組み立てていきます. 最初に supfile の全体構造を説明します. supfile はテキストファイルです. コメントは # から行末までです. 空行とコメントだけの行は無視します. 残りの各行には, ユーザが受け取りたいファイル群について記述します. 行の始めは, サーバ側で定義した論理的なファイルのグループである “コレクション”の名称です. コレクションの名称を指定して, 欲しいファイル群を サーバに伝えます. コレクション名の後には, ホワイトスペースで区切られた 0個以上のフィールドが続きます. これらのフィールドが上記の質問に対する 答えになります. フィールドには 2種類あります: flag フィールドと value フィールドです. flag フィールドは delete や compress のような 単独のキーワードから成ります. また, value フィールドもキーワードで 始まりますが, キーワードの後にはホワイトスペースは入らず, = と 二つめの単語が続きます. 例えば, release=cvs は value フィールドです. 通常, supfile には受け取りたいコレクションを一つ以上指定します. supfile を組み立てる一つの方法として, コレクション毎にすべての関係の あるフィールドを明示的に指定する方法があります. しかし, これでは supfile のすべてのコレクションに対して ほとんどのフィールドが同じになるため, 行が非常に長くなってしまい不便になります. これらの問題を避けるため, CVSup ではデフォルトを指定することのできる メカニズムが提供されています. 特殊な擬似コレクション名 *default で始まる行は, supfile 中の後続の コレクションに対して使用する flag フィールドと value フィールドの デフォルトを設定するために利用できます. 個々のコレクションで固有の値を 指定すると, デフォルト値を無効にできます. また 行を追加すると, supfile の途中からデフォルト値の変更や追加が可能になります. これまでの予備知識を基に, FreeBSD-current のメインのソースツリーを受け取って更新するための supfile を 組み立ててみましょう. どのファイルを受け取りたいのか? CVSup を通して入手できるファイルは “コレクション” と呼ばれる名前の付けられたグループにまとめられています. 利用可能なコレクションについては ここ で説明しています. ここでは, FreeBSD システムのメインのソースツリー全体 を受け取るための設定例を紹介します. 輸出規制されている暗号化サポートの コード以外のすべてを含む src-all という 単一の大きなコレクションがあります. この例では私たちがアメリカ合衆国か カナダにいるものと仮定します. その場合, cvs-crypto という一つの付化的な コレクションで暗号化コードを入手することができます. supfile を組み立てる最初のステップとして, これらのコレクションを一行に一つづつ 記述します: src-all cvs-crypto どのバージョンのものが欲しいのか? CVSup を使用すると, かつて存在していたことのある, 事実上どのバージョンの ソースでも受け取ることができます. これは cvsupd サーバがすべてのバージョンを含む CVS リポジトリに基づいて動作することにより, 実現されています. tag= および の value フィールドを使用して, 欲しいバージョンの 一つを指定します. tag= のフィールドの指定は正確に行うように十分注意 してください. いくつかのタグは特定のコレクションに 対してのみ有効です. タグの綴りが違っていたり不適切なタグを指定すると, CVSupはユーザが消し たくないファイルまで削除してしまいます. 特に ports-* のコレクション に対しては tag=. だけ を指定するようにしてください. tag= フィールドはリポジトリ中のシンボリックタグを指定します. tag には revision tag と branch tag の二種類があります. revision tag は特定のリビジョンを指します. これは, 毎日同じ状態に保つことになります. 一方 branch tag は, ある時点での開発分流の最新のリビジョンを指します. branch tag は特定のリビジョンを指定している訳ではないので, 今日と明日では 異なるリビジョンを参照することになるかもしれません. 以下はユーザが興味を持っていると思われる branch tag です: tag=. メインの開発分流であり, FreeBSD-current として知られています. 注意: . は句読点ではありません. tag の名称です. このタグの指定は総ての コレクションに対して有効です. tag=RELENG_3 FreeBSD-3.x 用の開発分流であり, FreeBSD-stable として知られています. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_2 FreeBSD-2.2.x 用の開発分流であり, 2.2-stable として知られています. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_1_0 FreeBSD-2.1.x 用の開発分流です. この分流はほとんど利用されていません. このタグの指定は ports-* のコレクションに対しては無効です. 以下はユーザが興味を持っていると思われる revision tag です: + tag=RELENG_3_1_0_RELEASE + + FreeBSD-3.1. このタグの指定は ports-* + のコレクションに対しては無効です. + + + tag=RELENG_3_0_0_RELEASE FreeBSD-3.0. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_2_8_RELEASE FreeBSD-2.2.8. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_2_7_RELEASE FreeBSD-2.2.7. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_2_6_RELEASE FreeBSD-2.2.6. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_2_5_RELEASE FreeBSD-2.2.5. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_2_2_RELEASE FreeBSD-2.2.2. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_2_1_RELEASE FreeBSD-2.2.1. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_2_0_RELEASE FreeBSD-2.2.0. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_1_7_RELEASE FreeBSD-2.1.7. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_1_6_1_RELEASE FreeBSD-2.1.6.1. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_1_6_RELEASE FreeBSD-2.1.6. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_1_5_RELEASE FreeBSD-2.1.5. このタグの指定は ports-* のコレクションに対しては無効です. tag=RELENG_2_1_0_RELEASE FreeBSD-2.1.0. このタグの指定は ports-* のコレクションに対しては無効です. tag 名を示した通りにタイプされているか十分注意してく ださい. CVSup は tag 名が正しいかどうかを見分けることはできません. tag が間違っていた場合, たまたまファイルがまったく存在しない正しい tag が 指定されたものとしてCVSup は動作します. その場合は, 現在あるソースが削 除されるでしょう. branch tag を指定した際には, 通常はその開発分流の最新バージョンの ファイルを受け取ります. いくらか前のバージョンを受け取りたい場合は, の value フィールドを使って日付を指定することで, これを実現することが できます. &man.cvsup.1; のマニュアルページで, その方法を説明しています. 例として, FreeBSD-current を受け取りたいとします. 次の行を supfile の始めに追加します: *default tag=. tag= フィールドも date= フィールドも指定しなかった場合に 動き出す重要な特殊なケースがあります. そのケースでは, 特定のバージョンの ファイルを受け取るのではなく, サーバの CVS リポジトリから実際の RCS ファイルを直接受け取ります. 一般的に開発者はこの処理のモードが 好きなようです. 彼らのシステム上にリポジトリそのものの コピーを維持することで, リビジョン履歴を閲覧し過去のバージョンの ファイルを検査できるようになります. しかし, これには大きなディスクスペースが必要になります. どこから入手したいのか? 更新情報をどこから入手するかを cvsup に伝えるために host= フィールドを使用します.CVSup ミラーサイト のどこからでも入手できますが, ネット上での最寄りのサイトを選ぶべきでしょう. この例では, 仮想上の FreeBSD 配布サイト cvsup666.FreeBSD.org を使用します: *default host=cvsup666.FreeBSD.org CVSup を実行する前にホスト名を 実在のものに変更する必要があります. どのように cvsup を実行しても, この設定は を 使用してコマンドラインで変更することができます. 自分のマシンのどこに置きたいのか? prefix= フィールドは, cvsup に受け取ったファイルをどこに置くかを 伝えます. この例では, ソースファイルを直接メインのソースツリー /usr/src に置きます. src ディレクトリはすでにファイルを受け取るために 選択したコレクションで暗黙に指定しているので, これは正しい仕様となります: *default prefix=/usr どこに status ファイルを置きたいのか? cvsup クライアントは “base” ディレクトリと呼ばれる場所に, ある status ファイルを維持しています. すでに受け取った更新情報を追従し続け ることで, これらのファイルは CVSup がより効果的に動作することを支援し ます. 標準の base ディレクトリ /usr/local/etc/cvsup を使用します: *default base=/usr/local/etc/cvsup supfile に指定がない場合は, この設定をデフォルトで使用しますので, 実際には上の行は必要ありません. base ディレクトリが存在しない場合は作成しておきましょう. base ディレクトリが存在しない場合, cvsup クライアントは実行を拒否します. その他もろもろの supfile の設定: 通常 supfile に入れておくべき行がもう一つあります: *default release=cvs delete use-rel-suffix compress release=cvs は, サーバがメインの FreeBSD CVS リポジトリから その情報を取得するように指示します. ほとんどの場合はこのようにしておきますが, ここでの説明の範疇をこえるような 状況では他の指定をすることも可能です. delete は CVSup にファイルを削除することを許可します. CVSup が ソースツリーを完全に最新の状態に 保てるようにするためには, これは常に 指定しておくべきでしょう. CVSup は, これらの責任範囲のファイルだけを 慎重に削除します. たまたま存在する他の余分なファイルについては, まったく手をつけずに残しておきます. use-rel-suffix は ... 神秘的なものです. これについて本当に 知りたい人は, &man.cvsup.1; のマニュアルページをご覧ください. でなければ, 何も考えずに指定してみてください. compress は通信チャネルで gzip 形式の圧縮の使用を有効にします. ご使用のネットワーク接続が T1 speed 以上である場合, この圧縮を 使用しない方がよいかもしれません. そうでない場合は十分に役に立ちます. supfile の例のまとめ: 以下は supfile の例の全体です: *default tag=. *default host=cvsup666.FreeBSD.org *default prefix=/usr *default base=/usr/local/etc/cvsup *default release=cvs delete use-rel-suffix compress src-all cvs-crypto <application>CVSup</application> の実行 さて, 更新の準備ができました. これを実行するコマンドラインは 実に簡単です: &prompt.root; cvsup supfile もちろん, ここでの supfile は作成したばかりの supfile のファイル名です. X11 環境で実行するものと仮定して, cvsup は 通常の操作に必要なボタンを持つ GUI ウィンドウを表示します. “go” ボタンを押して, 実行を監視してください. この例では実際の /usr/src ツリーを更新しているので, cvsup にファイルを更新するのに必要なパーミッションを与えるために, ユーザ root で実行する必要があります. コンフィグレーションファイルを作ったばかりで, しかも以前にこのプログラムを実行したことがないので, 神経質になるのは 無理もない話だと思います. 大切なファイルに触らずに試しに実行する簡単な 方法があります. どこか適当な場所に空のディレクトリを作成して, コマンドラインの引数で指定するだけです: &prompt.root; mkdir /var/tmp/dest &prompt.root; cvsup supfile /var/tmp/dest 指定したディレクトリは, すべての更新されるファイルの 更新先ディレクトリとして使用します. CVSup は /usr/src の下の ファイルを検査しますが, 変更や削除はまったくおこないません. かわりに /var/tmp/dest/usr/src に更新されたすべてのファイルが 置かれるようになります. この方法で実行した場合は, CVSup は base ディレクトリの status ファイルを更新せずにそのままにします. これらのファイルの新しいバージョンは指定されたディレクトリ に書き込まれます. /usr/src の読み取り許可がある限り, このような 試し実行のためにユーザ root になる必要はありません. X11 を利用していないとか単に GUI が気に入らない場合は, cvsup 起動時にコマンドラインに 二つほどオプションを追加する必要があります: &prompt.root; cvsup -g -L 2 supfile オプションは cvsup に GUI を使用しないように伝えます. X11 を利用していない場合には自動的に指定されますが, そうでない場合は 明示的に指定します. オプションは cvsup にファイル更新中の詳細情報をプリントアウト するように伝えます. 冗長性には から までの三つのレベル があります. デフォルトは 0 であり, エラーメッセージ以外はまったく出力 しません. たくさんの他のオプション変数があります. それらの簡単な一覧は cvsup -H で表示されます. より詳しい説明はマニュアルページをご覧ください. 動作している更新の方法に満足したら, &man.cron.8; を使って cvsup を定期的に 実行させる準備をすることができます. cron から起動する際には, 明示的に cvsup が GUI を使わないようにする必要があります. <application>CVSup</application> ファイルコレクション CVSup 経由で入手できるファイルコレクションは 階層的に組織化されています. いくつか大きなコレクションがあり, それらは小さなサブコレクションに 分割されています. 大きなコレクションは, そのサブコレクション毎に 受信することと同じことになります. 下の一覧ではコレクション間の階層関係を 字下げして表現します. 最も一般的に使用するコレクションは src-all, cvs-crypto, そして ports-all です. 他のコレクションは特別な目的を持つ人達だけが 使用しており, ミラーサイトはそれらのすべてを 持っていないかもしれません. cvs-all release=cvs メインの FreeBSD CVS リポジトリであり, 輸出規制された暗号化コードは含まれていません. distrib release=cvs FreeBSD の配布とミラーに関連するファイルです. doc-all release=cvs FreeBSD ハンドブックおよびその他のドキュメントの ソースです. ports-all release=cvs FreeBSD の ports コレクションです. ports-archivers release=cvs アーカイビングのツール. ports-astro release=cvs 天文学関連の ports. ports-audio release=cvs サウンドサポート. ports-base release=cvs /usr/ports のトップにあるその他のファイル. ports-benchmarks release=cvs ベンチマークプログラム. ports-biology release=cvs 植物学関連のプログラム. ports-cad release=cvs CAD ツール. ports-chinese release=cvs 中国語サポート. ports-comms release=cvs 通信ソフトウェア. ports-converters release=cvs 文字コードコンバータ. ports-databases release=cvs データベース. ports-deskutils release=cvs コンピュータが発明される前に 卓上で使われていたものたち. ports-devel release=cvs 開発ユーティリティ. ports-editors release=cvs エディタ. ports-emulators release=cvs 他の OS のエミュレータ. ports-games release=cvs ゲーム. ports-german release=cvs ドイツ語サポート. ports-graphics release=cvs グラフィックユーティリティ. ports-japanese release=cvs 日本語サポート. ports-korean release=cvs 韓国語サポート. ports-lang release=cvs プログラミング言語. ports-mail release=cvs メールソフトウェア. ports-math release=cvs 数値計算ソフトウェア. ports-mbone release=cvs MBone アプリケーション. ports-misc release=cvs 色々なユーティリティ. ports-net release=cvs ネットワーキングソフトウェア. ports-news release=cvs USENET ニュースのソフトウェア. ports-plan9 release=cvs Plan9 からの色々なプログラム. ports-print release=cvs 印刷ソフトウェア. ports-russian release=cvs ロシア語サポート. ports-security release=cvs セキュリティユーティリティ. ports-shells release=cvs コマンドラインシェル. ports-sysutils release=cvs システムユーティリティ. ports-textproc release=cvs 文書処理ユーティリティ (デスクトップパブリッシングは含まない). ports-vietnamese release=cvs ベトナム語サポート. ports-www release=cvs World Wide Web 関連のソフトウェア. ports-x11 release=cvs X window システムをサポートする ports. ports-x11-clocks release=cvs X11 上で動作する時計の数々. ports-x11-fm release=cvs X11 上で動作するファイラ. ports-x11-fonts release=cvs X11 のフォントとフォントユーティリティ. ports-x11-toolkits release=cvs X11 のツールキット. ports-x11-wm release=cvs X11 のウィンドウマネージャ. src-all release=cvs メインの FreeBSD ソース群であり, 輸出規制された暗号化コードは 含まれていません. src-base release=cvs /usr/src のトップにあるその他のファイル. src-bin release=cvs シングルユーザモードで必要な ユーザユーティリティ (/usr/src/bin). src-contrib release=cvs FreeBSD プロジェクト外部からの ユーティリティおよびライブラリ, 比較的無修正 (/usr/src/contrib). src-etc release=cvs システムコンフィグレーションファイル (/usr/src/etc). src-games release=cvs ゲーム (/usr/src/games). src-gnu release=cvs GNU Public License 下にあるユーティリティ (/usr/src/gnu). src-include release=cvs ヘッダファイル (/usr/src/include). src-kerberosIV release=cvs KerberosIV セキュリティパッケージ (/usr/src/kerberosIV). src-lib release=cvs ライブラリ (/usr/src/lib). src-libexec release=cvs システムプログラムであり, 通常は他のプログラムから実行される (/usr/src/libexec). src-release release=cvs FreeBSD の release を構築するために必要なファイル (/usr/src/release). src-sbin release=cvs シングルユーザモード用の システムユーティリティ (/usr/src/sbin). src-share release=cvs 多様なシステム間で共有可能なファイル (/usr/src/share). src-sys release=cvs カーネル (/usr/src/sys). src-tools release=cvs FreeBSD の保守用の色々なツール (/usr/src/tools). src-usrbin release=cvs ユーザユーティリティ (/usr/src/usr.bin). src-usrsbin release=cvs システムユーティリティ (/usr/src/usr.sbin). www release=cvs World Wide Web のデータ用のソースです. cvs-crypto release=cvs 輸出規制された暗号化コードです. src-crypto release=cvs 輸出規制された FreeBSD プロジェクト外部からのユーティリティおよび ライブラリ, 比較的無修正 (/usr/src/crypto). src-eBones release=cvs Kerberos および DES (/usr/src/eBones). src-secure release=cvs DES (/usr/src/secure). distrib release=self CVSup サーバ自身のコンフィグレーションファイルです. CVSup ミラーサイトが使用します. gnats release=current GNATS バグトラッキングデータベースです. mail-archive release=current FreeBSD 関連メーリングリストのアーカイブ. www release=current インストールされた World Wide Web のデータです. WWW ミラーサイトが使用します. 詳細について CVSup の FAQ や CVSup に関するその他の情報については The CVSup Home Page をご覧ください. CVSup のほとんどの FreeBSD 関連の議論は &a.hackers; で おこなわれています. ソフトウェアの新しいバージョンは &a.announce; で アナウンスされます. 質問とバグ報告はプログラムの作者, cvsup-bugs@polstra.com へ 送ってください. <command>make world</command> でシステムを再構築する Contributed by &a.nik;. 訳: &a.jp.y-koga;. 16 March 1998. FreeBSD のどれか特定のバージョン (stable, current など) について, ローカルのソースツリーを同期させたら, そのソースツリーを使ってシステムを 再構築しなければなりません. その方法については, http://www.nothing-going-on.demon.co.uk/FreeBSD/make-world/make-world.html が今のところ一番よいチュートリアル資料です. このチュートリアルの次のバージョンは, ハンドブックに統合される予定です. diff --git a/ja_JP.eucJP/books/handbook/kerneldebug/chapter.sgml b/ja_JP.eucJP/books/handbook/kerneldebug/chapter.sgml index 4e1a45a5fb..8d6f36133c 100644 --- a/ja_JP.eucJP/books/handbook/kerneldebug/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/kerneldebug/chapter.sgml @@ -1,689 +1,690 @@ カーネルデバッグ 原作 &a.paul; and &a.joerg; 訳: &a.jp.yoshiaki;. 18 March 1997. <command>kgdb</command> によるカーネルのクラッシュダンプのデバッグ ここではクラッシュダンプ (crash dump : 訳注 この文脈では kernel 自身 の異常によって停止した場合に出力されるイメージを指します) によるカー ネルデバッグの方法を示します. ここではダンプするための十分なスワップ (swap) の容量があるものとします. もし複数のスワップパーティションを持ち, 最初のパーティションがダンプ を保持するのに十分な大きさを持たない場合は 別のダンプデバイスを使うよ うに (config kernel 行で) カーネルのコンフィグをおこなうか, &man.dumpon.8; コマンドを使って別のデバイスを示すことができます. &man.dumpon.8; を使うもっともよい方法は変数 dumpdev を /etc/rc.conf で設定することです. 一般的には /etc/fstab で設定されているスワップデバイスが 使われるでしょう. スワップに使えないデバイスへのダンプ, 例えばテープへのダンプは現在サポートさ れていません. カーネルのコンフィグは config -g によって行ってください. FreeBSD カーネルのコンフィグレーション には FreeBSD のカーネルの設定の詳細がありますので 参照してください. &man.dumpon.8; コマンドを使ってどこへダンプするか カーネルに伝えてください (&man.swapon.8; によってそのパーティションが スワップとして設定された 後でなければならないことに注意してください). これは普通は /etc/rc.conf や /etc/rc で設定されます. あるいは 別の方法としてカーネルコンフィグレーションファイルの config 行の dump 節 で ダンプデバイスをハードコードすることができます. この方法はあまりよくは ありません. カーネルがブート時に crash する場合のクラッシュダンプを取り たい時だけ使うべきです. 以下では kgdbという用語は gdbを “カーネルデバッグモード” で動かしていることを意味します. gdbを オプションをつけて起動するか kgdbという名前でリン クして起動することでこのモードになります. デフォルトでは このリンク は作られていません. また, このアイデアは GNU関係者たちが彼らのツール を別の名前で呼び出した時に異なった動作をするということを 好まない, と いう点で不評です. あるいは将来この機能を廃止することになるかもしれません. カーネルを作った時にそのコピーを kernel.debug という名前で作 りましょう. また, オリジナルに対して strip -dを実行します. オリジナルを普通にインストールします. また strip していないカーネル も同様にインストールすることができますが, シンボルテーブルの参照時間 がいくつかのプログラムでは劇的に増加するでしょう. また, カーネル全体 はブート時に読み込まれ スワップアウトされないため数メガバイトの物理メ モリが無駄になります. 例えばブートプロンプトで 新しいカーネルの名前をタイプすることによって, 新しいカーネルをテストした場合で, 再びシステムを動かすのに別のカーネ ルで立ち上げることが必要な場合はブートプロンプトで フラグ を使いシングルユーザの状態にしてください. そして以下のような操作をおこな います. &prompt.root; fsck -p &prompt.root; mount -a -t ufs # /var/crash 用のファイルシステムを書き込み可能にする &prompt.root; savecore -N /kernel.panicked /var/crash &prompt.root; exit # ...マルチユーザモードへ移行 ここに示した &man.savecore.8; は (現在動いているものとは別の) カーネルのシンボル名の抽出をおこなうために使っています. 抽出はデフォルトで は現在動いているカーネルに対しておこなわれ, クラッシュダンプとカーネルシンボ ルのくい違いのためにまったく何もしません (訳注:そのためにオプション で実際にダンプをおこしたカーネルを指定します). クラッシュダンプの起きた後に /sys/compile/WHATEVERへ行き kgdbを動かします. kgdb より次のようにします. symbol-file kernel.debug exec-file /var/crash/kernel.0 core-file /var/crash/vmcore.0 こうすると, クラッシュダンプを使ってカーネルソースを他のプログラムと同様に デバッグすることができます. 次に kgdb での手順のセッションのログを示します. 長い行は読 みやすくするために改行しました. また, 参照のために行番号を入れてあり ます. ただし, これは実際の pcvtコンソールドライバの開発中の実際のエ ラーのトレースです. - 1:Script started on Fri Dec 30 23:15:22 1994 + 1:Script started on Fri Dec 30 23:15:22 1994 2:&prompt.root; cd /sys/compile/URIAH 3:&prompt.root; kgdb kernel /var/crash/vmcore.1 - 4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel...done. + 4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel +...done. 5:IdlePTD 1f3000 6:panic: because you said to! 7:current pcb at 1e3f70 8:Reading in symbols for ../../i386/i386/machdep.c...done. 9:(kgdb) where 10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767) 11:#1 0xf0115159 in panic () 12:#2 0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698) 13:#3 0xf010185e in db_fncall () 14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073) 15:#5 0xf0101711 in db_command_loop () 16:#6 0xf01040a0 in db_trap () 17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723) 18:#8 0xf019d2eb in trap_fatal (...) 19:#9 0xf019ce60 in trap_pfault (...) 20:#10 0xf019cb2f in trap (...) 21:#11 0xf01932a1 in exception:calltrap () 22:#12 0xf0191503 in cnopen (...) 23:#13 0xf0132c34 in spec_open () 24:#14 0xf012d014 in vn_open () 25:#15 0xf012a183 in open () 26:#16 0xf019d4eb in syscall (...) 27:(kgdb) up 10 28:Reading in symbols for ../../i386/i386/trap.c...done. 29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\ 30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\ 31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\ 32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\ 33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\ 34:ss = -266427884}) (../../i386/i386/trap.c line 283) 35:283 (void) trap_pfault(&frame, FALSE); 36:(kgdb) frame frame->tf_ebp frame->tf_eip 37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done. 38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\ 39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403) 40:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); 41:(kgdb) list 42:398 43:399 tp->t_state |= TS_CARR_ON; 44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */ 45:401 46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200) 47:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); 48:404 #else 49:405 return ((*linesw[tp->t_line].l_open)(dev, tp, flag)); 50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */ 51:407 } 52:(kgdb) print tp 53:Reading in symbols for ../../i386/i386/cons.c...done. 54:$1 = (struct tty *) 0x1bae 55:(kgdb) print tp->t_line 56:$2 = 1767990816 57:(kgdb) up 58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\ 59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126) 60: return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p)); 61:(kgdb) up 62:#2 0xf0132c34 in spec_open () 63:(kgdb) up 64:#3 0xf012d014 in vn_open () 65:(kgdb) up 66:#4 0xf012a183 in open () 67:(kgdb) up 68:#5 0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\ 69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\ 70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \ 71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \ 72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673) 73:673 error = (*callp->sy_call)(p, args, rval); 74:(kgdb) up 75:Initial frame selected; you cannot go up. 76:(kgdb) quit 77:&prompt.root; exit 78:exit 79: 80:Script done on Fri Dec 30 23:18:04 1994 上の出力についてのコメントをします. line 6: これは DDB (後述) からのダンプです. このため “because you said to!” という panicコメントがつき, ページフォルトのト ラップによって DDBに入ったことが原因の, やや長いスタックトレー スがあります. line 20: スタックトレースでのこれは trap()関数の位置で す. line 36: 新しいスタックフレームの使用を指定しています. これは現 在は必要ありません. trapの場合ではスタックフレームは正 しい場所を指していると考えられます. (私は新しいコアダンプ を持っていません. 私のカーネルは長い間 panicを起こしていま せん.) ソースコードの 403行を見ると,“tp”ポインタのアク セスが失敗しているか配列のアクセスが範囲外である可能性が高 いことがわかります. line 52: 怪しいポインタですが, アクセスは正常におこなえました. line 56: ところが, 明らかにポインタはゴミを指しています. これで エラーを見つけました! (ここのコードの部分からはよくわかり ませんが, tp->t_lineはコンソールデバイスの規定 する行を参照しているので, もっと小さな整数でなければなりませ ん. ) DDD によるクラッシュダンプのデバッグ カーネルのクラッシュダンプは ddd のようなグラフィカルなデバッガで調べることもできます. 通常はコマンドラインで オプションをつけて ddd を起動します. たとえば: &prompt.root; ddd -k /var/crash/kernel.0 /var/crash/vmcore.0 クラッシュダンプを ddd のグラフィカルなインターフェースを使って 見ることができます. 突然ダンプした場合の解析 カーネルが予想もしない時にコアダンプして config -g を行ってコンパイルされていなかった場合にはどうしたら よいでしょう. すべてが失われるわけではありません. パニックを起こさないでください. もちろん, クラッシュダンプを使えるようにする必要があります. 使い方は前述の部分を見てください. カーネルのコンパイルディレクトリで, (Makefileの) COPTFLAGS?=-O とある行を編集します. オプショ ンをここに加えます (オプティマイズオプションのレベルは 変更しな いでください ). もし大まかにコードのどこで問題が起きているか (例 えば, 上の例では pcvtドライバ) わかっているのでしたら, その部 分のコードについてのすべてのオブジェクトファイルを 消してください. カーネ ルを再構築しましょう. Makefileのタイムスタンプの変更により, 例えば trap.o などのいくつかの他のオブジェクトファイルも作り直さ れます. 少しの幸運があれば, オプションが追加されても作ら れるコードは変更されず, いくらかのデバッグシンボル以外には 問題を 起こしたコードとそっくりな新しいカーネルを手に入れることが できます. 少なくとも &man.size.1; コマンドで古い方と新しい方のサイズを比較すべ きです. これが食い違っていれば, 多分あきらめなければならないでしょう. ダンプを使って前述のように動かして調べます. デバッグシンボルは 必ずしも十分ではありません. 上の例ではスタックトレースでいくつかの関 数の行番号や引数リストが表示されないかもしれません. もしより多くのデ バッグシンボルが必要であれば,十分になるまで 適切なオブジェクトファイ ルを消して (makeして) kgdbセッションを繰り返してください. これは必ずしもうまく動くと保証はできません. しかしほとんどの場合でう まくいくでしょう. DDBを使ったオンラインカーネルデバッグ kgdb は非常に高レベルのユーザインタフェースを提 供するオフラインデバッガですが, いくつかのことはできません. (できないことの中で) 極めて重要なことはカーネルコードへのブレークポイ ントの設定とシングルステップ実行です. カーネルの低レベルデバッグが必要であれば, DDBと呼ばれる on-lineデバッ ガが使えます. ブレークポイントの設定, シングルステップのカーネルの実 行, 変数の検査と変更などができます. ただし,これはカーネルのソースファ イルにアクセスすることはできません. kgdbのようにすべてのデ バッグ情報にはアクセスできず, globalと staticのシンボルにアクセス することができるだけです. カーネルに DDB を含めるためにはコンフィグファイルに次のようなオプショ ンを加えて, options DDB 再構築をおこないます. ( FreeBSDのカーネルの設定の詳細については FreeBSD カーネルのコンフィグレーションを参照してくださ い. もしブートブロックが古いバージョンですと, デバッガのシンボルが完 全にはロードされないかもしれませんので注意してください. DDB シンボル がロードされるようにブートブロックを 最新の物にアップデートしてくださ い) DDB カーネルの実行において, DDBに入るいくつかの方法があります. 最初 の, 最も早い方法はブートプロンプトが出ている時に のブート フラグをタイプすることです. カーネルはデバッグモードで起動し, デバ イスのプローブ以前に DDBに入ります. したがって, デバイスのプローブ/初期 設定ファンクションのデバッグができます. 2つ目のシナリオはキーボードのホットキーで, 通常は Ctrl-Alt-ESCです. syscons ではホットキーは再設定することができ, 配付されているいくつかの キーマッピングでは別のキーに 再設定されていますので確認しておいてください. シリアルラインの BREAKを使って シリアルコンソールから DDBへ入ることを可 能にするオプションもあります (カーネルコンフィグレーションファイルの options BREAK_TO_DEBUGGER). これは 多くのつまらないシリ アルアダプタが, 例えばケーブルを引き抜いた時に BREAK状態を意味もなく 作り出してしまうのでデフォルトでは無効になっています. 3つ目は, DDB を使うようになっているカーネルがパニック状態になると DDB へ入るというものです. このため, 無人運転するマシンのカーネルにDDBを 入れるのは賢明ではありません. DDB のコマンドはおおまかには gdb のいくつかのコマンドと似て います. おそらく最初にブレークポイントを 設定する必要があるでしょう. b function-name b address 数値はデフォルトでは16進数で, シンボル名とはまったく異ります. 16進数で a-f の文字で始まる場合は, 先頭に 0x をつける必要があります(それ以外の数字の場合はどちらでもか まいません). function-name + 0x103のような単純な式を使うこ とができます. 割り込みされたカーネルから処理を続行するためには, c とタイプするだけです. スタックのトレースには trace とします. DDB にホットキーで入った場合は, カーネルはその (ホットキーの) 割り込み の処理を行っていますのでスタックトレースは あまり役にたたないことに注 意してください. ブレークポイントを削除したい場合は, del del address-expression とします. 最初の形式はブレークポイントにヒットしたすぐ後で使うことが でき, 現在のブレークポイントを削除します. 2番目の形式では任意のブレー クポイントを削除することができますが, 次の形式で得られるような正確な アドレスを与えることが必要です. show b カーネルをシングルステップ実行させるには s としてみてください. これは関数呼出し先までステップ実行 (step into function) するでしょう. 次のステートメントが終了するまでのDDBトレースは n によっておこなうことができます. これは gdb の next 命令とは異ります. gdbの finish命令と似ています. メモリ上のデータを調べるには (例として) 次のようにします. x/wx 0xf0133fe0,40 x/hd db_symtab_space x/bc termbuf,10 x/s stringbuf word/halfword/byte 単位でアクセスをおこない, hex (16進) /dec (10進) / char (文字) /string (文字列) で表示します. カンマの後ろの数字はオブジェク トカウントです. 次の 0x10個の要素を表示するには, 単純に x ,10 とします. 同様に次のように使うことができます. x/ia foofunc,10 foofunc の最初の 0x10個の命令語をディスアセンブルし, foofunc の先頭からのオフセットとともに表示します. メモリの内容を変更するには writeコマンドを使います. w/b termbuf 0xa 0xb 0 w/w 0xf0010030 0 0 コマンドモディファイアの (b/h/w) はデータを 書くサイズを定義し, これに続く最初の式は書き込むアドレス, 残りがこれ に続く連続するメモリアドレスに書き込まれるデータになります. 現在のレジスタ群の内容を知りたい場合は show reg とします. また, 単一のレジスタの値を表示するには, 例えば p $eax とします. また値の変更は set $eax new-value とします. DDBからカーネルの関数を呼び出す必要がある場合は, 単に call func(arg1, arg2, ...) とします. return 値が出力されます. 動いているプロセスの &man.ps.1; スタイルの概要は ps です. カーネルの失敗の原因の調査が終わったらリブートすべきです. それまでの 不具合によりカーネルのすべての部分が期待するような 動作をしているわけ ではないということを忘れないでください. 以下のうちいずれかの方法でシ ステムのシャットダウンおよびリブートを行ってください. call diediedie() カーネルをコアダンプしてリブートしますので, 後で kgdbによってコアの高 レベル解析をすることができます. このコマンドは通常 continue命令にエイリアスされています. panicにエイリアスされている call boot(0) は動いているシステムを `clean' に shut downするよい方法です. すべて のディスクを sync()して最後にリブートします. ディスクとカー ネルのファイルシステムインタフェースが破損していない限り, ほぼ完全 に `clean'にシャットダウンするよい方法でしょう. call cpu_reset() は大惨事を防ぐための最後の手段で 「赤い大きなボタン」 を押すのとほとんど 同じです.(訳注: リセットボタンを押すのとほぼ同じであるという意味です) 短いコマンドの要約は help をタイプします. ただし, デバッグセッションのために &man.ddb.4; の マニュアルページのプリントアウトを用意しておくことを 強くお奨めします. カーネルのシングルステップ中にオンラインマニュアルを 読むことは難しい ということを覚えておいてください. リモート GDB を使ったオンラインカーネルデバッグ この機能は FreeBSD 2.2 からサポートされました. これは本当にすばらし い機能です. GDB はすでにかなり以前より リモートデバッグ をサポートしてい ます. これはシリアル回線を使い非常に単純なプロトコルで行ないます. もちろん, この方法では今までに示した方法とは違い, 2台のマシンが必 要になります. 1台はデバッグ環境のためのホストで, すべてのソースとす べてのシンボルを含んだバイナリのコピーを持っています. もう 1台は ターゲットマシンで, 同一のカーネルのコピー (ただしデバッグ情報は 取り除いてあるもの) を単に実行するためのものです. この場合, カーネルのコンフィグレーションは config -g で行な い, を含めなくてはなりません. そうして通常通りコンパイルし ます. こうして作ったバイナリファイルはデバッグ情報のために非常に大き くなります. このカーネルをターゲットマシンにコピーして strip -x でデバッグシンボルを取り除きます. そして ブートオプションを使いブートします. ターゲットマシンの 1番目の シリアル回線をデバッグホストの いずれかのシリアル回線につないでおきま しょう. それからデバッグ(訳注:ホスト)マシン上で, ターゲットとなって いるカーネルのコンパイルディレクトリで gdb を起動します: &prompt.user; gdb -k kernel GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc... (kgdb) リモートデバッグセッションの初期化 (1番目のシリアルポートを使用する ことの設定) を以下のように行ないます. (kgdb) target remote /dev/cuaa0 次にターゲットマシン (デバイスのプローブ直前で DDB に入っています) で次のように入力します: Debugger("Boot flags requested debugger") Stopped at Debugger+0x35: movb $0, edata+0x51bc db> gdb DDB は次のような出力を返すでしょう. Next trap will enter GDB remote protocol mode gdbと入力するたびに リモート GDB とローカル DDB が交互に切り替わ ります. トラップをすぐに起こすために単に ``s'' (step) と入力して下 さい. そうするとホストの GDB はターゲットのカーネルの制御を行なうよ うになります. Remote debugging using /dev/cuaa0 Debugger (msg=0xf01b0383 "Boot flags requested debugger") at ../../i386/i386/db_interface.c:257 (kgdb) このセッションではソースコードへのフルアクセスや Emacs の window 上 の gud-mode (これは別の Emacs window に自動的にソースコードを表示し ます) で動かすなど, 通常の GDB セッションでできることのほとんどのこ とができます. リモート GDB は LKM のデバッグも行なうことができます. 最初に LKM を デバッグシンボルを含めた形で作ります. &prompt.root; cd /usr/src/lkm/linux &prompt.root; make clean; make COPTS=-g そしてターゲットマシン上で モジュールのこのバージョンをインストールし ます. これをロードしてから, modstat を使ってロードされている ことを確認してください: &prompt.root; linux &prompt.root; modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 4 f5109000 001c f510f010 1 linux_mod 示されたロードアドレスに 0x20 (a.outのヘッダはおそらくこの大きさでしょ う) を加えます. それがモジュールコードの再配置されるアドレスです. GDB の add-symbol-file コマンドを使ってデバッガにモジュールの 情報をつたえます. (kgdb) add-symbol-file /usr/src/lkm/linux/linux_mod.o 0xf5109020 add symbol table from file "/usr/src/lkm/linux/linux_mod.o" at text_addr = 0xf5109020? (y or n) y (kgdb) これで LKM のすべてのシンボルにアクセスできるようになります. コンソールドライバのデバッグ DDBを動かすためにはコンソールドライバが必要ですから, コンソールドラ イバ自身に不具合のある場合は複雑になります. シリアルコンソールを利 用する方法 (ブートブロックを変更するか Boot:プロンプトで と入力する) を思い出してください. そして標準ター ミナルを最初のシリアルポートに設定します. DDBは, もちろんシリアルコ ンソールを含むいずれの コンソールドライバの設定でも動作します. diff --git a/ja_JP.eucJP/books/handbook/ports/chapter.sgml b/ja_JP.eucJP/books/handbook/ports/chapter.sgml index 6390ba6298..1c343d7c23 100644 --- a/ja_JP.eucJP/books/handbook/ports/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/ports/chapter.sgml @@ -1,5231 +1,5233 @@ アプリケーションのインストール : ports コレクション 原作: &a.jraynard;. 訳: &a.jp.masaki;, &a.jp.saeki;. 11 November 1996. FreeBSD の ports コレクションを利用すると, 最小限の労力で 非常に幅広くのアプリケーションのコンパイルとインストールがおこなえます. やってみたことのある方はよくご存知でしょうが, オープンな規格とは 全くの誇大広告であって, あるプログラムを異なるバージョンの Unix 上で 動作させることは退屈で手間のかかる仕事です. 求めているプログラムが自分のシステムでうまくコンパイルでき, 正しいところにインストールできて, 完璧に動作するとしたらとてもラッキーです. しかし, あいにくこれは滅多にないことなのです. ほとんどのプログラムについて, あなたは髪を掻きむしることになるでしょうし, かなりのプログラムでは, 白髪混じりの頭になってしまったり, あるいは慢性の 脱毛症にすら なってしまうかもしれません... いくつかのソフトウェアディストリビューションでは, 設定用のスクリプトを 配布することでこの問題を解決しようとしています. これらのスクリプトの中には非常に精巧なものもありますが, 残念ながら, 中にはこれまで 聞いたこともないようなシステムの名前をしゃあしゃあと 言い放ったうえに, まるでシステムレベルの Unix プログラミングに関する 最終試験のような, たくさんの質問をしてくる場合があります. (例えば, このシステムの gethitlist 関数は fromboz への const ポインタを 返しますか? それとも const fromboz へのポインタを返しますか?, このシステムには Foonix スタイルの, 容認できない例外処理をおこなう ルーチンがありますか? もしもないとしたら, それはなぜですか?) 幸いなことに, ports コレクションがあれば, これらのきつい作業はすべて 完了しています. make install とタイプするだけで, 動作するプログラムを 入手することができるのです. なぜ ports コレクションを作ったのか? FreeBSD の基本システムは, 非常に多くのツールやユーティリティから 構成されています. しかし, よく使われるプログラムのうち多くのものが, この基本システムには含まれていません. その理由は:- ある Lisp ベースのエディタのように, それがないと生きていけないと 言う人もいれば, ディスクの無駄だと言う人もいるようなプログラム. 基本システムに組み込むには特殊すぎるプログラム. (CAD やデータベースなど.) “時間のある時に, ちょっと見ておかなければ”というような類の, それがシステムに含まれていないことが 致命的とは言えないプログラム. (おそらく, 何らかの言語などでしょう.) FreeBSD のような真面目なオペレーティングシステムの一部として 供給するには遊びが過ぎるようなプログラム. ;-) たくさんのプログラムを基本システムに組み込んだとしても, もっともっと 組み込みたいという要求が出てくるので, どこかで制限を引かなくてはならないため. (そうしなければ FreeBSD の配布物は, とてつもなく膨大になってしまうでしょう.) すべての人が自分のお気に入りの プログラムを手作業で移植しなければ ならないとしたら, (途方もない膨大な作業の繰り返しをさておいたとしても) それは明らかに不合理な話です. そこで, FreeBSD プロジェクトでは, 標準のツールを使って移植のプロセスを 自動化する巧妙な方法を考え出しました. なお, これは単純ながら非常に柔軟なツールを組み合わせることで, 非常に強力な働きをさせるという“Unix 流”の作業の優れた実例です. ports コレクションはどのように動くのでしょうか? インターネットでは通常, tarball の形で プログラムが配布されています. これは, Makefile とソースコードで構成され, 普通は何らかの説明書 (あいにく, いつもわかりやすく書かれているとは 限りませんが) が付属しています. ことによるとコンフィグレーションスクリプトも 含まれているかもしれません. 標準的な手順では, FTP で tarball を入手して, 適当なディレクトリで展開します. 次に説明書を読んで, 必要な変更をおこないます. そして, 設定スクリプトを実行し, 標準の make コマンドを使ってソースのコンパイルとインストールを おこないます. FreeBSD の ports も tarball の仕組みを利用していますが, これはユーザが 苦労して作業することを期待したものではなく, どのようにすれば FreeBSD 上で そのプログラムが動くようになるかという「ノウハウ」を スケルトン を使用して収めているものです. スケルトンは, カスタマイズ済みの Makefile も 提供していますので, ほとんどすべての ports は同じ手順でインストールすることが できます. もしあなたが (あなたの FreeBSD システム または FTP サイト にある) ports スケルトンを見ていて, そこに潜んでいる あらゆる種類の先端的な ロケット工学的なものを見つけられると期待していると, つまらなそうなファイルやディレクトリがそこにあるだけなのを見て, がっかりするかもしれません. (ports を手に入れる方法については, すぐに FreeBSD ports コレクションの入手方法 の節でお話します.) “一体どうしたらいいんだ? ここにはソースコードが ないじゃないか?” というあなたの叫びが聞こえるようです. 心配いりません. おとなしく読んでいけば, すべてが (たぶん) 明らかに なるでしょう. 試しに ports をインストールして, 何が起きるのかを見てみましょう. ここではサンプルとして開発者向けの便利なツール, ElectricFence を選択します. このスケルトンを選んだ理由は, 他の ports に比べても素直で理解しやすく 書かれているからです. 自宅で試してみる場合には, root になる必要があるでしょう. &prompt.root; cd /usr/ports/devel/ElectricFence &prompt.root; make install >> Checksum OK for ElectricFence-2.0.5.tar.gz. ===> Extracting for ElectricFence-2.0.5 ===> Patching for ElectricFence-2.0.5 ===> Applying FreeBSD patches for ElectricFence-2.0.5 ===> Configuring for ElectricFence-2.0.5 ===> Building for ElectricFence-2.0.5 [大量のメッセージをコンパイラが出力します...] ===> Installing for ElectricFence-2.0.5 ===> Warning: your umask is "0002". If this is not desired, set it to an appropriate value and install this port again by ``make reinstall''. install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.a /usr/local/lib install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.3 /usr/local/man/man3 ===> Compressing manual pages for ElectricFence-2.0.5 ===> Registering installation for ElectricFence-2.0.5 ここではあなたが混乱しないように, コンパイル時の出力を すべて取り除いてあります. もしもあなた自身で実行されたら, 最初にこのような 出力結果が得られるはずです:- &prompt.root; make install >> ElectricFence-2.0.5.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://ftp.doc.ic.ac.uk/Mirrors/sunsite.unc.edu/pub/Linux/devel/lang/c/. make プログラムは, あなたの手元にソースコードがないことを検出し, 処理を続けられるようにソースを FTP でダウンロードしようとします. この例では, あらかじめ手動でソースコードを用意してあったので, 持ってくる必要はありませんでした. では, 続けて make プログラムが何をしているのか見てみましょう. ソースコード tarball のありかを 確認します. 手元にファイルが存在しなければ, FTP サイトから入手しようとします. チェックサム テストを実行して, その tarball が事故か何かで途中で切れていたり, ASCII モードで ダウンロードされていたり, 転送中にニュートリノによって傷められたりして 改変されたりしていないかどうかを確認します. tarball を一時的な作業用ディレクトリに展開します. FreeBSD 上でコンパイルしたり, 動作させるのに必要な すべての パッチ をソースコードに当てます. 構築のために必要な コンフィグレーションスクリプトを実行します. コンフィグレーションスクリプトの 質問には正確に答えてください. (いよいよ!) ソースコードをコンパイルします. 実行形式のプログラム, マニュアル, その他のサポートファイルを, システムのプログラムと混ざってしまわないように /usr/local 以下に インストールします. ports はすべて同じ場所にインストールされ, システムのあちこちにばらまかれることはありません. インストール結果はデータベースに登録されます. これにより, インストールしたプログラムがもしも気に入らなかったときも, システムから すべての痕跡をきれいに 消去 することができます. 以上のステップが make の出力と一致しているかどうか確認してください. 今まで確認していなかったのなら, 今からするようにしてください! FreeBSD ports コレクションの入手 あるプログラムの FreeBSD port を入手するには二つの方法があります. ひとつは FreeBSD CD-ROM を使う方法で, もうひとつは インターネット接続 を使う方法です. CD-ROM からコンパイルする FreeBSD CD-ROM がドライブに入っており, /cdrom にマウントされていると仮定すると (マウントポイントが /cdrom である必要があります), ただ普通に実行するだけで ports を構築できるようになり, tarball をネットワーク経由でダウンロードするのではなく /cdrom/ports/distfiles/ からさがすようになります (そこにあればの話ですが). CD-ROM にある port スケルトンを使いたければ, 他に /etc/make.conf の 変数を以下のようにセットする方法があります: PORTSDIR= /cdrom/ports DISTDIR= /tmp/distfiles WRKDIRPREFIX= /tmp (任意の十分な空きスペースの場所を /tmp とおいています). 次に, /cdrom/ports 下の適宜のサブディレクトリに cd して, 例のごとく make install とタイプします. WRKDIRPREFIX は port に /tmp/cdrom/ports の下でビルドさせようとします; 例えば, games/oneko は /tmp/cdrom/ports/games/oneko の下で ビルドされるでしょう. ライセンスの制限により, いくつかの ports でオリジナルのソースコードを CD-ROM に入れることができなかったものがあることに注意してください. この場合, インターネット経由で ports をコンパイルする の 節を参照してください. インターネット経由で ports をコンパイルする CD-ROM を持っていなかったり, その ports の最新バージョンを確実に入手したい 場合は, その ports の スケルトン を ダウンロードする必要があります. ところで, これは落し穴が たくさんある作業に見えるかもしれませんが, 実際には非常に簡単です. 初めに, あなたの動かしている FreeBSD がリリースバージョンなら ports ページ でその FreeBSD 用の “アップグレードキット” を手にいれてください. このパッケージには, 最新の ports をコンパイルするのに必要な, リリース以降に更新されたファイルが含まれています. FreeBSD の FTP サーバーがその場で tarball を作成できることを利用してスケルトンを入手すると 非常に便利です. ここでは例として databases ディレクトリにある gnats プログラムを使って説明します. (角型かっこの中の文はコメントなので, 実際に実行する場合には, これをタイプしないでください!):- &prompt.root; cd /usr/ports &prompt.root; mkdir databases &prompt.root; cd databases &prompt.root; ftp ftp.freebsd.org [ユーザ名 `ftp' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] > cd /pub/FreeBSD/ports/ports/databases > get gnats.tar [gnats スケルトンの tarballs を取得] > quit &prompt.root; tar xf gnats.tar [gnats スケルトンの展開] &prompt.root; cd gnats &prompt.root; make install [gnats の構築とインストール] さて何が起きるでしょうか? FTP サイトにいつも通りに接続して, データベースの サブディレクトリに移動します. get gnats.tar とコマンドを入力すると, FTP サイトでは gnats ディレクトリを tarred にしてくれるのです. gnats スケルトンを展開したら, gnats ディレクトリへ移動して ports を構築します. すでに 説明したように, make の過程で 手元にソースコードがないことを検出すると, ソースコードを取得してから 展開し, パッチ当てと構築をおこないます. それでは, 少し冒険をしてみましょう. 一つの ports スケルトンを 取得するかわりに, たとえば ports コレクションの中のデータベースの スケルトンをすべて, サブディレクトリ全体を取得してみましょう. やり方はほとんど同じです:- &prompt.root; cd /usr/ports &prompt.root; ftp ftp.freebsd.org [ユーザ名 `ftp' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] > cd /pub/FreeBSD/ports/ports > get databases.tar [データベースディレクトリの tarballs を取得] > quit &prompt.root; tar xf databases.tar [すべてのスケルトンを展開] &prompt.root; cd databases &prompt.root; make install [データベース ports 全部の構築とインストール] わずかばかりの簡単なコマンドで, この FreeBSD マシン上にデータベース プログラムを一揃い手に入れてしまいました! 一つの ports スケルトンを取ってきて それを構築する場合との違いは, すべてのディレクトリを一度に取得して, 全部を一度にコンパイルしたということだけです. かなり感動的だと思いませんか? たくさんの ports をインストールする つもりなら, おそらくすべての ports ディレクトリをダウンロードしておく 価値があるでしょう. スケルトン スケルトン (訳注: skeleton とは骸骨のことです) とは, 締め切りを守るため, 食事をするのを忘れるほど仕事にのめり込んだ ハッカーたちのなれの果ての ことでしょうか? FreeBSD の屋根裏に潜む, なにか気持ちの悪いものでしょうか? いいえ, ここでスケルトンの意味するところは, ports の魔術を実現するのに 必要とされるすべてのものを提供する最小の骨組みのことです. <filename>Makefile</filename> スケルトンのもっとも重要な要素は Makefile です. Makefile は ports を どのようにコンパイルし, インストールをおこなうかを指示する いろいろな命令を含んでいます. 以下に ElectricFence の Makefile を示します:- # New ports collection makefile for: Electric Fence # Version required: 2.0.5 # Date created: 13 November 1997 # Whom: jraynard # # $Id$ # DISTNAME= ElectricFence-2.0.5 CATEGORIES= devel MASTER_SITES= ${MASTER_SITE_SUNSITE} MASTER_SITE_SUBDIR= devel/lang/c MAINTAINER= jraynard@freebsd.org MAN3= libefence.3 do-install: ${INSTALL_DATA} ${WRKSRC}/libefence.a ${PREFIX}/lib ${INSTALL_MAN} ${WRKSRC}/libefence.3 ${PREFIX}/man/man3 .include <bsd.port.mk> "#" で始まる行は, 人間のためのコメント行です. (ほとんどの Unix のスクリプトと同じですね.) DISTNAME は tarball の名前から拡張子を取ったものです. CATEGORIES はこのプログラムの種類を示します. この場合, 開発者向けのユーティリティということになります. 完全なリストはこのハンドブックの カテゴリ をみてください. MASTER_SITES はマスタ FTP サイトの URL です. もしローカルシステムに tarball がない場合には, ここから取得します. これは信頼できると考えられているサイトで, 通常はそのプログラムを インターネット上で公式に配布しているサイトです. (そのソフトウェアがインターネット上で「公式に」 配布されているとしたら) MAINTAINER は, 例えば新しいバージョンのプログラムが出た場合に, 必要であれば スケルトンの更新をおこなう保守担当者の 電子メールアドレスです. 次の数行はとりあえず飛ばします. .include <bsd.port.mk> この行は, この ports に必要なその他の命令やコマンドは bsd.port.mk に 入っているということを示しています. これらはすべての ports で共通のものなので, それぞれの Makefile に書いておく必要はありません. そのため単一の標準ファイルに まとめられているのです. ここでは Makefile がどう働くかを詳細に調査するのが目的ではありませんので, MAN3 で始まる行は, インストールの後に ElectricFence のマニュアルを 圧縮するために使用される, と言っておくだけで充分でしょう. これにより, 貴重なディスクスペースが保護されているわけです. オリジナルの port では install ターゲットが用意されていないので, do-install からの 3 行が この ports によって生成されたファイルを 正しい場所に置くために使用されます. <filename>files</filename> ディレクトリ ports のチェックサム算出には MD5 アルゴリズムを使用しているので, この チェックサム を含んでいる ファイルは md5 と呼ばれます. ちょっと混乱するかもしれませんが, このファイルは files という 名前のディレクトリに置かれています. このディレクトリは, ports に必要だけれども, 他のどこにも属さない 雑多なファイルも含んでいます. <filename>patches</filename> ディレクトリ このディレクトリには, FreeBSD ですべてを正常に動作させるのに 必要な パッチ が含まれています. <filename>pkg</filename> ディレクトリ このディレクトリには, 非常に役立つ三つのファイルが含まれています:- COMMENT — プログラムについての 1 行の説明. DESCR — より詳細な説明. PLIST — プログラムのインストール時に作成される, すべてのファイルのリスト. ports が動かないのですが, どうしたらよいでしょう おやおや. では, 次の四つのどれかをやってみてください: 自分で修正する. ports の仕組みに関する技術的な詳細については, アプリケーションの移殖方法をご覧ください. 苦情をいう. これは電子メールで だけ にしてください! このようなメールの宛先は &a.ports; です. なお, 必ず port の名前やバージョン, その port のソースや distfile(s) を どこから入手したか, どんなエラーが発生したのかを書いておいてください. 忘れてしまう. これはほとんどの場合最も簡単な方法です. ports のプログラムのうち必要不可欠な物はごくわずかです. FTP サイトからコンパイル済みのパッケージを入手する. “マスター”パッケージコレクションは FreeBSD の FTP サイトの パッケージディレクトリ に置いてありますが, まずあなたの近くのローカルミラーサイトを確認してください! ソースからのコンパイルに挑戦するよりも, パッケージを使うほうが (全体的に見て) ずっと確実に動作するでしょうし, より手っ取り早い方法でもあります. システムにパッケージをインストールするには, &man.pkg.add.1; を使ってください. 質問と回答集 Q. 私はモデムについての議論を しているのかと思っていました??! A.なるほど, あなたはきっとコンピュータの背面についている シリアルポートのことだと思ってしまったのでしょう. あるバージョンの Unixから別のバージョンの Unix へとプログラムを 移殖することを “porting” というのですが, ここで我たちは “porting” の結果 という意味で “port” を使っています. (コンピュータに関わる人々の悪しき習慣として, ひとつの同じ言葉を複数の まったく違う意味として使うことがあるのです.) Q. 私は, 標準以外のプログラムのインストールには packages を使うと 思っていたのですが. A. そのとおり. 通常は packages が最も手早くて簡単な方法です. Q. それではどうして面倒な ports があるのですか? A. いくつかの理由があります:- いくつかのソフトウェアのライセンス条件には, バイナリではなくソースコードでの 配布を求めているものがあります. バイナリ配布を信用していない人もいます. 少なくともソースコード があれば, ソースコードを読んで, (理論的には) 潜在的な問題点を自分で 見つけ出すこともできるはずです. ローカルなパッチを入手した場合, それを自分で追加するために ソースコードが必要になります. プログラムがいかにコンパイルされるべきかについて, あなたはパッケージを作った人とは 異なる見解を持っているかもしれません. どんな最適化オプションをつけるべきかとか, デバッグバージョンを作ってから それを strip するべきだとか, いや, そうするべきでない, などなど, 確固たる見解を持っている人もいるでしょう. ソースコードを手元に置いておきたい人たちもいます. 彼らは, 退屈したときに眺めたり, あちこち解析してみたり, ソースコードを 借用したり (もちろん, ライセンスが許せばの話ですが) するのです. あなたがソースコードを持っていなければ, それはソフトウェアとは 言えませんね! ;-) Q. パッチとは何ですか? A. パッチとは, あるバージョンから他のバージョンへどのように変更するかを 示す, (通常は) 小さなファイルです. “23 行目を削除”, “468 行目の後に これらの 2 行を追加”, または“197 行目をこのように変更”というような 内容を含んでいます. これは, “diff” という名前のプログラムで生成されます. Q. tarball とは一体何ですか? A. .tar または .tar.gz という拡張子を持つファイルです. (.tar.Z のようなバリエーションも ありますし, DOS のファイルシステム用に .tgz と短縮される場合もあります.) これは基本的に, 一つのファイルに固めた (.tar) ディレクトリツリーです. 圧縮されている (.gz) 場合もあります. これは元々 Tape ARchives (訳注: テープアーカイブ) (このため tar という名前なのです) で使われていたものなのですが, インターネット上でプログラムのソースコードを配布するために 広く使われている方法です. これらのファイルの中身を見たり, 展開したりすることもできます. FreeBSD の基本システムに付属する Unix 標準の tar コマンドを使ってみると 次のようになります:- &prompt.user; tar tvzf foobar.tar.gz &prompt.user; tar xzvf foobar.tar.gz &prompt.user; tar tvf foobar.tar &prompt.user; tar xvf foobar.tar Q. チェックサムとは何ですか? A. これは, チェックしたいファイル中のすべてのデータを加えて生成した 数値です. 何か文字が書き換わっていたら, チェックサムが一致しなくなります. そのため, 単純な比較だけで違いを見つけることができるのです. (実際には, 文字の位置が入れ替わるなどの, 単純な加算ではわからない問題も 見つけることができる複雑な方法で計算されています.) Q. 私は, CD-ROM から ports をコンパイルする にしたがって ports をインストールしていました. kermit をインストールしようとするまではうまくいっていました:- &prompt.root; make install >> cku190.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://kermit.columbia.edu/kermit/archives/. なぜ cku190.tar.gz が見つからないのでしょうか? 不良品の CD-ROM を買ってしまったのでしょうか? A. Kermit の権利を持つチームは, 私たちの CDROM に kermit の tarball を 入れることを許可しませんでした. 申し分けありませんが, 手動でファイルを 入手してください. このようなエラーメッセージが出たのは, あなたがそのときインターネットに 接続していなかったためです. あらかじめ上記のサイトのいずれかからファイルを ダウンロードしておけば, プロセスを再開することができます. (ダウンロードの際には, あなたに最も近いサイトを選ぶようにしてください. そうすれば, 時間とインターネットの帯域の節約になります) Q. kermit の tarball を入手しましたが, /usr/ports/distfiles に ファイルを置こうとすると, 書き込み権がないというエラーがでます. A. ports のしくみは /usr/ports/distfiles から tarball を探します. しかし, これは read-only の CD-ROM へのシンボリックリンクなので, ここにファイルを置くことはできません. 次のようにすれば, 他の場所を探すよう ports に指示することができます. - &prompt.root; make DISTDIR=/where/you/put/it install + &prompt.root; make DISTDIR=/where/you/put/it install Q. ports では, すべてを /usr/ports に置いたときだけ動作するのでしょうか? システムの管理者によると, 私の個人的なファイルは /u/people/guests/wurzburger に入れなければならないのですが, これでは うまくいかないように思います. A. PORTSDIR 変数と PREFIX 変数を変更することで, 違うディレクトリを 使用することができます. 例えば, &prompt.root; make PORTSDIR=/u/people/guests/wurzburger/ports install とすると, ports は /u/people/guests/wurzburger/ports でコンパイルされ, すべて /usr/local 以下にインストールされます. &prompt.root; make PREFIX=/u/people/guests/wurzburger/local install この場合, コンパイルは /usr/ports でおこない, /u/people/guests/wurzburger/local にインストールします. もちろん, 以下のように両者を組み合わせることも可能です. &prompt.root; make PORTSDIR=.../ports PREFIX=.../local install (省略せずに記述したら, このページに収めるには長すぎるのですが, 考え方は理解していただけたと思います) もし ports をインストールするたびに, これらを毎回タイプするのが 気に入らないのであれば, (正直に言って, 誰もそう思わないでしょう) これらを環境変数にセットしてしまうという手があります. Q. 私は, FreeBSD の CD-ROM を持っていませんが, 私はすべての tarball を 私のシステムに置いておきたいのです. そうすれば, 私は ports をインストール するたびに, 毎回ダウンロードが終わるのを待たなくてすむでしょう. これを一度におこなう簡単な方法はありませんか? A. ports コレクション全体の tarball を持ってくるには, 次のようにしてください. &prompt.root; cd /usr/ports &prompt.root; make fetch ports の下のディレクトリひとつの tarball を持ってくるには, 次のように してください. - &prompt.root; cd /usr/ports/directory + &prompt.root; cd /usr/ports/directory &prompt.root; make fetch ports をひとつだけ持ってくる方法は, きっと既にご存知だと思います. Q. マスタ FTP サイトから tarball を持ってくるより, 近くにある FreeBSD の ミラーサイトから持ってきた方が速いはずです. MASTER_SITES に書かれている サイト以外から持ってくるように ports に指示する方法はありませんか? A. もちろんあります. 例えば ftp.FreeBSD.ORG が MASTER_SITES に書かれている サイトより近いとしたら, 以下のようにしてください. - &prompt.root; cd /usr/ports/directory + &prompt.root; cd /usr/ports/directory &prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/distfiles/ fetch Q. ダウンロードをする前に, どんなファイルが必要なのか知りたいのですが. A. make fetch-list とすると, ports に必要なファイルの一覧を表示できます. Q. ports のコンパイルを途中で止める方法はありますか? 私はインストールをする前に いろいろとソースコードを解析したいのですが, 毎回 control-C を打たなければならないのが少し面倒です. A. make extract を実行すると, ファイル転送とソースコードの展開まで おこなったところで停止します. Q. 自分で ports を作ろうとしています. 私の作ったパッチが 正しく処理できることを確認できるように, コンパイルを止めたいのです. パッチのための make extract のようなものはありませんか? A. あります. make patch があなたのお望みのものです. おそらく PATCH_DEBUG オプションも同様に お役に立つことでしょう. ところで, あなたの努力に感謝いたします!! Q. あるコンパイルオプションはバグの 原因になるという話を聞きました. 本当なのでしょうか? どうやったら正しい設定で ports をコンパイルできますか? A. 本当です. gcc の バージョン 2.6.3 (FreeBSDの 2.1.0 と 2.1.5 に付属している バージョン) では, オプションを オプションなしで 使うと, バグのあるコードを出力します (ほとんどの ports は オプションを 使いません). コンバイラオプションは次のように定義 すべき です. &prompt.root; make CFLAGS='-O2 -fno-strength-reduce' install これを /etc/make.conf に書いておくこともできますが, 残念なことに すべての ports がこの指定を尊重してくれる 訳ではありません. もっとも確実なのは make configure を実行し, ソースディレクトリの Makefile を見て手で修整することですが, ソースが 多くのサブディレクトリにわかれていて, 各々に Makefile がある場合は 大変な仕事になります. Q. ports がたくさんありすぎて, 私の欲しいものがなかなか見つけられません. どんな ports が使えるのか, リストはどこかにありませんか? A. /usr/ports の中にある INDEX ファイルを見てみましょう. あるキーワードで ports コレクションを検索したければ, それも可能です. たとえば, 以下のようにすればプログラミング言語 LISP に関連した ports を見つけることができます: &prompt.user; cd /usr/ports &prompt.user; make search key=lisp Q. foo ports をインストールしたいのですが, それのコンパイルは すぐに停止して, bar ports のコンパイルが始まってしまいます. 一体どうして? A. foo ports が, bar ports の提供する何らかの機能を必要としているからです. 例えば foo が画像を使うとすると, bar は画像処理に必要な ライブラリを持っている, などです. または, bar は foo をコンパイルするのに必要なツールなのかもしれません. Q. ports から grizzle プログラムをインストールしましたが, まったく ディスクスペースの浪費です. 削除したいのですが, すべてのファイルが どこへインストールされたのかわかりません. 何か手がかりはありませんか? A. 大丈夫, 次のようにしてください. &prompt.root; pkg_delete grizzle-6.5 Q. ちょっと待ってください. 削除しようとするコマンドのバージョン番号を 知っていなくてはならないのでしょうか? あなたは, 私がバージョン番号を 覚えていることを本気で当てにしているのでしょうか? A. そんなことはありません. バージョン番号は次のようにすればわかります. &prompt.root; pkg_info -a | grep grizzle Information for grizzle-6.5: grizzle-6.5 - the combined piano tutorial, LOGO interpreter and shoot 'em up arcade game. Q. ディスク容量のことなのですが, ports のディレクトリは非常に膨大な容量を 使うように見えます. 残しておいた方がよいのでしょうか? 削除してしまっても よいのでしょうか? A. はい. インストールが首尾よく終わり, もうソースコードが必要でないと思うなら, それらを残しておく理由はないでしょう. 一番よい方法は, 次の通りです. &prompt.root; cd /usr/ports &prompt.root; make clean これは, すべての ports のサブディレクトリを調べ, 各 ports のスケルトン以外の削除をおこないます. Q. これを試してみたのですが, tarball や ports で使われたファイルが distfiles ディレクトリに残っています. これも削除してしまっても大丈夫ですか? A. はい. それを使った作業が終わったのであれば, 削除してしまっても大丈夫です. Q. 私はとてもとてもたくさんのプログラムを楽しみたいのです. 一度にすべての ports をインストールする方法はありませんか? A. 次のようにしてください. &prompt.root; cd /usr/ports &prompt.root; make install Q. やってみました. 時間がとてもかかるだろうと思ったので, そのまま実行を 続けさせて, 私は寝ました. 翌朝コンピュータを見てみると, 三つ半の ports しか 処理が終わっていませんでした. なにか悪かったのでしょうか? A. これは ports の中には私たちの決められないこと (例えば, あなたが A4 の 用紙に印刷したいのか, US レターサイズの用紙に印刷したいのかなど) について 質問してくるものがあるからです. それらの質問には手動で答える必要があります. Q. 私は一日中モニタの前に座って過ごしたりしたくないのですが. 何かよいアイデアはありませんか? A. では, あなたが寝に / 仕事に / 公園にいく前に以下を実行してください:- &prompt.root; cd /usr/ports &prompt.root; make -DBATCH install これでユーザの入力を要求しないすべての ports をインストールします. そして, 戻ってきてから, 次のように実行してください. &prompt.root; cd /usr/ports &prompt.root; make -DIS_INTERACTIVE install そして, 残りの作業を実行してください. Q. 私たちは ports コレクションにある frobble を使っています. ですが, 私たちの必要に応じて ports を変更したところがあるのです. 自分でパッケージを作って, それを私たちのサイトのまわりに 簡単に配布できるような方法がありますか? A. もちろんあります. 変更点をパッチにする方法は知っていますよね:- - &prompt.root; cd /usr/ports/somewhere/frobble + &prompt.root; cd /usr/ports/somewhere/frobble &prompt.root; make extract &prompt.root; cd work/frobble-2.8 [あなたのパッチを当ててください] &prompt.root; cd ../.. &prompt.root; make package Q. この ports の技術は本当に賢いですね. どのようにして動いているのか 私はどうしても知りたいと思います. その秘密は何ですか? A. 秘密は一切ありません. Makefiles + URL="file://localhost/usr/ports/Mk/">Makefiles ディレクトリ にある bsd.ports.mk と bsd.ports.subdir.mk ファイルを見るだけです. 複雑なシェルスクリプトを嫌う読者は, このリンクを追いかけないほうが よいでしょう. 自分で port を作る 原作: &a.jkh;, &a.gpalmer;, &a.asami;, &a.obrien; and &a.hoek;. 28 August 1996. 訳: &a.jp.simokawa;, &a.asami;. 10 November 1996. 自分で port を作ることに興味がありますか, すばらしい! これから, FreeBSD 用のportを作る際の, いくつかのガイドラインを 説明します. 実際にportをコンパイルするときのほとんどの仕事は - /usr/share/mk/bsd.port.mk + /usr/ports/Mk/bsd.port.mk というファイルでおこないます. Portsコレクションについてのさらに細かい内部の働きについては, そちらの ファイルを参照してください. これにはコメントが細かく書いてありますので, Makefile を読むのにあまり慣れていない人でも, 得るものはとても大きいで しょう. ここでは, 変更可能な変数の一部についてのみ記述しています. ほとんどの変数はbsd.port.mk の始めに記述があります. また, このファイルは非標準のタブの設定になっています. Emacs や Vim はファイルのロード時にこれを認識しますが, viやexでは, ファイルをロードしたら :set tabstop=4 のようにして正しい値を設定する ことができます. 3分porting この節では, 簡単なportの方法について説明します. 多くの場合これ では不十分ですが, まあうまくいくかどうか試してみて損はないでしょ う. まず, 元のtarファイルをDISTDIRに置きます. デフォルトは/usr/ports/distfilesです. 以下では, ソフトウェアはそのままコンパイルされるとします. つまり, FreeBSDのマシンで動かすために, 変更がまったく必要ない とします. もしなにか変更が必要な場合には次の節も参照する必要 があります. <filename>Makefile</filename> の作成 最小限のMakefile は次のようなものです: # New ports collection makefile for: oneko # Version required: 1.1b # Date created: 5 December 1994 # Whom: asami # # $Id$ # DISTNAME= oneko-1.1b CATEGORIES= games MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ MAINTAINER= asami@FreeBSD.ORG MAN1= oneko.1 MANCOMPRESSED= yes USE_IMAKE= yes .include <bsd.port.mk> おわかりになりますでしょうか. $Id$があ る行の内容については, 気にしないでください. これはこのファイル がportsツリーに書き込まれるときにCVSによって自動的に書 き込まれます. もっと詳しい例が見たければ, Makefileのお手本 の節をご覧ください. Package記述ファイルの作成 どのようなportでも, packageにするしないに関わらず, 3つ の記述ファイルが必要です. pkgサブディレクトリにある, COMMENT, DESCR, それに PLISTです. <filename>COMMENT</filename> これには, そのportについての説明を1行で書きます. Package の名前, バージョン番号等は 含めないでください. たとえば, こんな具合です: A cat chasing a mouse all over the screen. <filename>DESCR</filename> これは, そのソフトウェアについての, すこし長い説明を記述します. その port が何をするのかについての数段落程度の 簡潔な解説があれば十分です. このファイルはマニュアルでもなければ, 使用方法やコンパイル方法についての細かい 説明書でもありません. 特に, READMEファイル manpage をコピーしようとしてしている場合には 注意してください. これらは多くの場合, そのポートの簡潔な説明に なっていなかったり, 扱いにくい形式(manpage の場合, 行を揃えるために空白が調整されます)になっていたりします. もしこのソフトウエアに公式の WWW のホームページがあれば, - ここに書いて下さい. + ここに書いて下さい. 自動化ツールが正しく動作するように, + Web サイトのうちの ひとつ には, 前に + WWW: を付け加えてください. このファイルの最後にあなたの名前を書くことが 推奨されています. たとえば, こんな具合です. This is a port of oneko, in which a cat chases a poor mouse all over the screen. : (うんぬん.) -http://www.oneko.org/ +WWW: http://www.oneko.org/ - Satoshi asami@cs.berkeley.edu <filename>PLIST</filename> このファイルには, このportによってインストールされるファ イルが列挙されます. このファイルはpackageを作る際のリス トとして使われるため, `packing list' とも呼ばれます. ここ に書かれているファイル名は, インストール時のプレフィックス (普通は /usr/local か /usr/X11R6) からの 相対パスです. MANn 変数を使用する場合(使用することが推奨されています)には, マニュアルはここに入れないでください. 簡単な例を載せておきましょう: bin/oneko lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpm @dirrm lib/X11/oneko 'Packing list'の詳細については, &man.pkg.create.1; の マニュアルを参照してください. すべてファイルを列挙しなければなりませんが, ディレクトリ名は必要ありません. また, ports がインストール時にディレクトリを作成する場合には, @dirrm の行を加えて, その port が削除されるとき, そのディレクトリも削除されるようにしてください. このファイルには, ファイル名をアルファベット順に並べるようにしてください. port のアップグレートのとき, 楽に確認ができるようになります. チェックサムファイルの作成 ただ, make makesum と入力するだけです. bsd.port.mk にルールがあるので, 自動的にfiles/md5が生成されます. Portのテスト そのportが正しく動くことを, package化を含めて確認してください. 以下の重要なポイントを確認してください. PLIST にその port がインストールしないものが含まれていないこと. PLIST にその port がインストールする全てのものが含まれていること. reinstall ターゲットを使うことによって, 何度でもインストールが可能こと. deintall の際に 後片付け をすること. 推奨されるテストの手順 make install make package make deinstall pkg_add `make package-name` make deinstall make reinstall make package package および deinstall の段階で, どんな警告(warning)も出力されないことを確認してください. ステップ3の後, 新しいディレクトリが全て正しく消去されているかを 確認してください. また, ステップ4の後にそのソフトウェアを使用してみて, package からインストールされた場合に正しく動作するかを 確認してください. <command>portlint</command> でチェック portlintを使って, あなたの port が我々のガイドラインそっているかを確認してください. portlint プログラムは ports コレクションに含まれています. 特に, Makefile が正しい形式になっているか, package の名前が正しいか, をチェックするのに良いでしょう. Portの送付 まず, やってよいことといけないこと についての節を読んでください. さあ, あなたのportに満足したら, あとはそれをFreeBSDのメイ ンのportsツリーに置いて, 皆に使ってもらうだけです. いまある work ディレクトリや pkgname.tgz パッケージは必要ありませんから, まず消去してください. あとは, バグレポートの中に shar `find port_dir` の出力を, &man.send-pr.1; プログラムを使用して送ってください. &man.send-pr.1; についての詳細は, バグ報告と一般的な論評 を参照してください.) もし, 圧縮していない状態で, 20KB以上あるようなポートであれば, 圧縮して tar ファイルにして, バグレポートに入れる前に &man.uuencode.1; を使用してください. (20KB以下のものでも, tar ファイルにして送ってもよいですが, あまり歓迎されません). バクレポートの category は ports, class は change-requestを必ず使用してください. (レポートを confidential (内密) にしないようにしてください!) もう一度, オリジナルのソースファイル, work ディレクトリ, make package で作成したパッケージが含まれていないこと を確認してください. 以前, 新しい port をわれわれの ftp サイト (ftp.freebsd.org) にアップロードするようにお願いしたことがありますが, 現在このサイトの incoming ディレクトリは読み出し不可になっており, いまでは推奨されていません. 沢山の海賊版ソフトウェアがそこに置かれたためです. 私たちは, 何か不明な点があったらあなたに確認したのち, それをツリーへ置きます. あなたの名前は, FreeBSD ハンドブックやその他のファイルの “Additional FreeBSD contributors” のリストにも載るでしょう. う〜ん, 素晴らし い. :) 本格的なport 残念ながら, 移植がそう簡単ではなく, 動かすために多少の変更が 必要な場合も多いでしょう. この節では, portsコレクション の方法論にのっとって, そのような場合にどのように変更を施し, 動 くようにしたらよいかを順を追って説明します. port構築の詳細 まず, あなたがportのディレクトリで make とタイ プしてから起こる一連の出来事について,順を追って説明しま す. ここを読むときには, 他のウィンドウで同時に bsd.port.mk も開いておくとよいかもしれません. しかし, bsd.port.mkが何をしているのか, 完全に理解 できなくても心配する必要はありません. そう多くの人が理解して いるわけではないですから... f(^_^;) まず, fetch というターゲットが実行されます. このfetchターゲットは ローカルディスクのDISTDIRに配布ファ イルがあるようにするのが役目です. もし, fetchが必要なファ イルをDISTDIRに見つけることが できなけ れば, Makefileに指定されているURL MASTER_SITES, そして私たちのFTPサイトで ある ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/ (ここ には, 私たちが取ってきたファイルを バックアップとして置いてあ ります) に探しにいきます. そして, ユーザのサイトがインター ネットに 直接接続されている場合には, FETCH を使って, その名前のファイルを取っ てきて, DISTDIRに保存します. 次に実行されるのは extract ターゲットです. これは, DISTDIRにある, 配布ファイル (普通は gzipされたtarファイル) を読み, ソースを一時的な作業ディレ クトリWRKDIR (デフォルトは work) に展開します. 次に, patch というターゲットが実行されます. まず, PATCHFILESに定義されている, すべてのパッ チをあてます. 次にもしPATCHDIR (デフォ ルトは patches サブディレクトリ) にパッチが存在す れば, これらをアルファベット順にあてます. 次に実行されるターゲットは configureです. これには, い ろいろな場合があります. もし存在すれば, scripts/configure が実行されます. もし, HAS_CONFIGURE あるいは GNU_CONFIGURE がセットされていれば, WRKSRC/configure が実行されます. もし, USE_IMAKE がセットされていれば, XMKMF (デフォルト: xmkmf -a) が実行されます. 最後に, build というターゲットが実行されます. これは, その port の専用の作業ディレクトリ (WRKSRC) にい き, コンパイルするのが役目です. もし USE_GMAKE がセットされていれば, GNU make が使用されます. さもなければFreeBSDの make が使用されます. 上記はデフォルトのルールです. さらに, pre-何とか や post-何とか というターゲット が定義してあった り,そのような名前のスクリプトが scripts サブディレクトリに置いてある場合には, それらはデフォルトの動作の前 後に実行されます. たとえば, post-extract というターゲットがMakefile で定義されていて, pre-build というファイルが, scripts サブディレクトリにあるとすると, post-extractターゲットは, 通常の展開動作のあとに呼 び出され, pre-build スクリプトはデフォルトのコンパイ ルのルールが実行される前に実行されます. もし動作が簡単であれ ば, Makefile のターゲットを使用することが推奨されています. な ぜならば, そのportが何らかのデフォルトではない動作を必要とす るのかどうかが一箇所にまとめて書いてあった方が他の人に 理解しやす いからです. デフォルトの動作は bsd.port.mk の do- 何とか というターゲットでおこなわれます. たとえば, portを展開するコマンドは, do-extract というターゲットにあります. もし, デフォルトのターゲットに 不満があれば, do- something というターゲッ トを再定義することによって, どのようにでも直すことができます. “メイン”のターゲット (例えば, extract, configure等) は, すべての前段階が実行されていること を確認して, 実際のターゲットやスクリプトを呼び出す以外のこと はしません. bsd.port.mkはこれらが変更されることは仮定してい ませんので, もし, 例えば, 展開の仕方を直したいときには, do-extract を直し, 絶対にextractには手を 触れないでください. これで, ユーザが make と入力したときに何が起こ るのかが理解できたと思います. では, 完璧なportを手順を追っ て作ってみましょう. オリジナルのソースの入手 オリジナルのソースを, (普通は) 圧縮されたtarファイルの形 ( foo.tar.gz あるいは foo.tar.Z) で入手して, それを DISTDIR にコピーします. 可能なかぎり, 広 く使われている主流の ソースを使用するようにしてください. もし, ネットワークへの接続のよい FTP/HTTP サイトを見つけるこ とができなかったり, 頭にくるような非標準的な形式しか持ってい ないサイトしか見つけられないときには, 自分で管理する確実な ftp か http サーバ (たとえば, あなたのホームページ)に置くこと ができます. MASTER_SITES に正しく反映されていることを確認してください. もしも, そのような都合の良く, 安心な置き場所が見つけられない 場合(あなたが FreeBSD の committer であれば, 自分の public_html ディレクトリに置けます), 私たちが, ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/distfiles/LOCAL_PORTS/ に置き場所を提供できます. この場所は, 変数 MASTER_SITE_LOCAL を使って参照してください. これについての問い合わせのメールは &a.ports へお願いします. その port の配布ファイルが特に理由もなく, しょっちゅう変る場合には, 配布ファイルをあなたのホームページに置いて MASTER_SITESの最初に入れてください. こうすることによって, ユーザ利用する場合に checksum mismatch エラーが起るのを防ぎ, 我々の ftp サイトの保守の負担を減らすことができます. もし, master site がたった一つしかない場合には, あなたのサイトにバックアップを置いて MASTER_SITES の2番目に加えてください. もし, あなたのportに必要ないくつかの追加パッチがインター ネット上で手に入るのならば, それらも取ってきて, DISTDIR に置きます. もし, それらがメイン のソースのtarファイルとは別のサイトにあっても, 心配する必要 はありません. そのような状況にはちゃんと対応できるようになっ ています. (以下のPATCHFILESの記述 をご覧ください). Portの修正 適当なディレクトリにtarファイルを展開して, FreeBSDの最新の バージョン上で, 正しくコンパイルできるために必要なあらゆる変 更を施します. 最終的に処理は自動化するわけですから, 何をおこなっ たかを注意深く記録しておきましょう. あなたのport が完成した暁には, ファイルの削除, 追加, 修正を含むすべての処 理が, 自動化されたスクリプトやパッチファイルで おこなえるようになっ ていないといけません. もし, あなたの port のコンパイルやインストールのために必要 な手作業があまりに多いようならば, Larry Wall の模範的な Configure スクリプトでも参考にしたほうがいいかもしれませ ん. 新しいportsコレクションは, 最小のディスクスペースで, 個々のportがエンドユーザにできるだけ“プラグ & プレ イ”の状態でmakeできることをめざしています. あなたが作成し FreeBSD の ports に寄付されたパッチファイル, スクリプトおよびその他のファイルは, 明示的に記述されている場合 を除いては, BSDの標準的な著作権条件によりカバーされていると見な されます. パッチをあてる port の過程で追加されたり変更されたファイルは再帰的diffで変 更点を取り出すことができます. パッチは適当にまとめて, patch-xx という名前のファイルに入れてくだ さい. xx はパッチが適用される順番を示します — これらは, アルファベット順, つまり aa が 最初, つぎに ab などとなります. これらのファイル をPATCHDIRに置いておくと, 自動的に適用さ れるようになっています. すべてのパッチは WRKSRC (通常は, portのtarファイルが展 開されるところで, makeが実行されるところと同じです) からの相 対パスになります. 修正やアップグレードを容易にするため, 2つ 以上のパッチが同じファイルを修正するのは避けてください. (例, patch-aaとpatch-abが共にWRKSRC/foobar.c を修正する, など.) コンフィグレーション カスタマイズのために追加したいコマンドがあれば, configure という名前のスクリプトに入れて scripts サブディレクトリに置きます. 上で述べたよ うに, pre-configure あるいは post-configure という Makefile のターゲットおよび/あるいはスクリプトで処理す ることもできます. ユーザからの入力の扱い もし, そのportがビルド, コンフィグレーション, インストー ルの際にユーザからの入力を必要とするならば, Makefileで IS_INTERACTIVEをセットしてください. これによって, 深夜, 自動的にたくさんのportをコンパイルすることが可能にな ります. 環境変数BATCHがセットされていると IS_INTERACTIVE の定義されているportはスキップされ ます (そして, ユーザがINTERACTIVEという変数をセッ トすると入力を必要とする port のみコンパイルされま す). もし, 適切なデフォルト設定があるのであれば, PACKAGE_BUILDING 変数をチェックして,それが設 定されて いる場合には, ユーザ入力のスクリプトを起動しないように してください. こうすることによって, CD-ROM や ftp に 置く packageを我々が作成することができます. Makefileの作成 Makefileの作成は非常に単純です. 繰り返しになりますが, 始める まえに, すでにある例を見てみることをお奨めします. またこのハ ンドブックにはMakefileのお手本 があります. それを見て, Makefile内の変数の順番や空行を入れると ころなどの参考にしてください. そうすると他の人々にも読みやすい ものとなります. では, Makefileをデザインするときに問題となるところを順に追っ て見てみましょう. オリジナルのソース ソースはDISTDIRに, 標準的なgzipされた tarファイルとして置かれていますか? そうであれば, 次のステッ プに進めます. そうでなければ, 変数 EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX, DISTFILES を適当に書き換えないといけません. どれだけ変更しないといけないかは, あなたのportの 配布ファイルがどの程度標準からかけはなれているかによりま す. (最もよくある場合は, gzipではなく普通のcompressコマンド でtarファイルが圧縮されている場合で, EXTRACT_SUFX=.tar.Z とするだけです.) 最悪の場合には, 自分で do-extract ターゲットを作 成して, デフォルトを上書きすることもできます. しかし, そこま でする必要があることはめったにないでしょう. <makevar>DISTNAME</makevar> DISTNAME には port の名前の基幹部分を入れ ます. デフォルトのルールでは, 配布ファイルのリスト (DISTFILES) は DISTNAME EXTRACT_SUFX という名前 になっています. 例えば, foozolix-1.0.tar.gzの場 合, 通常のtarファイルだと, DISTNAME=foozolix-1.0 のようになります. さらにデフォルトのルールでは, tarファイルは work/DISTNAME というサブディレクトリ に展開されることを仮定しています, 例えば work/foozolix-1.0/ といった具合いです. これらの動作はもちろんすべて変更可能です. デフォルトのルー ルは最も標準的な場合を仮定しているだけです. まず, port が複 数の配布ファイルを必要とするときには, 単に明示的に DISTFILESを設定してください. もし, DISTFILES の一部だけが実際に展開される場合 には, それらをEXTRACT_ONLY に設定してくだ さい. この変数が定義されている場合には, 展開時に DISTFILESに優先して利用されます. 残りのファ イルもDISTDIRに取ってきますが, 展開時に はなにもせずに後で使うためにそのまま置いておかれます. <makevar>PKGNAME</makevar> もし, DISTNAME が我々の package の名前についてのガイドライン に沿ったものでない場合には, PKGNAME にもっと良い名前を設定してください. 詳細は上記のガイドラインを参照してください. <makevar>CATEGORIES</makevar> (分類) 完成した package の実体は /usr/ports/packages/All に置かれます. また, 1つかそれ以上の /usr/ports/packages のサブディレクトリからのシンボリッ クリンクが作られます. それらのサブディレクトリの名前が CATEGORIES という変数によって指定されます. これは, ユーザがFTPサイトやCD-ROMのpackageの山を渡り歩 くことを容易にするためです. 現在存在する カテゴリを見て, そ のportに適したもを選んでください. このリストは, この port が port tree のどこに import されるかも決定します. 2つ以上のカテゴリを指定した場合には 最初のカテゴリで指定されるサブディレクトリに置かれること になります. 適切なカテゴリを選ぶ方法については, カテゴリ の節を参照してください. もしその port が本当に現在存在するすべてのものとは異なって いる場合には, 新しいカテゴリ名を作ることもできます. その際には, &a.ports 宛てに新しいカテゴリ名を提案する メールを送ってください. カテゴリ名については, なんのエラーチェックも行なわれません.ミスタイプがあっても make package はなにも考えずに 新しいディレクトリを作ってしまいますので, 注意してください. <makevar>MASTER_SITES</makevar> オリジナルの配布ファイルを指し示す FTP または HTTP の URL のディ レクトリ部分までを MASTER_SITES に記録しま す. スラッシュ (/) を最後につけることをお忘れなく. 配布ファイルがシステム上に存在しないときに, makeマクロは FETCH でこの変数に指定されたサイトから取っ てきます. 複数の, できれば異なる大陸のサイトをこのリストに入れておく ことが推奨されています. これによって, 広域ネットワークにトラ ブルがあった場合でも成功する可能性が高くなります. 私たちはさら に, 自動的に最も近いマスタサイトを検出して, そこから取って くるメカニズムの導入を計画しています. オリジナルのtar ファイルが, X-contrib, GNU, Perl CPAN, TeX CTAN または Linux Sunsite などの有名なアーカイブにある場合には, MASTER_SITE_XCONTRIB, MASTER_SITE_GNU, MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN および MASTER_SITE_SUNSITE を利用することで, 簡単にこれらのサイトを 指定することができます. あとは MASTER_SITE_SUBDIR にアーカイ ブ内でのパスを指定するだけです. 以下に例を示します. MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications ユーザは/etc/make.conf中で MASTER_SITE_* 変数を設定 することによって, デフォルトの FTP サイトではなく, これらの 有名なアーカイブの ミラーの中で好みのものを使用することが可能 です. <makevar>PATCHFILES</makevar> もし, オリジナルの配布ファイル以外にもFTPかHTTPで手に入る パッチが必要な場合には, PATCHFILESにファ イル名を, PATCH_SITESにサイトとディレクト リの名前を MASTER_SITES と同様に設定してく ださい. そのパッチ内のファイル名ががソースツリーの 一番上のディレク トリ (WKRSRC) からの相対パスになっていな い場合には, PATCH_DIST_STRIPを指定してく ださい. 例えば, パッチ内のファイル名にすべて余計な foozolix-1.0/ がついている場合には, PATCH_DIST_STRIP=-p1としてください. これらのパッチは圧縮されていても大丈夫です. ファイル名が .gz か .Z で終わる場合には自動的に復元 されるようになっています. もしパッチが, 文書などその他のファイルと一緒に gzip された tarファイルで配布されている場合には，単純に PATCHFILES を使うことはできません. このような場合には, このパッチの tar ファイルの名前と場所を DISTFILES と MASTER_SITES に加えます. それから, pre-patch ターゲットで, パッチコマンドを走らせるか, パッチファイルを PATCHDIR ディレクトリに patch-xx という名前でコピーするかして, パッチを適用するようにします． 普通の gzip か compress された tar ファイルであれば, 通常のソースファイルと一緒にその時までに 展開されていますので, 明示的に展開する必要はありません. もし, 後者の方法を使用する場合には, すでにそのディレクトリにある なにかを上書きしないように, 注意する必要があります. さらに, pre-clean ターゲットにコピーしたパッチファイル を削除するコマンドを追加するのを忘れないでください. <makevar>MAINTAINER</makevar> あなたのメールアドレスをここに入れてください. お願いします. :) 保守担当者(maintainer)の責任についての詳細は， Makefile 中の MAINTAINER の節をご覧ください． 依存関係 このプログラムが他のportに依存する場合には, 必要なものが 自動的に作られるようにすることができます. そのために, 以下の 5つの変数が用意されています. よくあるケースのためにあらかじめ設定された依存変数や, いくつかの依存関係の制御のための変数があります. <makevar>LIB_DEPENDS</makevar> Port が必要とする非標準の共有ライブラリを この変数で指定 します. これは lib: dir: target という組のリストで, うち lib が共有ライブラリの名前, そして dir がそのライブラリが見つからない場合にインストールする port のあるディレクトリで, target はそのディレクトリで呼ばれるターゲットです. 例えば, LIB_DEPENDS= jpeg.9:${PORTSDIR}/graphics/jpeg:install と指定してあれば, まずメジャーバージョンが9のjpegライブ ラリがあるかどうか確認し, ない場合にはportsツリーの中の graphics/jpeg というサブディレクトリに移動し, そこ でコンパイルとインストールを行ないます. target の 部分は, DEPENDS_TARGET (デフォルトは install) と等しいときには省略できます. 前半の lib 部分は ldconfig -r | grep -wF への引数になります. この変数には正規表現を入れられません. この依存関係は2度チェックされます. まず extract ターゲットで, 次に install でチェックされます. (これは, その port を作成するマシンとインストールする マシンが違う場合でも, きちんとそのライブラリが利用できる ことを確認するためです.) また, 依存するもの名前は package の中にも含まれますので, ユーザのシステムに存在しなければ, pkg_add が自動的にインストールします. <makevar>RUN_DEPENDS</makevar> Port を使用する際に必要となるファイルまたはプログラムがある ときにはこの変数で指定します. これは path: dir :target とい う組のリストで, path がファイルまたはプログラムの 名前, そして dir がそれが見つからない場合に作成する ためのディレクトリ名で target はそのディレクトリで呼ばれるターゲットです. path の最初の文字がスラッ シュ (/) の場合にはファイルかディレクトリ とみなし, その存在を test -e でチェックします; そうでない場合には 実行可能であると仮定し, which -s を使って そのプログラムがユーザのサーチパス上に あるかどうか確認します. 例えばMakefileに以下のように書いてあるとします. RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \ wish8.0:${PORTSDIR}/x11-toolkits/tk80 まず, /usr/local/etc/innd というファイルかディレクトリが存在 するか確認し, ない場合にはportsツリーの中の news/inn というサブディレクトリから作られます. ま た, wish8.0 というプログラムがユーザのサーチパス中 にあるかどうか探し, ない場合には同じくportsツリーの x11-toolkits/tk80 というサブディレクトリから作られます. この例で, innd は実際にはプログラムです; この ように, プログラムであっても標準のサーチパス以外のところに あるようなものの場合には, 絶対パスで指定してください. この依存関係はinstall ステージのはじめでチェック されます. また, packageを作る際に必要となるportのpackage名 が記録され, pkg_addを使用すると ユーザのシステムに存在しない場合には自動的にそちら のpackageもインストールされるようになります. target の部分は, DEPENdS_TARGET と同じ場合には省略可能です. <makevar>BUILD_DEPENDS</makevar> Port のコンパイルに必要なファイルまたはプログラムがある ときは, この変数で指定してください. RUN_DEPENDSと同 様に, これは path: dir :target という組のリストです. 例 えば, BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip は unzip という名前のプログラムを探し, 見つから ない場合にはarchivers/unzip サブディレクトリで作 れという意味になります. ここでは “コンパイル” と一口にいいましたが, この変数は実際 にはファイルの展開から実際のコンパイル・リンクまで 全部をま とめて面倒を見てくれます. この依存関係は extract ステージからチェックされます. target の部分は DEPENDS_TARGET と同じ場合には省略可能です. <makevar>FETCH_DEPENDS</makevar> この変数は, portを取ってくるのに必要なファイルまたはプロ グラムを指定するのに使います. 上の二つと同様に, これは path: dir :target という組のリストです. 例えば, FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2 としておけば, ncftp2 という名前のプログラムを探 し, 見つからない場合にはnet/ncftp2 サブディレク トリにいってインストールします. この依存関係は fetch ステージからチェックされます. target の部分は DEPENDS_TARGET と同じ場合には省略可能です. <makevar>DEPENDS</makevar> 上記の四つのいずれにもあてはまらないような 依存関係がある場 合, または他の port がインストールされれているだけではなく, ソースが展開されている必要がある場合にはこの変数 を使います. これは dir :target という形式のリスト になります. 上記の四つと違って特に “確認”するものがありませんので. よくある依存関係を表す変数 もし ports が X Window System を必要とするのであれば, USE_XLIB=yes を定義してください. (これは USE_IMAKEも意味します) BSD make の代りに GNU make を必要とする場合には, USE_GMAKE=yes を定義. 動作するのに GNU autoconf を必要とする場合には, USE_AUTOCONF=yes を定義. 最新の qt toolkit を使用 する場合には USE_QT=yes を定義. perl 言語のバージョン5 を必要とする場合には, USE_PERL5=yes を定義してください. (特に最後のは重要で, FreeBSD のいくつかの バージョンでは基本システムに perl5 を含みますが, 他のものは含んでいません.) 依存関係に関する注意 上で述べたように, 依存する ports が必要になったときに呼ばれるデフォルトのターゲットは DEPENDS_TARGET で, そのデフォルトは install です. これは, ユーザの使用する変数で, port の Makefile で定義されるものではありません. もし, あなたのportが特別な方法で, 依存関係を扱う必要が ある場合には, DEPENDS_TARGET を再定義するのではなく, *_DEPENDS 変数の :target の部分を利用してください. make clean とタイプしたときには, 依存する port も自動的に clean されます. もしそうしたくない場合には, NOCLEANDEPENDS を環境変数として設定してください. 無条件に他の port に依存させるには, 特別に nonexistent という文字列を BUILD_DEPENDS あるいは RUN_DEPENDS の最初のフィールドに使用してください. これは, 他の port のソースが必要なときのみ使用してください. target も指定することによって, コンパイルの時間を節約することができます. 例えば, BUILD_DEPENDS= /nonexistent:${PORTSDIR}/graphics/jpeg:extract これは, 常に JPEG port の directory に行きソースの展開を行ないます. あなたがやりたいことが他の方法ではできない場合以外は, DEPENDS を使わないでください. これは常に 他の port の作成を行い(さらにデフォルトでインストール を行い), package も作成します. もし本当にこれがあなたの やりたいことでしたら, 代りにこれを BUILD_DEPENDS と RUN_DEPENDS で書くことをお勧めします — 少なくとも意図が明確になります. コンパイル時の特別な指定 GNUのmakeを使う場合には, USE_GMAKE=yes と指定してください. Port に GNU の configure が含まれ ている場合には, GNU_CONFIGURE=yes を使います(これは, HAS_CONFIGURE も意味します). configure に追加の引数 (デフォルトでは, GNU の configure では --prefix=${PREFIX}, GNUでない configure では空) を渡したい場合には追加部分を CONFIGURE_ARGS で指定してください. そのパッケージが autoconf を使用する場合には, USE_AUTOCONF=yes を使います. これは, GNU_CONFIGURE も意味し, configure の前に autoconf を実行します. X Window Systemのアプリケーションなど, imakeを 使って Imakefile から Makefile を作成するportの場合には USE_IMAKE=yes を指定してください. コンフィグレー ションステージで自動的にxmkmf -a が実行されます. も し フラグが問題をもたらすなら, さらに XMKMF=xmkmfとしてください. もし, port が imake を使用するけれども, install.man ターゲットがない場合には, NO_INSTALL_MANPAGES=yes を指定してください. ついでに, その port のオリジナルの作者を探し出して八つ裂きにすると いいでしょう.:> Portの Makefile が all 以外のものをメインのター ゲットとしている場合には, ALL_TARGET でそ れを指定してください. install と INSTALL_TARGET も同様です. もし, port の元の Makefile が all 以外のターゲットをメインのターゲットとしている場合には, ALL_TARGET をそれに合わせて設定してください. install と INSTALL_TARGET についても同様です. <makevar>NO_INSTALL_MANPAGES</makevar> あなたの port がimakeは使うものの install.man ターゲットを持っていない場合, NO_INSTALL_MANPAGES=yes を指定してください. つい でに, 作者を探し出して八つ裂きにするといいでしょ う. (-_-#) 特別な配慮 Portを作成する場合, 考慮しなくてはいけないことがさらにいくつかあります. この節では, それらのうちもっともありがちなものについて説明します. ldconfig 共有ライブラリをインストールするときには, 共有ライブラリのキャッシュを更新するために port の Makefile の post-installtarget から${LDCONFIG} -m を走らせてください. このコマンドの引数は共有ライブラリのインストールしてある ディレクトリ (通常 PREFIX/lib) です. また, pkg/PLIST に @exec /sbin/ldconfig -m と @unexec /sbin/ldconfig -R の組を入れて, package をインストールした場合にも共有ライブラリがすぐ使え, 削除の際にも, システムがまだライブラリが存在すると 誤認しないようにしてください. この行は共有ライブラリを指定する行のすぐ後に 書くのがよいでしょう: lib/libtvl80.so.1 @exec /sbin/ldconfig -m %D/lib @unexec /sbin/ldconfig -R 絶対に引数なしでただ ldconfig とだけ書いてある行を Makefile や pkg/PLIST ファイルに入れないでください. このコマンドを実行すると, 共有ライブラリのキャッシュが /usr/lib の内容のみとなり, ユーザのマシンにさまざまな問題をもたらします (「ぎゃぁ! このportをインストールしたら xinit が使えなくなっちゃった!」). この掟を破った者は, 永久に地獄の底で苦しみ続けるように, 閻魔様に頼んでおきます. ELF 対応 FreeBSD は 3.0-RELEASE で ELF に移行しましたので, シェアードライブラリを作成するたくさんの port を ELF 対応 にする必要があります. 3.0 システムは ELF としても a.out としてmも 動作しますし, 我々は非公式ではありますが, できるだけ長い間 2.2 システムのサポートをしたいと思っていますので, 複雑な状況です. 以下は a.out のみに対応している port をどのように a.out と ELF 両方に対応させるかのガイドライ ンです. このリストの一部は, 移行時にしかあてはまらないものもありますが, 古い port をアップグレードしたい場合に参考になるように, しばらくのあいだは残しておきます. a.out ライブラリの退避 a.out ライブラリは, /usr/local/lib から, aout サブディレクトリ に移動しなくはなりません. (もし移動しないと, ELF ports がそれらをあっさり上書きして しまいます.) 3.0-CURRENT の src/Makefile にある move-aout-libs ターゲット (aout-to-elf から呼ばれます) がその移動をしてくれます. a.out ライブラリを移動するだけなので, ELF と a.out の両方のライブラリが標準的な ディレクトリにあるシステムでは, このターゲットを実行しても安全です. フォーマット port ツリーは package をそのマシンのフォーマットで作成します. つまり, 2.2 では a.out, また 3.0 では `objformat` の結果によって, a.out か ELF になります. また, いったん a.out ライブラリをサブディレクトリに移動すると a.out ライブラリの作成はサポートされません. (つまり, あなたがにをすれば良いのかを理解しているのならば, うまく作成できるかもしれませんが, 自力でやらなければならないということです) もし port が aout でしか動作しないのなら, BROKEN_ELF に原因を説明する文字列を設定してください. この変数が設定された port は, ELF システム上でのビルドの際スキップされます. PORTOBJFORMAT bsd.port.mk において PORTOBJFORMAT は aout か elf に設定され, 環境変数 CONFIGURE_ENV, SCRIPTS_ENV, MAKE_ENV の中で export されます. (2.2-STABLE では常に aout になります). また, PORTOBJFORMAT=${PORTOBJFORMAT} として PLIST_SUB に渡されます. (以下にある ldconfig に関するコメントを参照して下さい.) この変数は, 以下のようにして bsd.port.mk 中で設定されます. PORTOBJFORMAT!= test -x /usr/bin/objformat && /usr/bin/objformat || echo aout この変数を使って, port の make の過程で何をすべきかを決定すべきですが, もし port の configure スクリプトが元々, ELF システムを自動的に検出するのであれば, PORTOBJFORMAT を参照する必要はありません. 共有ライブラリの作成 以下は, a.out と ELF での共有ライブラリの扱いの違いです. 共有ライブラリのバージョン ELF の共有ライブラリは, libfoo.so.M という名前になっていなければなりません. ここで M は単一の バージョン番号を表します. 一方 a.out のライブラリは libfoo.so.M. N という名前で, M はメジャーバージョン番号, N はマイナーバージョン番号になっている必要があります. これらを混同しないでください. libfoo.so.N. M という名のELF 共有ライブラリや libfoo.so.N という名の a.out 共有ライブラリ (あるいはシンボリックリンク) は 絶対にinstallしないでください. リンカコマンドライン 直接 ld を使用せずに, cc -shared を使用してください. たった一つの違いは, ELF には, コマンドラインにを加える必要があることです. ELF のリンカを満足させるためには, libfoo.so から libfoo.so.N へのシンボリックリンクを作る必要があります. これは, PLIST にも加えなくては いけませんし, a.out の場合でも害にはならないので (一部の port ではダイナミックリンクローディングのために 必要でもあります), PORTOBJFORMAT の設定を気にせずに, ただ単純にリンクを作成してください. <makevar>LIB_DEPENDS</makevar> すべての port の Makefile を編集して, LIB_DEPENDS からマイナー番号を除去する必要があり, 正規表現のサポートも除去する必要があります. (例えば, foo\\.1\\.\\(33|40\\) から foo.2) マッチングは grep -wF を使って行われます. <filename>PLIST</filename> PLIST は, a.out のマイナー番号が0であれば, 短い (ELFの) 共有ライブラリの名前を含み, さもなくば長い (a.outの) 名前を含んでいる必要があります. bsd.port.mk は 自動的に, PORTOBJFORMAT が aout であれば, .0 を 短い共有ライブラリの名前の行に付け加え, PORTOBJFORMAT が elf であれば, マイナー番号を 長い共有ライブラリの名前から削除します. ELF システムで 2 つのバージョン番号を持つ共有ライブラリを インストールしたり, aout システムで 1 つのバージョン番号しか持たない共有ライブラリを インストールするのが避けられない場合 (例えば他のオペレーティングシステム用の 互換ライブラリをインストールする port など), NO_FILTER_SHLIBS 変数を定義すれば, 前節で説明されている PLIST 編集の機能が停止されます. <literal>ldconfig</literal> Makefile 中の ldconfig の行は以下のようになります. ${SETENV} OBJFORMAT=${PORTOBJFORMAT} ${LDCONFIG} -m .... また PLIST 中では: @exec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -m ... @unexec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -R となります. これは, システムのデフォルトフォーマットではなく パッケージのフォーマットに応じて, 正しい ldconfig が呼ばれることを保証するためのものです. <makevar>MASTERDIR</makevar> もし, あなたの port が 変数(例えば 解像度とか紙のサイズなど)を変えたりした, ちょっと違うバージョンを作成する必要があるときには, ユーザが分りやすいように, package ごとに別々のサブディレクトリを作成し, ただし, できるだけ port 間でファイルを共有するようにしてください. 典型的な例では, うまく変数を使えば, とても短いMakefileだけ, 1つ以外のすべてのディレクトリに置くだけで済みます. その短い Makefile には MASTERDIR を使って, 残りのファイルがあるディレクトリを指定できます. また PKGNAME の一部に変数に使って, package が別々の名前を持つようにしてください. 以下が, とても良い例になるでしょう. これは japanese/xdvi300/Makefile の一部です: PKGNAME= ja-xdvi${RESOLUTION}-17 : # default RESOLUTION?= 300 .if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \ ${RESOLUTION} != 300 && ${RESOLUTION} != 400 @${ECHO} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\"" @${ECHO} "Possible values are: 118, 240, 300 (default) and 400." @${FALSE} .endif japanese/xdvi300 は通常のパッチ, package ファイルももっています. そこで, make と入力すると, デフォルトの解像度(300)を使って, 普通に port の作成を行います. 他の解像度に関してですが, これが, xdvi118/Makefile の(コメントを除いた) すべてです. RESOLUTION= 118 MASTERDIR= ${.CURDIR}/../xdvi300 .include ${MASTERDIR}/Makefile (xdvi240/Makefile と xdvi400/Makefile も同様です). MASTERDIR が bsd.port.mk に PATCHDIR や PKGDIR などの通常のサブディレクトリが xdvi300 にあることを教えます. RESOLUTION=118 の行が, xdvi300/Makefile の RESOLUTION=300 の行を無効にし, port は解像度を118として作成されます. 共有ライブラリのバージョン まず, 共有ライブラリのバージョンについての指針 を読んで, 共有ライブラリのバージョンを 一般的にどうすれば良いかを理解してください. 盲目的に, ソフトウエアの作者がちゃんと理解していると 信じててはいけません, 多くの場合違います. 細い点まで考慮することは大変重要なことです, なぜなら我々は互換性がないかもしれない大量の ソフトウェアを共存させようとする, 特殊な状況にあるからです. 不注意な port の導入が共有ライブラリに関して, 多大な問題を引き起したことが過去にあります (今まで, jpeg-6b がなぜ 9.0 といバージョン番号を持っているか不思議に 思ったことはありませんか?). もし, 疑問があれば, &a.ports; にメールを送ってください. ほとんどの時間は, 正しいシェアードライブラリのバージョンを決めることと, それを実現するためのパッチを作成することに終始します. しかしながら, が同じソフトウェアの違ったバージョンの ソフトウェアが既にツリーにあるばあいには, 状況は非常に複雑です. つまり, FreeBSD では, ユーザがリンカにどのバージョンの共有ライブラリを 使用するかを指定できないからです (リンカは常にもっとも高いバージョンを選びます). これは, もし, libfoo.so.3.2 と libfoo.so.4.0 がシステムに存在するときには, リンカに特別なアプリケーションだけ libfoo.so.3.2 をリンクするように指示する方法がないことを意味します. これは, コンパイル時のリンクという意味では完全に見劣りします. この場合の唯一の解決方法は, 共有ファイルの名前の ベース 部分を変えることです. 例えば, libfoo.so.4.0 を libfoo4.so.1.0 へ変えることによって, バージョン 3.2 とバージョン 4.0 共に他の port からリンクされることができるようになります. マニュアル MAN[1-9LN] 変数を使用すると, 自動的にすべてのマニュアルを pkg/PLIST に加えます (つまり, マニュアルを PLIST に加えては いけません — PLIST の生成 を参照してください). またマニュアルを /etc/make.conf 中の NOMANCOMPRESS の設定に応じて, install時に自動的に圧縮したり伸長したりします. マニュアルをインストール時に圧縮するかどうかを 指定するには, MANCOMPRESSED 変数を使用します. この変数は, 3つの値をとることができます, yes, no そして maybe です. yes はマニュアルが既に圧縮されて インストールされている, no はされていない, maybe はそのソフトウェアがすでに, NOMANCOMPRESS に合わせており bsd.port.mk が特別なにもする必要がないことを意味します. USE_IMAKE がセットされていて, NO_INSTALL_MANPAGES がセットされていなければ, MANCOMPRESSED は自動的に yes に設定され, それ以外の場合には, no になります. デフォルトがあなたの port に合わない場合以外は明示的に設定する必要がありません. PREFIX 以外のディレクトリの下に マニュアルを置くような port では MANPREFIX を指定することができます. さらに, 特定のセクションのマニュアルだけ, 標準ではない場所にインストールする場合, 例えばいくつかの Perl のモジュールの ports など, には個々のマニュアルのパスを MANsectPREFIX (sect は, 1-9, または, L か N を表わします) によって指定できます. ができます. マニュアルが, 言語特有のサブディレクトリに 置かれる場合には, 言語名を MANLANG に設定してください. この変数のデフォルト値は, "" になっています (つまり, 英語のみ). これは, 全部をまとめた例です. MAN1= foo.1 MAN3= bar.3 MAN4= baz.4 MANLANG= "" ja MAN3PREFIX= ${PREFIX}/share/foobar MANCOMPRESSED= yes 以下の6個のファイルがこの port でインストールされます. ${PREFIX}/man/man1/foo.1.gz ${PREFIX}/man/ja/man1/foo.1.gz ${PREFIX}/share/foobar/man/man3/bar.3.gz ${PREFIX}/share/foobar/man/ja/man3/bar.3.gz ${PREFIX}/man/man4/baz.4.gz ${PREFIX}/man/ja/man4/baz.4.gz Motifを必要とするport 最近はコンパイルに Motif を必要とするアプリケーションが増えて きました. (Motif自体は有料のものがいくつかの会社から手に入りま すし, 多くのアプリケーションがコンパイル可能な無料の互換ライブラリ が x11-toolkits/lesstifにあります) Motifはかなり広く使われていますし, 製品のライ センスではライブラリを静的にリンクした 実行形式は再配布が認めら れている場合が多いので, Motifを必要とするソフトウェアを簡単に 動的(port からコンパイルする人々のために)/静的(package を配布 する人々のために)にリンクできるような しくみが用意されています. <makevar>REQUIRES_MOTIF</makevar> Motif がないとコンパイルできないportのMakefileではこの変 数を指定してください. これによって, Motifを持っていない人が このportをコンパイルしようとするのを未然に防ぎます. <makevar>MOTIFLIB</makevar> この変数は bsd.port.mk によって Motif ライブラリの指 定に置き換えられます. ソース内のMakefileやImakefileで Motif ライブラリを指定しているところをこの変数に置き換えるよ うにパッチをあててください. 代表的な例としては以下の二つがあげられます: MakefileかImakefileの中でMotifライブラリが として使われている場合には, かわりに MOTIFLIB と書いてください. Imakefileの中で XmClientLibs が使われている 場合には, それを ${MOTIFLIB} ${XTOOLLIB} ${XLIB} と書きかえてください. MOTIFLIB は通常 -L/usr/X11R6/lib -lXm か /usr/X11R6/lib/libXm.a に置き換えら れます. したがって前に や をつけ る必要はありません. X11 のフォント もし, あなたの port が X window system のフォントをインストールするのであれば, それらを X11BASE/lib/X11/fonts/local に置くようにしてください. このディレクトリは XFree86 release 3.3.3 で新設されたものです. もし, それが存在しなければ作成し, ユーザに XFree86 を 3.3.3 かそれより新しいものに更新か, すくなくとも, このディレクトリを /etc/XF86Config の font path に加えるように促すメッセージを出力するようにしてください. Info ファイル 新しい版の texinfo(2.2.2-RELEASE およびそれ以降に入っています) には, install-info というコマンドが含まれており, dir ファイルに項目を追加したり, 削除したりすることがで きます. もし, あなたの port が info ドキュメントをインストー ルするのであれば, 以下の指示に従って, その port および package が正しく, ユーザの ${PREFIX}/info/dir ファイル を更新するようにしてください. (この節は, とても長くてすいません, しかし info ファイルを作りあげるためには, これらは不可欠 です. 正しく行なえば, 美しい リストができますので, 辛抱してください! :) まず, これを知っておかなければなりません: &prompt.user; install-info --help install-info [OPTION]... [INFO-FILE [DIR-FILE]] Install INFO-FILE in the Info directory file DIR-FILE. (訳注: Info ディレクトリの INO-FILE を DIR-FILE にインストールする) Options: --delete Delete existing entries in INFO-FILE; don't insert any new entries. (訳注: INFO-FILE の中の項目を削除, 新しい項目は一切追加しない.) : --entry=TEXT Insert TEXT as an Info directory entry. (訳注: TEXT を Info ディレクトリの項目として追加する.) : --section=SEC Put this file's entries in section SEC of the directory. (訳注: このファイルの項目を Info ディレクトリの SEC という節に置く.) : このプログラムは, 実際には info ファイルをインストール しません, 単に dir ファイルにエントリーを挿入したり削除し たりするだけです. これから, install-info を使用するように, ports を変換す る7段階の工程を示します. 例として editors/emacsを 使用します. まず, texinfo のソースを見て, @dircategory と @direntry 文がないファイルについて, それらを追加するパッチを作成します. 以下は, ここでの例での patchの一部です: --- ./man/vip.texi.org Fri Jun 16 15:31:11 1995 +++ ./man/vip.texi Tue May 20 01:28:33 1997 @@ -2,6 +2,10 @@ @setfilename ../info/vip @settitle VIP +@dircategory The Emacs editor and associated tools +@direntry +* VIP: (vip). A VI-emulation for Emacs. +@end direntry @iftex @finalout : フォーマットについては見ればわかると思います. dir というファイルに必要な項目を書いておいてくれる作者 も多いので, まず自分で書く前にさがしてみてください. また, 関係 する ports も調べて, 節(section)の名前や, インデントなどが きちんと合っているかどうかを確認してください (項目のテキスト は, すべて4つめのタブ・ストップ(tab stop)から始めることを推 奨します). 1つのファイルに対して1つの info の項目しか書けないことに注 意してください, これは, install-info --delete が, そのバグにより, @direntry セクションに複数の項目を書 いても, 初めの1つの項目しか削除してくれないからです. texinfo のソースにパッチをあてるかわりに, dir の項目 を install-info の 引数((, ) として与えることもできます. これはあまり良い方法とは 思えません, なぜなら, 同じ情報を3ヶ所(Makefile, PLIST の @exec/@unexec: 以下参照) に重複して, 書く必要があるからです. しかしながら, もし日本語(あるいは, 他のマルチバイト文字)の info ファイルがあるのならば, install-info の特別な引数を使用する必要があるでしょう, なぜならば, makeinfo がこのような texinfo ソースファイル を扱えないからです. (このようなものをどう扱うかの例としては, japanese/skk の Makefile と PLIST を見て ください.) portのディレクトリに戻って, make clean; make をして, info ファイルが texinfo ソースファイルから再び生成さ れることを確認してください. texinfo ソースファイルのほうが info ファイルよりも新しいので, make とタイプすれば, info ファイルは再構築されるはずですが, 多くの Makefile には info ファイルの正しい依存関係が書かれていません. emacs の場合, info ファイルの再構築ため, man サブディレクトリ に降りていくようにするために, メインの Makefile.in にパッ チをあてる必要がありました. --- ./Makefile.in.org Mon Aug 19 21:12:19 1996 +++ ./Makefile.in Tue Apr 15 00:15:28 1997 @@ -184,7 +184,7 @@ # Subdirectories to make recursively. `lisp' is not included # because the compiled lisp files are part of the distribution # and you cannot remake them without installing Emacs first. -SUBDIR = lib-src src +SUBDIR = lib-src src man # The makefiles of the directories in $SUBDIR. SUBDIR_MAKEFILES = lib-src/Makefile man/Makefile src/Makefile oldXMenu/Makefile lwlib/Makefile --- ./man/Makefile.in.org Thu Jun 27 15:27:19 1996 +++ ./man/Makefile.in Tue Apr 15 00:29:52 1997 @@ -66,6 +66,7 @@ ${srcdir}/gnu1.texi \ ${srcdir}/glossary.texi +all: info info: $(INFO_TARGETS) dvi: $(DVI_TARGETS) man サブディレクトリでのデフォルトターゲットは, info で呼ばれるのに対して, メインの Makefile では, all で呼びたいので, 2つめのpatchが必要でした. また, info info ファイルのインストールも削除しました, なぜなら, 同じものが同じ名前で既に /usr/share/info にあるからです. (このパッチはここにはありません.) もし, Makefile に dir ファイルをインストールす る個所があれば, 削除します. あなたの port がインストー ルしてはいけません. また, dir ファイルを壊してしまうよう なコマンドの類も削除します. --- ./Makefile.in.org Mon Aug 19 21:12:19 1996 +++ ./Makefile.in Mon Apr 14 23:38:07 1997 @@ -368,14 +368,8 @@ if [ `(cd ${srcdir}/info && /bin/pwd)` != `(cd ${infodir} && /bin/pwd)` ]; \ then \ (cd ${infodir}; \ - if [ -f dir ]; then \ - if [ ! -f dir.old ]; then mv -f dir dir.old; \ - else mv -f dir dir.bak; fi; \ - fi; \ cd ${srcdir}/info ; \ - (cd $${thisdir}; ${INSTALL_DATA} ${srcdir}/info/dir ${infodir}/dir); \ - (cd $${thisdir}; chmod a+r ${infodir}/dir); \ for f in ccmode* cl* dired-x* ediff* emacs* forms* gnus* info* message* mh-e* sc* vip*; do \ (cd $${thisdir}; \ ${INSTALL_DATA} ${srcdir}/info/$$f ${infodir}/$$f; \ chmod a+r ${infodir}/$$f); \ (これは, 既存のportを修正するときのみ必要です.) pkg/PLIST を見て, info/dir にパッチをあて ようとするものすべてを削除します. これらは, pkg/INSTALL やその他のファイルにもあるかもしれない ので, いろいろさがしてみてください. Index: pkg/PLIST =================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v retrieving revision 1.15 diff -u -r1.15 PLIST --- PLIST 1997/03/04 08:04:00 1.15 +++ PLIST 1997/04/15 06:32:12 @@ -15,9 +15,6 @@ man/man1/emacs.1.gz man/man1/etags.1.gz man/man1/ctags.1.gz -@unexec cp %D/info/dir %D/info/dir.bak -info/dir -@unexec cp %D/info/dir.bak %D/info/dir info/cl info/cl-1 info/cl-2 post-install ターゲットを Makefile に加えて, dir ファイルが存在しなければ作成するようにします. また, インストールされた info ファイルについては, install-info を実行するようします. Index: Makefile =================================================================== RCS file: /usr/cvs/ports/editors/emacs/Makefile,v retrieving revision 1.26 diff -u -r1.26 Makefile --- Makefile 1996/11/19 13:14:40 1.26 +++ Makefile 1997/05/20 10:25:09 1.28 @@ -20,5 +20,11 @@ post-install: .for file in emacs-19.34 emacsclient etags ctags b2m strip ${PREFIX}/bin/${file} .endfor + if [ ! -f ${PREFIX}/info/dir ]; then \ + ${SED} -ne '1,/Menu:/p' /usr/share/info/dir > ${PREFIX}/info/dir; \ + fi +.for info in emacs vip viper forms gnus mh-e cl sc dired-x ediff ccmode + install-info ${PREFIX}/info/${info} ${PREFIX}/info/dir +.endfor .include <bsd.port.mk> 新しい info ファイルを作成するのに, /usr/share/info/dir と上のコマンド, 以外は使用しな いでください. 実際のところ, もし port する人がこれに関して PLIST に自らまったく手を加える必要がないのであれば, 上 のパッチのはじめの3行を bsd.port.mk に加えたでしょう. PLIST を編集して, 同じ働きをする @exec 文, そ れにpkg_delete のために @unexec 文を加えてくださ い. @unexec を使用して info/dir を削除する必 要はありません. Index: pkg/PLIST =================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v retrieving revision 1.15 diff -u -r1.15 PLIST --- PLIST 1997/03/04 08:04:00 1.15 +++ PLIST 1997/05/20 10:25:12 1.17 @@ -16,7 +14,15 @@ man/man1/etags.1.gz man/man1/ctags.1.gz +@unexec install-info --delete %D/info/emacs %D/info/dir : +@unexec install-info --delete %D/info/ccmode %D/info/dir info/cl info/cl-1 @@ -87,6 +94,18 @@ info/viper-3 info/viper-4 +@exec [ -f %D/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > %D/info/dir +@exec install-info %D/info/emacs %D/info/dir : +@exec install-info %D/info/ccmode %D/info/dir libexec/emacs/19.34/i386--freebsd/cvtmail libexec/emacs/19.34/i386--freebsd/digest-doc @unexec install-info --delete コマンドは, info ファイル自身より先に置き, コマンドがファイルを読めるようにし ておかなければならないことに注意してください. また, @exec install-info コマンドは info ファイルおよび dir ファイルを作る @exec コマンドより後に おかなければなりません. テスト をして出来栄えに感服しましょう :) 各段階の前後に, dir ファイルをチェックしましょう. <filename>pkg/</filename> サブディレクトリ まだ触れていない, いくつかのこつが pkg/ サブディレクトリにはあり, 時として便利でしょう. <filename>MESSAGE</filename> もし, インストールする人にメッセージを表示する 必要がある場合には, そのメッセージを pkg/MESSAGE に置けます. この機能は, pkg_add の後の追加のインストール手続きを表示するときなどに, 重宝します. pkg/MESSAGE ファイルは pkg/PLIST に加える必要はありません. また, もしユーザが package ではなく port を使用して いる場合には自動的には表示されませんので, 明示的に post-install で表示するようにするべきでしょう. <filename>INSTALL</filename> バイナリパッケージが pkg_add でインストールされるときに, 実行される必要がある コマンドがあれば, pkg/INSTALL スクリプトを使って実行することができます. このスクリプトは自動的に package に加えられ, pkg_add によって2度実行されます. はじめは INSTALL ${PKGNAME} PRE-INSTALL と実行され, 2度目には, INSTALL ${PKGNAME} POST-INSTALL と実行されます. どちらのモードで実行されているかは, $2 を調べることによってわかります. 環境変数 PKG_PREFIX には package がインストールされるディレクトリが設定されます. 詳細は &man.pkg.add.1; を見てください. port を make install で インストールするときには, このスクリプトは自動的に実行されません. もし, 実行される必要があるならば, port の Makefile から明示的に呼ぶ必要があります. <filename>REQ</filename> port が(インストールされるシステムの状態によって) インストールされるべきか, されないべきか区別する必要が あるときには, “要件(requirements)” スクリプト pkg/REQ を作ることができます. これは, インストール及びデインストール (package の削除)の時に自動的に実行され, それらが処理されるべきかを決定します. make の変数にあわせた <filename>PLIST</filename> の変更 いくつかの port, 特に p5- portsなど, は configure のオプション (あるいは, p5- ports の場合は perl のバージョン)によって, PLIST を変える必要があります. これを容易に実現するために, PLIST 中の %%OSREL%%, %%PERL_VER%%, %%PERL_VERSION%% は, 適切に置き換えられるようになっています. %%OSREL%% の値は, オペレーティングシステムの数字で表されたリビジョンです (例えば, 2.2.7). %%PERL_VERSION%% は perl のバージョン番号全体(例えば, 5.00502 )で, %%PERL_VER%% はバージョン番号から, パッチレベルを引いてものです(例えば, 5.005). 他の置き換えが必要であれば, PLIST_SUB 変数に VAR=VALUE という形式のペアのリストを設定することによって, PLIST 中の %%VAR%% は VALUE に置き換えられます. 例えば, バージョンに固有の沢山のファイルを インストールする場合には, Makefile に OCTAVE_VERSION= 2.0.13 PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} と書いて, PLIST 中のバージョン番号が表われるすべてのところに, %%OCTAVE_VERSION%% と書きます. このようにしておけば, port をアップグレードするときに, 何十行(ときとして, 何百行)も PLIST を書き替えないですみます. この書き換えは ( マニュアル の追加も) do-install と post-install ターゲット のあいだに, PLIST を読み TMPPLIST (デフォルトは, WRKDIR/.PLIST.mktmp ) に書き込むことによって行なわれます. もし, あなたの port が PLIST を実行時に生成するのであれば, do-install のあいだか, その前に行うようにしてください. また, 書きかえられたあとのファイルを編集する必要がある場合には, post-install で, TMPPLIST を書きかえてください. <filename>pkg</filename> サブディレクトリにあるファイル名の変更 pkg サブディレクトリにあるファイルは全て, 変数を 使用して定義されていますので, 必要であれば Makefile 中で 変更可能です. いくつかの ports で 一つの pkg サブディレクトリを共有する場合や, 上記のファイルに書き込む 必要があるときなど, 特に便利です. (pkg サブディレクトリに直接書き込むのが良くない理由に ついては WRKDIR 以外への書きこみ を参照してください.) 以下が変数名とそのデフォルト値の表です. Variable Default value COMMENT ${PKGDIR}/DESCR DESCR ${PKGDIR}/DESCR PLIST ${PKGDIR}/PLIST PKGINSTALL ${PKGDIR}/PKGINSTALL PKGDEINSTALL ${PKGDIR}/PKGDEINSTALL PKGREQ ${PKGDIR}/REQ PKGMESSAGE ${PKGDIR}/MESSAGE PKG_ARGSを上書きせずに, これらの変数を変更 するようにしてください. PKG_ARGSを変更すると これらのファイルは port から正しく /var/db/pkg にインストールされなくなります. ライセンス上の問題 ソフトウェアによっては制限の厳しい ライセンスがついてきたり, 法律的に問題があるかもしれません. (PKPの公開鍵暗号化, ITAR (暗 号化ソフトウェアの輸出) などが例としてあげられます). それらを どう扱えばいいかはライセンスの文面によって さまざまな場合があり ます. ソフトウェア移植者として, あなたにはライセンスをよく読み, FreeBSD プロジェクトが FTP または CD-ROM で配布してはいけないソフ トウェアを配布してしまうことのないよう, 注意する義務があります. なにか疑問がある場合には, &a.ports;に聞いてみてください. よく見られるケースに対処するために, 二つの変数が用意されてい ます: ソフトウェアに “有償再配布を禁ずる” という趣旨のライセン スがついてきた場合には NO_CDROM という変数にその理由を記述して ください. 私たちはこれがついているportはCD-ROMリリースに入 れないようにしますが, オリジナルのソースファイルとpackage はFTPでは取れるようにしておきます. もしも, 生成される package が個々のサイトで独自に構築さ れる必要があったり, ライセンスによって生成されるバイナリが 配布できない場合には, NO_PACKAGE 変数にその理由を記述してくだ さい. そのような package が FTP サイトに置かれたり, リリース 時の CD-ROM へ入らないようにします. ただし, いずれの場合も distfile は(FTP や CD-ROM に)含まれるようになります. Portが, 使用者によっては法律上の問題が生じる時 (暗号化ソフ トウェアなど), または“商用利用を禁ずる”とライセンスに書い てある場合には RESTRICTEDという変数にその理由を入れ てください. この場合には, ソースファイルやpackageは私たちの FTPサイトにも置かれません. GNU一般公有使用許諾書 (GPL) はバージョン1, 2とも port作成上は何ら問題にはなりません. もしあなたが，ソースツリー管理者 (committer) であれば， ソースツリーにこのようなportを入れる際に, ports/LEGAL ファイルを書き換えるのを忘れないようにし てください. アップグレード Port のバージョンが原作者からのものに比べて古いことに気がつ いたら, まずはあなたの持っているportが私たちの最新のもの (ミラー サイトの ports/ports-current というディレクトリにあります) であることを確認してください. 次に, portの Makefile にMAINTAINER (保守担当者) の アドレスが書いてある場合には, その人にメールを出してみましょう. 保守担当者の人がすでにアップグレードの準備を しているかもしれま せんし, (新しいバージョンの安定度に問題があるなど) あえてアッ プグレードをしない理由があるのかもしれません. 保守担当者にアップグレードをしてくれと頼まれた場合, あるいは そもそもportのMakefileに保守担当者が書いてない場合などは, あ なたがアップグレードをしてくださると助かります. その場合にはアッ プグレードをしたのち, 変更前と変更後のディレクトリの再帰的diff (unified diff と context diff のどちらでもいいのですが, port のコミッター達は unified diff のほうを好むようです) をとって送ってください. (例えば, 変更前のディレクトリが superedit.bak という名前でとってあり, 変更後のもの が superedit に入っているなら, diff -ruN superedit.bak superedit の結果を送ってください. ) diff の出力を見て, すべての変更が正しくなされているか確認して ください. 変更箇所については, &man.send-pr.1; (カテゴリーは, ports)に diff の出力結果を添えて, 私たちに送ってもらうのが一 番よいです. commit する際に CVS に明確に記述しなければならない ので, 付け加えたり削除したりしたファイルがあったら, それについ て書いておいてください. もし diff の大きさが 20 KB 程度を 超えるようであれば, 圧縮したものを uuencode して下さい. そうでなければそのまま PR に入れるだけでいいです. 繰り返しになりますが, ports の変更を送るときには, &man.shar.1; ではなく &man.diff.1; を使用してください. やっていいことといけないこと この節では, ソフトウェアをportする上でよくある落し穴などにつ いて説明します. このリストを使って, あなた自身が作成した port のチェックはもとより, PR データベースにある, 他の人が作成した port のチェックもできます. あなたがチェックした port について のコメントを バグ報告と一般的な論評 にしたがって, 送ってください. PR データベースにある port を チェックすることによって, 私達がそれらを commit するのを早くし, あなたが何をしているか理解していることも示します. バイナリのstrip バイナリは strip してください. オリジナルのソースがバイナリを strip してくれる場合は良いですが, そうでない場合には post-install ターゲットを指定して strip するようにするとよいでしょう. 例えば, こんな風になります: post-install: strip ${PREFIX}/bin/xdl インストールされた実行形式がすでに strip されているかどうかは file コマンドで確認できます. これが`not stripped'と言わなければ, stripされているということです. <makevar>INSTALL_*</makevar> マクロ あなた自身の *-install ターゲットでファイルの正しいモードと オーナを保証するために, 必ずbsd.port.mkで提供されて いるマクロを使用してください. マクロは以下のようなものがあります. ${INSTALL_PROGRAM} は実行可能なバイナリを インストールするコマンドです. ${INSTALL_SCRIPT} は実行可能なスクリプトを インストールするコマンドです. ${INSTALL_DATA} は共有可能なデータを インストールするコマンドです. ${INSTALL_MAN} はマニュアルとその他のドキュメ ントをインストールするコマンドです. (圧縮はしません) これらは基本的に install コマンドに適当なフラグを与え たものです. どのようにこれらを使用するかは以下の例を見てください. <makevar>WRKDIR</makevar> WKRDIR の外のファイルにはなにも書き込まないように してください. WRKDIR は ports のビルド中に書き込こめる ことが保証されている唯一の場所です( CDROM から ports をコンパイルを参照). PKGDIR にあるファイルを修正する必要がある ときには, 変数の再定義 によって行ない, 上書きはしないでください. <makevar>WRKDIRPREFIX</makevar> WRKDIRPREFIX を尊重していることを確認してください. 特に, 別の port の WRKDIR を参照している ときには気を付けてください. 正しい場所は, WRKDIRPREFIX PORTSDIR /subdir/ name/work, です, PORTSDIR/subdir/ name/work とか .CURDIR/../../subdir /name/work とかではありません. また, 自分で WRKDIR 定義するときには, 頭に ${WRKDIRPREFIX}${.CURDIR} が付いている 事を確認してください. OS や OS のバージョンの区別 Port の過程で, 修正や, どのバージョンの UNIX で動くかによる条件つきコンパイルなどが 必要なコードに出会うかもしれません. そのような条件つきコンパイルなどのための 変更をおこなうときには, FreeBSD 1.x システムへの移植や, CSRGの4.4BSD, BSD/386, 386BSD, NetBSD, OpenBSD などの他のBSDシステムへの移植が可能なように, できるだけ普遍的な変更をおこなうことを 心がけてください. 4.3BSD/Reno (1990) およびそれより新しい BSD 版を古いバージョンと区別するには BSD マクロを利用するのがよいでしょう. これは <sys/param.h> で定義されています. このファイルがすでにインクルードされていればよいのですが, もしそうでない場合には以下のコードを, その .c ファイルの適当な場所に加えてください. #if (defined(__unix__) || defined(unix)) && !defined(USG) #include <sys/param.h> #endif これらの 2 つのシンボルが定義されているすべてのシステムには sys/param.h があるはずです. もし, そうでないシステムを発見したら我々にも教えてください. &a.ports; までメールを送ってください. あるいは, GNU の Autoconf のスタイルを使用することもできます, #ifdef HAVE_SYS_PARAM_H #include <sys/param.h> #endif この方法を使用するときには, Makefile 中の CFLAGSに -DHAVE_SYS_PARAM_H を加えることを忘れないようにしてください. いったん sys/param.h がインクルードされると, #if (defined(BSD) && (BSD >= 199103)) このようにしてそのコードが 4.3 Net2 コードベース, またはそれより新しいもの (例: FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1とそれ以前) の上でコンパイルされているかを検出できます. #if (defined(BSD) && (BSD >= 199306)) これは, 4.4コードベース, またはそれより新しいもの (例: FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0とそれ以後) の上でコンパイルされているかどうかを 検出するために使用します. 4.4BSD-Lite2 コードベースでは, BSD マクロの値は 199506 になっています. これは参考程度の意味合いしかありません. 4.4-Lite ベースの FreeBSD と 4.4-Lite2 での変更がマージされたバージョンとを 区別するのに使用するべきものではありません. この目的のためには, __FreeBSD__ マクロをかわりに使用してください. 以下は控え目に使ってください. __FreeBSD__ はFreeBSDのすべての版で定義されています. 変更が FreeBSD だけに適用されるとき以外は使用しないでください. Portでよくある, strerror() ではなく sys_errlist[] を使うなどは, FreeBSDでの変更ではなく, BSD の流儀です. FreeBSD 2.xでは __FreeBSD__ が 2 と定義されています. それ以前の版では 1 になっています. その後の版では, そのメジャー番号に合うように上がっていきます. もし, FreeBSD 1.x システムと FreeBSD 2.x あるいは FreeBSD 3.x システムを区別する必要があれば, 上で述べた BSDマクロを使用するのが, 大抵の場合において正しい答です. もし, FreeBSD特有の変更であれば (ld を使うときのシェアードライブラリ用のなオプションなど), __FreeBSD__を使い #if __FreeBSD__ > 1 のようにFreeBSD 2.x および, それ以降のシステムを検出するのはかまいません. もし, 2.0-RELEASE以降のFreeBSDシステムを細かく検出したけれ ば, 以下を使用することができます. #if __FreeBSD__ >= 2 #include <osreldate.h> # if __FreeBSD_version >= 199504 /* 2.0.5+ release specific code here */ # endif #endif Release - _FreeBSD_version + __FreeBSD_version 2.0-RELEASE 119411 2.1-CURRENT's 199501, 199503 2.0.5-RELEASE 199504 2.1 以前の 2.2-CURRENT 199508 2.1.0-RELEASE 199511 2.1.5 以前の 2.2-CURRENT 199512 2.1.5-RELEASE 199607 2.1.6 以前の 2.2-CURRENT 199608 2.1.6-RELEASE 199612 2.1.7-RELEASE 199612 2.2-RELEASE 220000 2.2.1-RELEASE 220000 (2.2-RELEASE と同じです) 2.2.1-RELEASE 以後の 2.2-STABLE 220000 (これも同じです) texinfo-3.9 以後の 2.2-STABLE 221001 top 導入以後の 2.2-STABLE 221002 2.2.2-RELEASE 222000 2.2.2-RELEASE 以後の 2.2-STABLE 222001 2.2.5-RELEASE 225000 2.2.5-RELEASE 以後の 2.2-STABLE 225001 ldconfig -R 以後の 2.2-STABLE 225002 2.2.6-RELEASE 226000 2.2.7-RELEASE 227000 2.2.7-RELEASE 以後の 2.2-STABLE 227001 semctl(2) 変更後の 2.2-STABLE 227002 2.2.8-RELEASE 228000 2.2.8-RELEASE 以後の 2.2-STABLE 228001 mount(2) 変更以前の 3.0-CURRENT 300000 mount(2) 変更以後の 3.0-CURRENT 300001 semctl(2) 変更以後の 3.0-CURRENT 300002 ioctl 引数変更後の 3.0-CURRENT 300003 ELF 移行後の 3.0-CURRENT 300004 3.0-RELEASE 300005 3.0-RELEASE 以後の 3.0-CURRENT 300006 3/4 の分岐後の 3.0-STABLE 300007 3.1-RELEASE 310000 3.1-RELEASE 以後の 3.1-STABLE 310001 3/4 の分岐後の 4.0-CURRENT 400000 (2.2-STABLE は, 2.2.5-RELESE 以後, “2.2.5-STABLE” と呼ばれることがあります.) 見ての通り, これは年・月というフォーマットになっていましたが, バージョン 2.2 から, より直接的にメジャー/マイナー番号を使う ように変更になりました. 並行していくつかのブランチ(枝分かれし たバージョン)を開発する場合には, リリースされた日付でそれらの リリースを分類することが不可能だからです. (あなたが今 port を作成するときに, 古い -CURRENT 達について心配 する必要はありません. これは参考のために挙げられているにすぎま せん.) これまで, 何百ものportが作られてきましたが, __FreeBSD__ が正しく使われたのは, 1つか2つの場合だけでしょう. 以前のportが誤った場所でそのマクロを使っているからと いって, それをまねする理由はありません. <filename>bsd.port.mk</filename> の後に書くこと .include <bsd.port.mk> の行の後には なにも書かないようにしてください. 大抵の場合は Makefile の 中程のどこかで, bsd.port.pre.mk を include して, 最後に bsd.port.pre.mk を include することによって避けることができます. pre.mk/post.mk のペアか bsd.port.mk だけのどちらかだけを include してください. 2つを混ぜないでください. 前者は, いくつかの変数の定義だけ をして, Makefile でのテストに使用し, 後者は残りを定義します. 以下は bsd.port.pre.mk で定義される重要な変数です. (これは, すべてではありません. 完全なリストは bsd.port.mk を参照してください.) 変数名 解説 ARCH uname -m で返される アーキテクチャ. (例, i386). OPSYS uname -s で返される オペレーティングシステム (例, FreeBSD). OSREL オペレーティングシステムの リリースバージョン (例., 2.1.5, 2.2.7). OSVERSION 数字形式のオペレーティングシステム のバージョン, 上記の __FreeBSD_version と同じです. PORTOBJFORMAT システムのオブジェクト フォーマット (aout あるいは elf). LOCALBASE “local” ツリーのベース. (例, /usr/local/). X11BASE “X11” ツリーのベース. (例, /usr/X11R6/). PREFIX portsのインストール先 ( PREFIXについてを参照). USE_IMAKE, USE_X_PREFIX あるいは MASTERDIR などの変数を定義する必要がある場合には, bsd.port.pre.mk を include する前に定義してください. 他のものは, bsd.port.pre.mk の前でも後でもかまいません. 以下は bsd.port.pre.mk の後に書けるものの例です: # no need to compile lang/perl5 if perl5 is already in system .if ${OSVERSION} > 300003 BROKEN= perl is in system .endif # only one shlib version number for ELF .if ${PORTOBJFORMAT} == "elf" TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR} .else TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR} .endif # software already makes link for ELF, but not for a.out post-install: .if ${PORTOBJFORMAT} == "aout" ${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so .endif 付加的ドキュメント 普通のマニュアルや info ファイルのほかにユーザにとって有用だ と思えるようなドキュメントがある場合には, PREFIX/share/doc の下にインストールしてく ださい. これは前記と同様, post-installターゲットの 中からするのがいいでしょう. まず, あなたのportのために新しいディレクトリを作りま す. どのportのドキュメントか簡単にわかるような名前にする必 要がありますので, 普通は PKGNAME からバージョ ン番号を除いた部分を使うといいでしょう. もちろん, ユーザが異 なるバージョンのものを同時に使うことが予想される port の場合 には, PKGNAME をそのまま使ってかまいません. ユーザが /etc/make.conf でこの部分を禁止するために NOPORTDOCS という変数をセットしている場合には， これらのドキュメントが インストールされないようにしてください. こんな具合です. post-install: .if !defined(NOPORTDOCS) ${MKDIR}${PREFIX}/share/doc/xv ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv .endif これらのファイルを pkg/PLIST に入れるのを忘れないよ うにしてください. (packageが/etc/make.conf内の 変数を読む方法は今のところ存在しませんので, NOPORTDOCS については気にしないでください.) インストール時に pkg/MESSAGE ファイルを利用して, メッセージを表示することができます. 詳細は pkg/MESSAGE を使う の節を参照してください. MESSAGE ファイルは pkg/PLIST に加える必要はありま せん. <makevar>DIST_SUBDIR</makevar> /usr/ports/distfiles ディレクトリ内をあまり散らかさ ないようにしてください. たくさんのファイルを取ってくるport や, 数は少なくてもほかのportのファイルと混同されるおそれが あるファイル (Makefile など) がある場合には, DIST_SUBDIR に port の名前 (PKGNAME からバージョン番号を取った部分を 使うといいでしょう) を入れてください. すると, DISTDIRがデフォルトの /usr/ports/distfiles から /usr/ports/distfiles/DIST_SUBDIR に変更され, 取ってきたファイルはすべてそのサブディレクトリの中に置か れるようになります. また, ファイルを取ってくるときにバックアップサイトとして使わ れる ftp.freebsd.org のディレクトリ名にもこの変数の 値が使われます. (DISTDIRを明示的に指定し た場合には, ローカルのファイルを置くところは変わりますが, こ のサイトのディレクトリ名は変わりませんので, 必ず DIST_SUBDIRを使うようにしてください.) この変数はMakefile中で明示的に指定された MASTER_SITES には影響しないことに注意して ください. RCS文字列 RCS が特別な意味を与えている文字列をパッチ内に入れないように してください. ファイルを私たちのソースツリーに入れる時にこれら の文字列はCVSによって書き換えられてしまい, あとでまたパッチ を使おうとした時にうまくいかないことがあります. RCS文字列は ドル記号 ($) で囲まれており, $Id や $RCS などで始まり ます. パッチ作成上の注意 diffの再帰 () フラグを使って再帰的なパッ チを作るのは大変結構なのですが, でき上がったパッチは必ず目で チェックして余計なゴミが入っていないことを確認してくださ い. よくあるのはバックアップファイル同士の変更点, あるいは Imake や GNU configure を使うソフトウェアの Makefile の変更点が入っている場合などです. また, configure.in を編集して, autoconf を使って configure を作り直す ときには, configure の diff は含めずに (それらは, 数千行になることもしばしばです), USE_AUTOCONF=yes を定義して, configure.in の diff をとってください. ファイルをまるごと消す場合にはパッチを使わずに post-extract ターゲットで消す方が簡単です. できあがった 差分に満足したら, それらをソースのファイルごとに別々の パッチファイルに分割してください. <makevar>PREFIX</makevar> なるべく port は PREFIX に対する相対パス にインストールすることができるように心がけてください. (この変数の値は USE_X_PREFIXか USE_IMAKEが指定してある時には X11BASE (デフォルト/usr/X11R6), そうでない場合にはLOCALBASE (デフォルト/usr/local) にセットされます.) サイトによってフリーソフトウェアが インストールされる場所が 違いますので, ソース内で /usr/local や /usr/X11R6 を明示的に書かないようにしてください. X のプログラムで imake を使うものについては, これは問題に はなりません. それ以外の場合には, ソース中のMakefileやスク リプトで /usr/local (imakeを使わないXのプログラ ムは /usr/X11R6) と書いてあるところを PREFIX に書き換えてください. この値は portのコンパイル, およびインストール時に自動的に環境変数として 下位makeに渡されます. USE_X_PREFIXは本当に必要な時 (つまり, X のライブラリなどとリンクしたり, X11BASE 以下にある ファイルを参照したりする必要がある時) 以外には設定しないでください. 変数 PREFIX の値は port の Makefile やユーザの環境で変更することもできます. しかし, 個々の port が Makefile でこの変数の値を明示的に設定することはなるべくしない でください. また, 他の port からインストールされるプログラムやファイル を指定するときには, 上で述べた変数を使用してください. 例えば, less のフルパスを PAGER というマクロに入れた い場合は, コンパイラに -DPAGER=\"/usr/local/bin/less\" と渡すかわりに -DPAGER=\"${PREFIX}/bin/less\" (Xを使うportの時は -DPAGER=\"${LOCALBASE}/bin/less\" ) を渡し てください. こうしておけば, `/usr/local' がまるごとどこか他 の場所に移してあるサイトでも, あなたのportがそのまま使える 可能性が高くなります. ディレクトリ構成 インストール時には PREFIX の正しいサブディ レクトリにファイルを置くように心がけてください. ソフトウェア によっては新しいディレクトリを 一つ作ってファイルを全部それに 入れてしまうものがありますが, それはよくありません. また, バ イナリ, ヘッダファイルとマニュアル以外のすべてを lib というディレクトリに入れてしまうportもあります が, これもBSD的なファイルシステム構成からいうと正しくありま せん. これは以下のように分散すべきです. etc にセッ トアップ/コンフィグレーションファイル, libexec に 内部で使用されるプログラム (コマンドラインから呼ばれることの ないコマンド), sbin に管理者用のコマンド, info に GNU Info 用のドキュメント, そして share にアーキテクチャに依存しないファイルが入り ます. 詳細については man &man.hier.7; を見てくださ い. /usrの構成方針はほとんどそのまま /usr/localにもあてはまります. USENET “ニュース”を 扱う ports は例外です. これらは, ファイルのインストール先として PREFIX/news を使用します. 空のディレクトリの除去 ports は デインストール(削除) の際には, 自分自身を消去したあとに, (ディレクトリの) 除去をするようにしてください. これは, 大抵の場合 @dirrm の行を ports が作成するすべてのディレクトリについて 加えることによって実現できます. 親ディレクトリは, 子ディレクトリを先に消さないと 消せないことに気をつけて下さい. : lib/X11/oneko/pixmaps/cat.xpm lib/X11/oneko/sounds/cat.au : @dirrm lib/X11/oneko/pixmals @dirrm lib/X11/oneko/sounds @dirrm lib/X11/oneko といった感じです. しかし, ときとして, 他の port をディレクトリを共有しているために @dirrm がエラーを返すことがあります. rmdir を @unexec から呼びだすことによって, 警告(warning)なしで 空のディレクトリのみを削除することができます: @unexec rmdir %D/share/doc/gimp 2>/dev/null || true これを使えば, たとえ, 他の port がファイルを インストールしていて, PREFIX/share/doc/gimp が空でない場合でも エラーメッセージは表示されませんし, pkg_delete が異常終了することもありません. UID もしあなたの portがインストールされるシステム上に特定のユー ザを必要とする場合は, pkg/INSTALL スクリプトから pw コマンドを実行して自動的にそのユーザを追加するよ うにしてください. net/cvsup-mirror の portが参考になるでしょう. もしあなたの port が, バイナリのパッケージとしてとして インストールされるときにも, コンパイルされたときと同じユーザー/グループ ID を使わなければならないのなら, 50 から 99 の間で空いている UID を選んで登録してください. japanese/Wnn の port が参考になるでしょう. 既にシステムや他の portで利用されている UIDを使わないように 十分注意してください. 現在の 50から 99までの間の UIDは以下の とおりです. majordom:*:54:54:Majordomo Pseudo User:/usr/local/majordomo:/nonexistent cyrus:*:60:60:the cyrus mail server:/nonexistent:/nonexistent gnats:*:61:1:GNATS database owner:/usr/local/share/gnats/gnats-db:/bin/sh uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67:X-10 daemon:/usr/local/xten:/nonexistent pop:*:68:6:Post Office Owner (popper):/nonexistent:/nonexistent wnn:*:69:7:Wnn:/nonexistent:/nonexistent ifmail:*:70:66:Ifmail user:/nonexistent:/nonexistent pgsql:*:70:70:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh ircd:*:72:72:IRCd hybrid:/nonexistent:/nonexistent alias:*:81:81:QMail user:/var/qmail/alias:/nonexistent qmaill:*:83:81:QMail user:/var/qmail:/nonexistent qmaild:*:82:81:QMail user:/var/qmail:/nonexistent qmailq:*:85:82:QMail user:/var/qmail:/nonexistent qmails:*:87:82:QMail user:/var/qmail:/nonexistent qmailp:*:84:81:QMail user:/var/qmail:/nonexistent qmailr:*:86:82:QMail user:/var/qmail:/nonexistent msql:*:87:87:mSQL-2 pseudo-user:/var/db/msqldb:/bin/sh このリストを最新の状態に保つためにも, この範囲の UID や GID を予約するような port を作ったり, 既存の port にそのような改変を行って我々に送るときには, UID の予約に関する注意書きをつけてください. 合理的な port Makefile は単純かつ適切であるべきです. もし, Makefile を数行短かくできたり, もっと読みやすくできるのであれば, そうしてください. 例えば, shell の if 構文を使う代りに, make の .if 構文を使う, EXTRACT* の再定義で代用できるのであれば, do-extract を再定義しない, CONFIGURE_ARGS += --prefix=${PREFIX} とするかわりに, GNU_CONFIGURE とする, などです. <makevar>CFLAGS</makevar> の尊重 CFLAGS 変数は尊重すべきです. その port がこれを無視するのであれば, NO_PACKAGE=ignores cflags を Makefile に加えてください. コンフィグレーション(設定)ファイル もしあなたの port が設定ファイルを PREFIX/etc に置く必要がある場合には, それを単純にインストールしたり, pkg/PLIST に加えてはいけません. こうしてしまうと, pkg_delete が ユーザが苦労して作ったファイルを消してしまったり, 新しく インストールすると上書きされてしまったりします. 代りに, 見本となるファイルを suffix ( filename.sample が良いでしょう) を付けて インストールして, message を表示して, ソフトウエアを動かす前に, ユーザがそのファイル をコピーして編集をしなければならないことを知らせましょう. Portlint 送付や commit をする前に portlint を使ってチェックしましょう. フィードバック Portを作るためにソフトウェアに変更を加えたら, なるべく原作者にその旨を伝えてパッチ等を送ってください. これらが次のリリースに取り入れられれば, アップグレードが楽になります. その他諸々 pkg/DESCR, pkg/COMMENT, pkg/PLIST などのファイルは, それぞれ2重にチェックしてください. 再検討してもっと良い記述があれば, それに置きかえてください. GNU General Public License (GNU一般公有使用許諾)のコピーは (すでにあるので)コピーしないでください, おねがいします. 法律に関することには, 十分注意をはらってください. 私達に法律に反するような形でソフトフェアの配布をさせない でください! 困ったら.... 私たちに質問を送る前に, 既存のportの例とbsd.port.mkを ちゃんと読んでください! ;) それでもわからないことがあったら, 一人で悩まないでどんどん 質問してください! :) <filename>Makefile</filename> のお手本 これはportの Makefile を作る際のお手本です. かぎかっこ ([])内のコメントは忘れずに取ってください. 変数の順番, 段落の間の空行など, Makefile を作るときはなるべくこ の形式にしたがってください. この形式は重要な情報が簡単に見つけられるように 設計されています. portlint を使って Makefile をチェックすることが 推奨されています. [ヘッダ -- どのようなportのMakefileかすぐにわかるようになっています] # New ports collection makefile for: xdvi # Version required: pl18 ["1.5alpha" みたいなのでも結構です] [この Makefile の最初の版が作成された日付です. この port をアップグ レードするときには変えないでください.] # Date created: 26 May 1995 [このソフトウェアを最初に FreeBSD に port した人の名前, つまり, この Makefile の最初の版を書いた人です. この port をアップグレー ドするとき, この行も変えないでください.] # Whom: Satoshi Asami <asami@FreeBSD.ORG> # # $Id$ [ ^^^^ この部分は, CVS ツリーに入れる時に自動的に RCS の ID 文字列に 置き換えられます.] # [Port自体, およびオリジナルのソースを取ってくるところを記述する部分. 最初は必ずDISTNAME, そして必要ならPKGNAME, CATEGORIES, 続いて MASTER_SITESがおかれ, さらに MASTER_SITE_SUBDIR がおかれることもあり ます. そのあと, EXTRACT_SUFX か DISTFILES を指定することも可能です] DISTNAME= xdvi PKGNAME= xdvi-pl18 CATEGORIES= print [MASTER_SITE_* マクロを使用しない場合は, 最後のスラッシュを忘れないように ("/")!] MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications [ソースファイルが標準の ".tar.gz" 形式でない時にこれを使いましょう] EXTRACT_SUFX= .tar.Z [配布パッチのセクション -- ない場合もあります] PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/ PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz [保守責任者 -- これは *必ず* 必要です. 担当者 (あなた) 自身, あるいは 担当者に素早く連絡をとれる人のアドレスを書いてください. どうしてもこ こに自分のアドレスを書くのがいやな人は "ports@FreeBSD.ORG" と書いて もいいです] MAINTAINER= asami@FreeBSD.ORG [依存するport -- ない場合もあります] RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript LIB_DEPENDS= Xpm.5:${PORTSDIR}/graphics/xpm [ここには標準のbsd.port.mkの変数で, 上のどれにもあてはまらないものを 書きます] [コンフィグレーション, コンパイル, インストールなどの時に質問をする なら...] IS_INTERACTIVE=yes [${DISTNAME}以外のディレクトリにソースが展開されるなら...] WRKSRC= ${WRKDIR}/xdvi-new [配布されているパッチが ${WRKSRC} に対する相対パスで作られてい い場合にこの変数の指定が必要かも...] PATCH_DIST_STRIP= -p1 [GNU autoconfによって生成された "configure" スクリプトを走らせたいなら...] GNU_CONFIGURE= yes [/usr/bin/makeでなく, GNU makeを使わないといけないなら...] USE_GMAKE= yes [これがXのアプリケーションで "xmkmf -a" を走らせたいなら...] USE_IMAKE= yes [などなど] [下の方のルールで使う非標準の変数] MY_FAVORITE_RESPONSE= "yeah, right" [そして, 特別なターゲット, 使用順に] pre-fetch: i go fetch something, yeah post-patch: i need to do something after patch, great pre-install: and then some more stuff before installing, wow [最後には必ず] .include <bsd.port.mk> Packageの名前 Package の名前は以下のルールにしたがってつけてください. こ れは package のディレクトリを見やすくするためで, 無秩序な名前 がたくさん並んでいるとユーザが使いづらくなるのでは という心配か らです. (FTPサイトなどにはたくさんpackageがありますからね.) Packageの名前は以下のようにしてください. 言語-名前-オプション バージョン.番号 DISTNAME が上記の形式になっていない場合に は, PKGNAME をそのようにしてください. FreeBSD はユーザの慣れ親しんだ言語のサポートに力を入れて います. 特定の言語のためのportのpackage名には 言語- に ISO-639 で定義されている言語名の略称を入れ てください. 例えば, 日本語なら ja, ロシア語なら ru, ベト ナム語なら vi, 中国語なら zh, 韓国語ならば ko, ドイツ 語なら de, といった具合です. 名前 の部分は原則的にはすべて英小文字 を使います. 例外はたくさんのプログラムが入っている巨大なport の場合で, XFree86 (ほんとにあるんですよ) やImageMagickな どがこれにあたります. そうでない場合には, 名前の大文字を小文 字に (少なくとも最初の一字だけは) 変えてください. もし, 大文字であることが重要な場合(例えば, 1文字の名前, R とか V)には, あなたの裁量で大文字を使うのも良いでしょう. Perl 5 のモジュールでは, 頭に p5- を付け, 2重コロン (::) のセパレータをハイフン( - ) に置きかえるしきたりになっています. 例えば, Data::Dumper は p5-Data-Dumper になります. また, その ソフトウェアの名前として通常使われるものに番号, ハイフン, あ るいは下線が入っている場合には, それらを使うことも構いません (kinput2 など). コンパイル時に環境変数や make の引数などで ハードコードされたデフォルト を変えてコンパイルできる場合, -compiled.specifics にそのコンパイル時のデフォルトを入れてください (ハイフンはあってもなくてもかまいません). 用紙のサイズ, あるいはフォントの解像度などがこれにあたります. バージョン番号は数字とアルファベットからなり, ピリオド (.) で区切ります. アルファベットは二文字以上続けてはいけませ ん. ただ一つの例外は「パッチレベル」を意味する pl で, それ 以外にバージョン番号が まったくついていない場合にのみ使うことがで きます. では, DISTNAMEを正しい PKGNAMEに直す例を見てみましょう: DISTNAME PKGNAME 理由 mule-2.2.2. mule-2.2.2 まったく問題なし XFree86-3.1.2 XFree86-3.1.2 同上 EmiClock-1.0.2 emiclock-1.0.2 プログラム一つだけの時は小文字のみ gmod1.4 gmod-1.4 `<名前>' のあとにハイフンが必要 xmris.4.0.2 xmris-4.0.2 同上 rdist-1.3alpha rdist-1.3a alphaのような文字列は使えない es-0.9-beta1 es-0.9b1 同上 v3.3beta021.src tiff-3.3 なんなんでしょう ;) tvtwm tvtwm-pl11 バージョン番号は必ず必要 piewm piewm-1.0 同上 xvgr-2.10pl1 xvgr-2.10.1 pl が使えるのは他にバージョン番号がない場合のみ gawk-2.15.6 ja-gawk-2.15.6 日本語バージョン psutils-1.13 psutils-letter-1.13 コンパイル時に用紙のサイズを指定 pkfonts pkfonts300-1.0 300dpiフォント用のpackage オリジナルのソースにまったくバージョン情報が見当たらず, また原作 者が新しいバージョンをリリースする可能性が低いときには, バージョ ン番号として 1.0 を使えばいいでしょう (上記のpiewmの例がこ れにあたります). そうでない場合には, 原作者に聞くか, 日付 ( 年.月 .日) を使うなどしてください. カテゴリ すでに御存知のように, ports はいくつかのカテゴリに 分類されています. これを有効に利用するためには, port を 行う人々とユーザが, そろぞれのカテゴリが何であるか, どのようにしてカテゴリに分類するかを理解する必要が あります. 現在のカテゴリのリスト まず, これが現在の port のカテゴリーのリストです. アスタリスク(*) が付いているものは, バーチャル(virtual) カテゴリです -- これらには対応するサブディレクトリが port ツリーにはありません. バーチャルカテゴリでないものは, そのサブディレクトリ内の pkg/COMMENT に1行の記述があります (例, archivers/pkg/COMMENT). Category Description afterstep* Ports to support AfterStep window manager archivers Archiving tools. astro Astronomical ports. audio Sound support. benchmarks Benchmarking utilities. biology Biology-related software. cad Computer aided design tools. chinese Chinese language support. comms Communication software. Mostly software to talk to your serial port. converters Character code converters. databases Databases. deskutils Things that used to be on the desktop before computers were invented. devel Development utilities. Do not put libraries here just because they are libraries—unless they truly don't belong to anywhere else, they shouldn't be in this category. editors General editors. Specialized editors go in the section for those tools (e.g., a mathematical-formula editor will go in math). elisp Emacs-lisp ports. emulators Emulators for other operating systems. Terminal emulators do not belong here—X-based ones should go to x11 and text-based ones to either comms or misc, depending on the exact functionality. games Games. german German language support. graphics Graphics utilities. japanese Japanese language support. kde* Ports that form the K Desktop Environment (kde). korean Korean language support. lang Programming languages. mail Mail software. math Numerical computation software and other utilities for mathematics. mbone MBone applications. misc Miscellaneous utilities—basically things that doesn't belong to anywhere else. This is the only category that should not appear with any other non-virtual category. If you have misc with something else in your CATEGORIES line, that means you can safely delete misc and just put the port in that other subdirectory! net Miscellaneous networking software. news USENET news software. offix* Ports from the OffiX suite. palm Software support for the 3Com Palm(tm) series. perl5* Ports that require perl version 5 to run. plan9* Various programs from Plan9. print Printing software. Desktop publishing tools (previewers, etc.) belong here too. python* Software written in python. russian Russian language support. security Security utilities. shells Command line shells. sysutils System utilities. tcl75* Ports that use tcl version 7.5 to run. tcl76* Ports that use tcl version 7.6 to run. tcl80* Ports that use tcl version 8.0 to run. tcl81* Ports that use tcl version 8.1 to run. textproc Text processing utilities. It does not include desktop publishing tools, which go to print/. tk41* Ports that use tk version 4.1 to run. tk42* Ports that use tk version 4.2 to run. tk80* Ports that use tk version 8.0 to run. tk81* Ports that use tk version 8.1 to run. vietnamese Vietnamese language support. windowmaker* Ports to support the WindowMaker window manager www Software related to the World Wide Web. HTML language support belong here too. x11 The X window system and friends. This category is only for software that directly support the window system. Do not put regular X applications here. If your port is an X application, define USE_XLIB (implied by USE_IMAKE) and put it in appropriate categories. Also, many of them go into other x11-* categories (see below). x11-clocks X11 clocks. x11-fm X11 file managers. x11-fonts X11 fonts and font utilities. x11-toolkits X11 toolkits. x11-wm X11 window managers. 適切なカテゴリの選択 多くのカテゴリに重なるので, どれを '第一' カテゴリにするかを決めなければならないことが たびたびあるでしょう. これを うまく決めるルールがいくつかあります. 以下はその優先順のリストで, 優先度の高いものから 低いものの順に書いてあります. 言語特有のカテゴリがまず最初です. 例えば日本語の X11 のフォントをインストールする port の場合, CATEGORIES 行は japanese x11-fonts となるでしょう. より特徴的なカテゴリが, 一般的なカテゴリより 優先されます. 例えば, HTML エディタの場合は www editors となり, 逆順にはしないでください. また, port が mail, mbone, news, security, www のいづれかに属するとには, net は必要ありません. x11 を第2カテゴリにするのは, 第1カテゴリが自然言語の場合のみにしてください. 特に X のアプリケーションには x11 を指定しないでください. もし, あなたの port が他のどのカテゴリにも 属しないばあいには, misc にしてください. もし, あなたがカテゴリについて自信が持てない場合には, そのことを send-pr するときに 書き加えてください. そうすれば import するまえに それについて議論できます. (もしあなたが commiter であれば, そのことを &a.ports に送って, 先に議論 するようにしてください — 新しい port が間違ったカテゴリに import されて, すぐ移動されることが多いので.) このドキュメントと ports システムの変更 もしあなたが, たくさんの ports の保守を しているのであれば, &a.ports メーリングリストの内容を フォロウすることを考えてください. Ports のしくみについての重要な変更点はここに アナウンスされます. 最新の変更点については, いつでも, the bsd.port.mk CVS log で詳細な情報を得ることができます. + url="http://www.FreeBSD.ORG/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk"> the bsd.port.mk CVS log で詳細な情報を得ることができます. やっとおしまい! いやはや, 長い文章ですみません. ここまで読んでくださった方に は感謝, 感謝でございます. (_ _) さあ, portの作り方がわかったところで, 世界中のソフトウェア をport化しましょう. FreeBSDプロジェクトに貢献するには, それ がもっとも簡単な方法です! :) diff --git a/ja_JP.eucJP/books/porter-handbook/book.sgml b/ja_JP.eucJP/books/porter-handbook/book.sgml index a36d1c49eb..f27bce571b 100644 --- a/ja_JP.eucJP/books/porter-handbook/book.sgml +++ b/ja_JP.eucJP/books/porter-handbook/book.sgml @@ -1,5231 +1,5233 @@ アプリケーションのインストール : ports コレクション 原作: &a.jraynard;. 訳: &a.jp.masaki;, &a.jp.saeki;. 11 November 1996. FreeBSD の ports コレクションを利用すると, 最小限の労力で 非常に幅広くのアプリケーションのコンパイルとインストールがおこなえます. やってみたことのある方はよくご存知でしょうが, オープンな規格とは 全くの誇大広告であって, あるプログラムを異なるバージョンの Unix 上で 動作させることは退屈で手間のかかる仕事です. 求めているプログラムが自分のシステムでうまくコンパイルでき, 正しいところにインストールできて, 完璧に動作するとしたらとてもラッキーです. しかし, あいにくこれは滅多にないことなのです. ほとんどのプログラムについて, あなたは髪を掻きむしることになるでしょうし, かなりのプログラムでは, 白髪混じりの頭になってしまったり, あるいは慢性の 脱毛症にすら なってしまうかもしれません... いくつかのソフトウェアディストリビューションでは, 設定用のスクリプトを 配布することでこの問題を解決しようとしています. これらのスクリプトの中には非常に精巧なものもありますが, 残念ながら, 中にはこれまで 聞いたこともないようなシステムの名前をしゃあしゃあと 言い放ったうえに, まるでシステムレベルの Unix プログラミングに関する 最終試験のような, たくさんの質問をしてくる場合があります. (例えば, このシステムの gethitlist 関数は fromboz への const ポインタを 返しますか? それとも const fromboz へのポインタを返しますか?, このシステムには Foonix スタイルの, 容認できない例外処理をおこなう ルーチンがありますか? もしもないとしたら, それはなぜですか?) 幸いなことに, ports コレクションがあれば, これらのきつい作業はすべて 完了しています. make install とタイプするだけで, 動作するプログラムを 入手することができるのです. なぜ ports コレクションを作ったのか? FreeBSD の基本システムは, 非常に多くのツールやユーティリティから 構成されています. しかし, よく使われるプログラムのうち多くのものが, この基本システムには含まれていません. その理由は:- ある Lisp ベースのエディタのように, それがないと生きていけないと 言う人もいれば, ディスクの無駄だと言う人もいるようなプログラム. 基本システムに組み込むには特殊すぎるプログラム. (CAD やデータベースなど.) “時間のある時に, ちょっと見ておかなければ”というような類の, それがシステムに含まれていないことが 致命的とは言えないプログラム. (おそらく, 何らかの言語などでしょう.) FreeBSD のような真面目なオペレーティングシステムの一部として 供給するには遊びが過ぎるようなプログラム. ;-) たくさんのプログラムを基本システムに組み込んだとしても, もっともっと 組み込みたいという要求が出てくるので, どこかで制限を引かなくてはならないため. (そうしなければ FreeBSD の配布物は, とてつもなく膨大になってしまうでしょう.) すべての人が自分のお気に入りの プログラムを手作業で移植しなければ ならないとしたら, (途方もない膨大な作業の繰り返しをさておいたとしても) それは明らかに不合理な話です. そこで, FreeBSD プロジェクトでは, 標準のツールを使って移植のプロセスを 自動化する巧妙な方法を考え出しました. なお, これは単純ながら非常に柔軟なツールを組み合わせることで, 非常に強力な働きをさせるという“Unix 流”の作業の優れた実例です. ports コレクションはどのように動くのでしょうか? インターネットでは通常, tarball の形で プログラムが配布されています. これは, Makefile とソースコードで構成され, 普通は何らかの説明書 (あいにく, いつもわかりやすく書かれているとは 限りませんが) が付属しています. ことによるとコンフィグレーションスクリプトも 含まれているかもしれません. 標準的な手順では, FTP で tarball を入手して, 適当なディレクトリで展開します. 次に説明書を読んで, 必要な変更をおこないます. そして, 設定スクリプトを実行し, 標準の make コマンドを使ってソースのコンパイルとインストールを おこないます. FreeBSD の ports も tarball の仕組みを利用していますが, これはユーザが 苦労して作業することを期待したものではなく, どのようにすれば FreeBSD 上で そのプログラムが動くようになるかという「ノウハウ」を スケルトン を使用して収めているものです. スケルトンは, カスタマイズ済みの Makefile も 提供していますので, ほとんどすべての ports は同じ手順でインストールすることが できます. もしあなたが (あなたの FreeBSD システム または FTP サイト にある) ports スケルトンを見ていて, そこに潜んでいる あらゆる種類の先端的な ロケット工学的なものを見つけられると期待していると, つまらなそうなファイルやディレクトリがそこにあるだけなのを見て, がっかりするかもしれません. (ports を手に入れる方法については, すぐに FreeBSD ports コレクションの入手方法 の節でお話します.) “一体どうしたらいいんだ? ここにはソースコードが ないじゃないか?” というあなたの叫びが聞こえるようです. 心配いりません. おとなしく読んでいけば, すべてが (たぶん) 明らかに なるでしょう. 試しに ports をインストールして, 何が起きるのかを見てみましょう. ここではサンプルとして開発者向けの便利なツール, ElectricFence を選択します. このスケルトンを選んだ理由は, 他の ports に比べても素直で理解しやすく 書かれているからです. 自宅で試してみる場合には, root になる必要があるでしょう. &prompt.root; cd /usr/ports/devel/ElectricFence &prompt.root; make install >> Checksum OK for ElectricFence-2.0.5.tar.gz. ===> Extracting for ElectricFence-2.0.5 ===> Patching for ElectricFence-2.0.5 ===> Applying FreeBSD patches for ElectricFence-2.0.5 ===> Configuring for ElectricFence-2.0.5 ===> Building for ElectricFence-2.0.5 [大量のメッセージをコンパイラが出力します...] ===> Installing for ElectricFence-2.0.5 ===> Warning: your umask is "0002". If this is not desired, set it to an appropriate value and install this port again by ``make reinstall''. install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.a /usr/local/lib install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.3 /usr/local/man/man3 ===> Compressing manual pages for ElectricFence-2.0.5 ===> Registering installation for ElectricFence-2.0.5 ここではあなたが混乱しないように, コンパイル時の出力を すべて取り除いてあります. もしもあなた自身で実行されたら, 最初にこのような 出力結果が得られるはずです:- &prompt.root; make install >> ElectricFence-2.0.5.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://ftp.doc.ic.ac.uk/Mirrors/sunsite.unc.edu/pub/Linux/devel/lang/c/. make プログラムは, あなたの手元にソースコードがないことを検出し, 処理を続けられるようにソースを FTP でダウンロードしようとします. この例では, あらかじめ手動でソースコードを用意してあったので, 持ってくる必要はありませんでした. では, 続けて make プログラムが何をしているのか見てみましょう. ソースコード tarball のありかを 確認します. 手元にファイルが存在しなければ, FTP サイトから入手しようとします. チェックサム テストを実行して, その tarball が事故か何かで途中で切れていたり, ASCII モードで ダウンロードされていたり, 転送中にニュートリノによって傷められたりして 改変されたりしていないかどうかを確認します. tarball を一時的な作業用ディレクトリに展開します. FreeBSD 上でコンパイルしたり, 動作させるのに必要な すべての パッチ をソースコードに当てます. 構築のために必要な コンフィグレーションスクリプトを実行します. コンフィグレーションスクリプトの 質問には正確に答えてください. (いよいよ!) ソースコードをコンパイルします. 実行形式のプログラム, マニュアル, その他のサポートファイルを, システムのプログラムと混ざってしまわないように /usr/local 以下に インストールします. ports はすべて同じ場所にインストールされ, システムのあちこちにばらまかれることはありません. インストール結果はデータベースに登録されます. これにより, インストールしたプログラムがもしも気に入らなかったときも, システムから すべての痕跡をきれいに 消去 することができます. 以上のステップが make の出力と一致しているかどうか確認してください. 今まで確認していなかったのなら, 今からするようにしてください! FreeBSD ports コレクションの入手 あるプログラムの FreeBSD port を入手するには二つの方法があります. ひとつは FreeBSD CD-ROM を使う方法で, もうひとつは インターネット接続 を使う方法です. CD-ROM からコンパイルする FreeBSD CD-ROM がドライブに入っており, /cdrom にマウントされていると仮定すると (マウントポイントが /cdrom である必要があります), ただ普通に実行するだけで ports を構築できるようになり, tarball をネットワーク経由でダウンロードするのではなく /cdrom/ports/distfiles/ からさがすようになります (そこにあればの話ですが). CD-ROM にある port スケルトンを使いたければ, 他に /etc/make.conf の 変数を以下のようにセットする方法があります: PORTSDIR= /cdrom/ports DISTDIR= /tmp/distfiles WRKDIRPREFIX= /tmp (任意の十分な空きスペースの場所を /tmp とおいています). 次に, /cdrom/ports 下の適宜のサブディレクトリに cd して, 例のごとく make install とタイプします. WRKDIRPREFIX は port に /tmp/cdrom/ports の下でビルドさせようとします; 例えば, games/oneko は /tmp/cdrom/ports/games/oneko の下で ビルドされるでしょう. ライセンスの制限により, いくつかの ports でオリジナルのソースコードを CD-ROM に入れることができなかったものがあることに注意してください. この場合, インターネット経由で ports をコンパイルする の 節を参照してください. インターネット経由で ports をコンパイルする CD-ROM を持っていなかったり, その ports の最新バージョンを確実に入手したい 場合は, その ports の スケルトン を ダウンロードする必要があります. ところで, これは落し穴が たくさんある作業に見えるかもしれませんが, 実際には非常に簡単です. 初めに, あなたの動かしている FreeBSD がリリースバージョンなら ports ページ でその FreeBSD 用の “アップグレードキット” を手にいれてください. このパッケージには, 最新の ports をコンパイルするのに必要な, リリース以降に更新されたファイルが含まれています. FreeBSD の FTP サーバーがその場で tarball を作成できることを利用してスケルトンを入手すると 非常に便利です. ここでは例として databases ディレクトリにある gnats プログラムを使って説明します. (角型かっこの中の文はコメントなので, 実際に実行する場合には, これをタイプしないでください!):- &prompt.root; cd /usr/ports &prompt.root; mkdir databases &prompt.root; cd databases &prompt.root; ftp ftp.freebsd.org [ユーザ名 `ftp' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] > cd /pub/FreeBSD/ports/ports/databases > get gnats.tar [gnats スケルトンの tarballs を取得] > quit &prompt.root; tar xf gnats.tar [gnats スケルトンの展開] &prompt.root; cd gnats &prompt.root; make install [gnats の構築とインストール] さて何が起きるでしょうか? FTP サイトにいつも通りに接続して, データベースの サブディレクトリに移動します. get gnats.tar とコマンドを入力すると, FTP サイトでは gnats ディレクトリを tarred にしてくれるのです. gnats スケルトンを展開したら, gnats ディレクトリへ移動して ports を構築します. すでに 説明したように, make の過程で 手元にソースコードがないことを検出すると, ソースコードを取得してから 展開し, パッチ当てと構築をおこないます. それでは, 少し冒険をしてみましょう. 一つの ports スケルトンを 取得するかわりに, たとえば ports コレクションの中のデータベースの スケルトンをすべて, サブディレクトリ全体を取得してみましょう. やり方はほとんど同じです:- &prompt.root; cd /usr/ports &prompt.root; ftp ftp.freebsd.org [ユーザ名 `ftp' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] > cd /pub/FreeBSD/ports/ports > get databases.tar [データベースディレクトリの tarballs を取得] > quit &prompt.root; tar xf databases.tar [すべてのスケルトンを展開] &prompt.root; cd databases &prompt.root; make install [データベース ports 全部の構築とインストール] わずかばかりの簡単なコマンドで, この FreeBSD マシン上にデータベース プログラムを一揃い手に入れてしまいました! 一つの ports スケルトンを取ってきて それを構築する場合との違いは, すべてのディレクトリを一度に取得して, 全部を一度にコンパイルしたということだけです. かなり感動的だと思いませんか? たくさんの ports をインストールする つもりなら, おそらくすべての ports ディレクトリをダウンロードしておく 価値があるでしょう. スケルトン スケルトン (訳注: skeleton とは骸骨のことです) とは, 締め切りを守るため, 食事をするのを忘れるほど仕事にのめり込んだ ハッカーたちのなれの果ての ことでしょうか? FreeBSD の屋根裏に潜む, なにか気持ちの悪いものでしょうか? いいえ, ここでスケルトンの意味するところは, ports の魔術を実現するのに 必要とされるすべてのものを提供する最小の骨組みのことです. <filename>Makefile</filename> スケルトンのもっとも重要な要素は Makefile です. Makefile は ports を どのようにコンパイルし, インストールをおこなうかを指示する いろいろな命令を含んでいます. 以下に ElectricFence の Makefile を示します:- # New ports collection makefile for: Electric Fence # Version required: 2.0.5 # Date created: 13 November 1997 # Whom: jraynard # # $Id$ # DISTNAME= ElectricFence-2.0.5 CATEGORIES= devel MASTER_SITES= ${MASTER_SITE_SUNSITE} MASTER_SITE_SUBDIR= devel/lang/c MAINTAINER= jraynard@freebsd.org MAN3= libefence.3 do-install: ${INSTALL_DATA} ${WRKSRC}/libefence.a ${PREFIX}/lib ${INSTALL_MAN} ${WRKSRC}/libefence.3 ${PREFIX}/man/man3 .include <bsd.port.mk> "#" で始まる行は, 人間のためのコメント行です. (ほとんどの Unix のスクリプトと同じですね.) DISTNAME は tarball の名前から拡張子を取ったものです. CATEGORIES はこのプログラムの種類を示します. この場合, 開発者向けのユーティリティということになります. 完全なリストはこのハンドブックの カテゴリ をみてください. MASTER_SITES はマスタ FTP サイトの URL です. もしローカルシステムに tarball がない場合には, ここから取得します. これは信頼できると考えられているサイトで, 通常はそのプログラムを インターネット上で公式に配布しているサイトです. (そのソフトウェアがインターネット上で「公式に」 配布されているとしたら) MAINTAINER は, 例えば新しいバージョンのプログラムが出た場合に, 必要であれば スケルトンの更新をおこなう保守担当者の 電子メールアドレスです. 次の数行はとりあえず飛ばします. .include <bsd.port.mk> この行は, この ports に必要なその他の命令やコマンドは bsd.port.mk に 入っているということを示しています. これらはすべての ports で共通のものなので, それぞれの Makefile に書いておく必要はありません. そのため単一の標準ファイルに まとめられているのです. ここでは Makefile がどう働くかを詳細に調査するのが目的ではありませんので, MAN3 で始まる行は, インストールの後に ElectricFence のマニュアルを 圧縮するために使用される, と言っておくだけで充分でしょう. これにより, 貴重なディスクスペースが保護されているわけです. オリジナルの port では install ターゲットが用意されていないので, do-install からの 3 行が この ports によって生成されたファイルを 正しい場所に置くために使用されます. <filename>files</filename> ディレクトリ ports のチェックサム算出には MD5 アルゴリズムを使用しているので, この チェックサム を含んでいる ファイルは md5 と呼ばれます. ちょっと混乱するかもしれませんが, このファイルは files という 名前のディレクトリに置かれています. このディレクトリは, ports に必要だけれども, 他のどこにも属さない 雑多なファイルも含んでいます. <filename>patches</filename> ディレクトリ このディレクトリには, FreeBSD ですべてを正常に動作させるのに 必要な パッチ が含まれています. <filename>pkg</filename> ディレクトリ このディレクトリには, 非常に役立つ三つのファイルが含まれています:- COMMENT — プログラムについての 1 行の説明. DESCR — より詳細な説明. PLIST — プログラムのインストール時に作成される, すべてのファイルのリスト. ports が動かないのですが, どうしたらよいでしょう おやおや. では, 次の四つのどれかをやってみてください: 自分で修正する. ports の仕組みに関する技術的な詳細については, アプリケーションの移殖方法をご覧ください. 苦情をいう. これは電子メールで だけ にしてください! このようなメールの宛先は &a.ports; です. なお, 必ず port の名前やバージョン, その port のソースや distfile(s) を どこから入手したか, どんなエラーが発生したのかを書いておいてください. 忘れてしまう. これはほとんどの場合最も簡単な方法です. ports のプログラムのうち必要不可欠な物はごくわずかです. FTP サイトからコンパイル済みのパッケージを入手する. “マスター”パッケージコレクションは FreeBSD の FTP サイトの パッケージディレクトリ に置いてありますが, まずあなたの近くのローカルミラーサイトを確認してください! ソースからのコンパイルに挑戦するよりも, パッケージを使うほうが (全体的に見て) ずっと確実に動作するでしょうし, より手っ取り早い方法でもあります. システムにパッケージをインストールするには, &man.pkg.add.1; を使ってください. 質問と回答集 Q. 私はモデムについての議論を しているのかと思っていました??! A.なるほど, あなたはきっとコンピュータの背面についている シリアルポートのことだと思ってしまったのでしょう. あるバージョンの Unixから別のバージョンの Unix へとプログラムを 移殖することを “porting” というのですが, ここで我たちは “porting” の結果 という意味で “port” を使っています. (コンピュータに関わる人々の悪しき習慣として, ひとつの同じ言葉を複数の まったく違う意味として使うことがあるのです.) Q. 私は, 標準以外のプログラムのインストールには packages を使うと 思っていたのですが. A. そのとおり. 通常は packages が最も手早くて簡単な方法です. Q. それではどうして面倒な ports があるのですか? A. いくつかの理由があります:- いくつかのソフトウェアのライセンス条件には, バイナリではなくソースコードでの 配布を求めているものがあります. バイナリ配布を信用していない人もいます. 少なくともソースコード があれば, ソースコードを読んで, (理論的には) 潜在的な問題点を自分で 見つけ出すこともできるはずです. ローカルなパッチを入手した場合, それを自分で追加するために ソースコードが必要になります. プログラムがいかにコンパイルされるべきかについて, あなたはパッケージを作った人とは 異なる見解を持っているかもしれません. どんな最適化オプションをつけるべきかとか, デバッグバージョンを作ってから それを strip するべきだとか, いや, そうするべきでない, などなど, 確固たる見解を持っている人もいるでしょう. ソースコードを手元に置いておきたい人たちもいます. 彼らは, 退屈したときに眺めたり, あちこち解析してみたり, ソースコードを 借用したり (もちろん, ライセンスが許せばの話ですが) するのです. あなたがソースコードを持っていなければ, それはソフトウェアとは 言えませんね! ;-) Q. パッチとは何ですか? A. パッチとは, あるバージョンから他のバージョンへどのように変更するかを 示す, (通常は) 小さなファイルです. “23 行目を削除”, “468 行目の後に これらの 2 行を追加”, または“197 行目をこのように変更”というような 内容を含んでいます. これは, “diff” という名前のプログラムで生成されます. Q. tarball とは一体何ですか? A. .tar または .tar.gz という拡張子を持つファイルです. (.tar.Z のようなバリエーションも ありますし, DOS のファイルシステム用に .tgz と短縮される場合もあります.) これは基本的に, 一つのファイルに固めた (.tar) ディレクトリツリーです. 圧縮されている (.gz) 場合もあります. これは元々 Tape ARchives (訳注: テープアーカイブ) (このため tar という名前なのです) で使われていたものなのですが, インターネット上でプログラムのソースコードを配布するために 広く使われている方法です. これらのファイルの中身を見たり, 展開したりすることもできます. FreeBSD の基本システムに付属する Unix 標準の tar コマンドを使ってみると 次のようになります:- &prompt.user; tar tvzf foobar.tar.gz &prompt.user; tar xzvf foobar.tar.gz &prompt.user; tar tvf foobar.tar &prompt.user; tar xvf foobar.tar Q. チェックサムとは何ですか? A. これは, チェックしたいファイル中のすべてのデータを加えて生成した 数値です. 何か文字が書き換わっていたら, チェックサムが一致しなくなります. そのため, 単純な比較だけで違いを見つけることができるのです. (実際には, 文字の位置が入れ替わるなどの, 単純な加算ではわからない問題も 見つけることができる複雑な方法で計算されています.) Q. 私は, CD-ROM から ports をコンパイルする にしたがって ports をインストールしていました. kermit をインストールしようとするまではうまくいっていました:- &prompt.root; make install >> cku190.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://kermit.columbia.edu/kermit/archives/. なぜ cku190.tar.gz が見つからないのでしょうか? 不良品の CD-ROM を買ってしまったのでしょうか? A. Kermit の権利を持つチームは, 私たちの CDROM に kermit の tarball を 入れることを許可しませんでした. 申し分けありませんが, 手動でファイルを 入手してください. このようなエラーメッセージが出たのは, あなたがそのときインターネットに 接続していなかったためです. あらかじめ上記のサイトのいずれかからファイルを ダウンロードしておけば, プロセスを再開することができます. (ダウンロードの際には, あなたに最も近いサイトを選ぶようにしてください. そうすれば, 時間とインターネットの帯域の節約になります) Q. kermit の tarball を入手しましたが, /usr/ports/distfiles に ファイルを置こうとすると, 書き込み権がないというエラーがでます. A. ports のしくみは /usr/ports/distfiles から tarball を探します. しかし, これは read-only の CD-ROM へのシンボリックリンクなので, ここにファイルを置くことはできません. 次のようにすれば, 他の場所を探すよう ports に指示することができます. - &prompt.root; make DISTDIR=/where/you/put/it install + &prompt.root; make DISTDIR=/where/you/put/it install Q. ports では, すべてを /usr/ports に置いたときだけ動作するのでしょうか? システムの管理者によると, 私の個人的なファイルは /u/people/guests/wurzburger に入れなければならないのですが, これでは うまくいかないように思います. A. PORTSDIR 変数と PREFIX 変数を変更することで, 違うディレクトリを 使用することができます. 例えば, &prompt.root; make PORTSDIR=/u/people/guests/wurzburger/ports install とすると, ports は /u/people/guests/wurzburger/ports でコンパイルされ, すべて /usr/local 以下にインストールされます. &prompt.root; make PREFIX=/u/people/guests/wurzburger/local install この場合, コンパイルは /usr/ports でおこない, /u/people/guests/wurzburger/local にインストールします. もちろん, 以下のように両者を組み合わせることも可能です. &prompt.root; make PORTSDIR=.../ports PREFIX=.../local install (省略せずに記述したら, このページに収めるには長すぎるのですが, 考え方は理解していただけたと思います) もし ports をインストールするたびに, これらを毎回タイプするのが 気に入らないのであれば, (正直に言って, 誰もそう思わないでしょう) これらを環境変数にセットしてしまうという手があります. Q. 私は, FreeBSD の CD-ROM を持っていませんが, 私はすべての tarball を 私のシステムに置いておきたいのです. そうすれば, 私は ports をインストール するたびに, 毎回ダウンロードが終わるのを待たなくてすむでしょう. これを一度におこなう簡単な方法はありませんか? A. ports コレクション全体の tarball を持ってくるには, 次のようにしてください. &prompt.root; cd /usr/ports &prompt.root; make fetch ports の下のディレクトリひとつの tarball を持ってくるには, 次のように してください. - &prompt.root; cd /usr/ports/directory + &prompt.root; cd /usr/ports/directory &prompt.root; make fetch ports をひとつだけ持ってくる方法は, きっと既にご存知だと思います. Q. マスタ FTP サイトから tarball を持ってくるより, 近くにある FreeBSD の ミラーサイトから持ってきた方が速いはずです. MASTER_SITES に書かれている サイト以外から持ってくるように ports に指示する方法はありませんか? A. もちろんあります. 例えば ftp.FreeBSD.ORG が MASTER_SITES に書かれている サイトより近いとしたら, 以下のようにしてください. - &prompt.root; cd /usr/ports/directory + &prompt.root; cd /usr/ports/directory &prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/distfiles/ fetch Q. ダウンロードをする前に, どんなファイルが必要なのか知りたいのですが. A. make fetch-list とすると, ports に必要なファイルの一覧を表示できます. Q. ports のコンパイルを途中で止める方法はありますか? 私はインストールをする前に いろいろとソースコードを解析したいのですが, 毎回 control-C を打たなければならないのが少し面倒です. A. make extract を実行すると, ファイル転送とソースコードの展開まで おこなったところで停止します. Q. 自分で ports を作ろうとしています. 私の作ったパッチが 正しく処理できることを確認できるように, コンパイルを止めたいのです. パッチのための make extract のようなものはありませんか? A. あります. make patch があなたのお望みのものです. おそらく PATCH_DEBUG オプションも同様に お役に立つことでしょう. ところで, あなたの努力に感謝いたします!! Q. あるコンパイルオプションはバグの 原因になるという話を聞きました. 本当なのでしょうか? どうやったら正しい設定で ports をコンパイルできますか? A. 本当です. gcc の バージョン 2.6.3 (FreeBSDの 2.1.0 と 2.1.5 に付属している バージョン) では, オプションを オプションなしで 使うと, バグのあるコードを出力します (ほとんどの ports は オプションを 使いません). コンバイラオプションは次のように定義 すべき です. &prompt.root; make CFLAGS='-O2 -fno-strength-reduce' install これを /etc/make.conf に書いておくこともできますが, 残念なことに すべての ports がこの指定を尊重してくれる 訳ではありません. もっとも確実なのは make configure を実行し, ソースディレクトリの Makefile を見て手で修整することですが, ソースが 多くのサブディレクトリにわかれていて, 各々に Makefile がある場合は 大変な仕事になります. Q. ports がたくさんありすぎて, 私の欲しいものがなかなか見つけられません. どんな ports が使えるのか, リストはどこかにありませんか? A. /usr/ports の中にある INDEX ファイルを見てみましょう. あるキーワードで ports コレクションを検索したければ, それも可能です. たとえば, 以下のようにすればプログラミング言語 LISP に関連した ports を見つけることができます: &prompt.user; cd /usr/ports &prompt.user; make search key=lisp Q. foo ports をインストールしたいのですが, それのコンパイルは すぐに停止して, bar ports のコンパイルが始まってしまいます. 一体どうして? A. foo ports が, bar ports の提供する何らかの機能を必要としているからです. 例えば foo が画像を使うとすると, bar は画像処理に必要な ライブラリを持っている, などです. または, bar は foo をコンパイルするのに必要なツールなのかもしれません. Q. ports から grizzle プログラムをインストールしましたが, まったく ディスクスペースの浪費です. 削除したいのですが, すべてのファイルが どこへインストールされたのかわかりません. 何か手がかりはありませんか? A. 大丈夫, 次のようにしてください. &prompt.root; pkg_delete grizzle-6.5 Q. ちょっと待ってください. 削除しようとするコマンドのバージョン番号を 知っていなくてはならないのでしょうか? あなたは, 私がバージョン番号を 覚えていることを本気で当てにしているのでしょうか? A. そんなことはありません. バージョン番号は次のようにすればわかります. &prompt.root; pkg_info -a | grep grizzle Information for grizzle-6.5: grizzle-6.5 - the combined piano tutorial, LOGO interpreter and shoot 'em up arcade game. Q. ディスク容量のことなのですが, ports のディレクトリは非常に膨大な容量を 使うように見えます. 残しておいた方がよいのでしょうか? 削除してしまっても よいのでしょうか? A. はい. インストールが首尾よく終わり, もうソースコードが必要でないと思うなら, それらを残しておく理由はないでしょう. 一番よい方法は, 次の通りです. &prompt.root; cd /usr/ports &prompt.root; make clean これは, すべての ports のサブディレクトリを調べ, 各 ports のスケルトン以外の削除をおこないます. Q. これを試してみたのですが, tarball や ports で使われたファイルが distfiles ディレクトリに残っています. これも削除してしまっても大丈夫ですか? A. はい. それを使った作業が終わったのであれば, 削除してしまっても大丈夫です. Q. 私はとてもとてもたくさんのプログラムを楽しみたいのです. 一度にすべての ports をインストールする方法はありませんか? A. 次のようにしてください. &prompt.root; cd /usr/ports &prompt.root; make install Q. やってみました. 時間がとてもかかるだろうと思ったので, そのまま実行を 続けさせて, 私は寝ました. 翌朝コンピュータを見てみると, 三つ半の ports しか 処理が終わっていませんでした. なにか悪かったのでしょうか? A. これは ports の中には私たちの決められないこと (例えば, あなたが A4 の 用紙に印刷したいのか, US レターサイズの用紙に印刷したいのかなど) について 質問してくるものがあるからです. それらの質問には手動で答える必要があります. Q. 私は一日中モニタの前に座って過ごしたりしたくないのですが. 何かよいアイデアはありませんか? A. では, あなたが寝に / 仕事に / 公園にいく前に以下を実行してください:- &prompt.root; cd /usr/ports &prompt.root; make -DBATCH install これでユーザの入力を要求しないすべての ports をインストールします. そして, 戻ってきてから, 次のように実行してください. &prompt.root; cd /usr/ports &prompt.root; make -DIS_INTERACTIVE install そして, 残りの作業を実行してください. Q. 私たちは ports コレクションにある frobble を使っています. ですが, 私たちの必要に応じて ports を変更したところがあるのです. 自分でパッケージを作って, それを私たちのサイトのまわりに 簡単に配布できるような方法がありますか? A. もちろんあります. 変更点をパッチにする方法は知っていますよね:- - &prompt.root; cd /usr/ports/somewhere/frobble + &prompt.root; cd /usr/ports/somewhere/frobble &prompt.root; make extract &prompt.root; cd work/frobble-2.8 [あなたのパッチを当ててください] &prompt.root; cd ../.. &prompt.root; make package Q. この ports の技術は本当に賢いですね. どのようにして動いているのか 私はどうしても知りたいと思います. その秘密は何ですか? A. 秘密は一切ありません. Makefiles + URL="file://localhost/usr/ports/Mk/">Makefiles ディレクトリ にある bsd.ports.mk と bsd.ports.subdir.mk ファイルを見るだけです. 複雑なシェルスクリプトを嫌う読者は, このリンクを追いかけないほうが よいでしょう. 自分で port を作る 原作: &a.jkh;, &a.gpalmer;, &a.asami;, &a.obrien; and &a.hoek;. 28 August 1996. 訳: &a.jp.simokawa;, &a.asami;. 10 November 1996. 自分で port を作ることに興味がありますか, すばらしい! これから, FreeBSD 用のportを作る際の, いくつかのガイドラインを 説明します. 実際にportをコンパイルするときのほとんどの仕事は - /usr/share/mk/bsd.port.mk + /usr/ports/Mk/bsd.port.mk というファイルでおこないます. Portsコレクションについてのさらに細かい内部の働きについては, そちらの ファイルを参照してください. これにはコメントが細かく書いてありますので, Makefile を読むのにあまり慣れていない人でも, 得るものはとても大きいで しょう. ここでは, 変更可能な変数の一部についてのみ記述しています. ほとんどの変数はbsd.port.mk の始めに記述があります. また, このファイルは非標準のタブの設定になっています. Emacs や Vim はファイルのロード時にこれを認識しますが, viやexでは, ファイルをロードしたら :set tabstop=4 のようにして正しい値を設定する ことができます. 3分porting この節では, 簡単なportの方法について説明します. 多くの場合これ では不十分ですが, まあうまくいくかどうか試してみて損はないでしょ う. まず, 元のtarファイルをDISTDIRに置きます. デフォルトは/usr/ports/distfilesです. 以下では, ソフトウェアはそのままコンパイルされるとします. つまり, FreeBSDのマシンで動かすために, 変更がまったく必要ない とします. もしなにか変更が必要な場合には次の節も参照する必要 があります. <filename>Makefile</filename> の作成 最小限のMakefile は次のようなものです: # New ports collection makefile for: oneko # Version required: 1.1b # Date created: 5 December 1994 # Whom: asami # # $Id$ # DISTNAME= oneko-1.1b CATEGORIES= games MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ MAINTAINER= asami@FreeBSD.ORG MAN1= oneko.1 MANCOMPRESSED= yes USE_IMAKE= yes .include <bsd.port.mk> おわかりになりますでしょうか. $Id$があ る行の内容については, 気にしないでください. これはこのファイル がportsツリーに書き込まれるときにCVSによって自動的に書 き込まれます. もっと詳しい例が見たければ, Makefileのお手本 の節をご覧ください. Package記述ファイルの作成 どのようなportでも, packageにするしないに関わらず, 3つ の記述ファイルが必要です. pkgサブディレクトリにある, COMMENT, DESCR, それに PLISTです. <filename>COMMENT</filename> これには, そのportについての説明を1行で書きます. Package の名前, バージョン番号等は 含めないでください. たとえば, こんな具合です: A cat chasing a mouse all over the screen. <filename>DESCR</filename> これは, そのソフトウェアについての, すこし長い説明を記述します. その port が何をするのかについての数段落程度の 簡潔な解説があれば十分です. このファイルはマニュアルでもなければ, 使用方法やコンパイル方法についての細かい 説明書でもありません. 特に, READMEファイル manpage をコピーしようとしてしている場合には 注意してください. これらは多くの場合, そのポートの簡潔な説明に なっていなかったり, 扱いにくい形式(manpage の場合, 行を揃えるために空白が調整されます)になっていたりします. もしこのソフトウエアに公式の WWW のホームページがあれば, - ここに書いて下さい. + ここに書いて下さい. 自動化ツールが正しく動作するように, + Web サイトのうちの ひとつ には, 前に + WWW: を付け加えてください. このファイルの最後にあなたの名前を書くことが 推奨されています. たとえば, こんな具合です. This is a port of oneko, in which a cat chases a poor mouse all over the screen. : (うんぬん.) -http://www.oneko.org/ +WWW: http://www.oneko.org/ - Satoshi asami@cs.berkeley.edu <filename>PLIST</filename> このファイルには, このportによってインストールされるファ イルが列挙されます. このファイルはpackageを作る際のリス トとして使われるため, `packing list' とも呼ばれます. ここ に書かれているファイル名は, インストール時のプレフィックス (普通は /usr/local か /usr/X11R6) からの 相対パスです. MANn 変数を使用する場合(使用することが推奨されています)には, マニュアルはここに入れないでください. 簡単な例を載せておきましょう: bin/oneko lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpm @dirrm lib/X11/oneko 'Packing list'の詳細については, &man.pkg.create.1; の マニュアルを参照してください. すべてファイルを列挙しなければなりませんが, ディレクトリ名は必要ありません. また, ports がインストール時にディレクトリを作成する場合には, @dirrm の行を加えて, その port が削除されるとき, そのディレクトリも削除されるようにしてください. このファイルには, ファイル名をアルファベット順に並べるようにしてください. port のアップグレートのとき, 楽に確認ができるようになります. チェックサムファイルの作成 ただ, make makesum と入力するだけです. bsd.port.mk にルールがあるので, 自動的にfiles/md5が生成されます. Portのテスト そのportが正しく動くことを, package化を含めて確認してください. 以下の重要なポイントを確認してください. PLIST にその port がインストールしないものが含まれていないこと. PLIST にその port がインストールする全てのものが含まれていること. reinstall ターゲットを使うことによって, 何度でもインストールが可能こと. deintall の際に 後片付け をすること. 推奨されるテストの手順 make install make package make deinstall pkg_add `make package-name` make deinstall make reinstall make package package および deinstall の段階で, どんな警告(warning)も出力されないことを確認してください. ステップ3の後, 新しいディレクトリが全て正しく消去されているかを 確認してください. また, ステップ4の後にそのソフトウェアを使用してみて, package からインストールされた場合に正しく動作するかを 確認してください. <command>portlint</command> でチェック portlintを使って, あなたの port が我々のガイドラインそっているかを確認してください. portlint プログラムは ports コレクションに含まれています. 特に, Makefile が正しい形式になっているか, package の名前が正しいか, をチェックするのに良いでしょう. Portの送付 まず, やってよいことといけないこと についての節を読んでください. さあ, あなたのportに満足したら, あとはそれをFreeBSDのメイ ンのportsツリーに置いて, 皆に使ってもらうだけです. いまある work ディレクトリや pkgname.tgz パッケージは必要ありませんから, まず消去してください. あとは, バグレポートの中に shar `find port_dir` の出力を, &man.send-pr.1; プログラムを使用して送ってください. &man.send-pr.1; についての詳細は, バグ報告と一般的な論評 を参照してください.) もし, 圧縮していない状態で, 20KB以上あるようなポートであれば, 圧縮して tar ファイルにして, バグレポートに入れる前に &man.uuencode.1; を使用してください. (20KB以下のものでも, tar ファイルにして送ってもよいですが, あまり歓迎されません). バクレポートの category は ports, class は change-requestを必ず使用してください. (レポートを confidential (内密) にしないようにしてください!) もう一度, オリジナルのソースファイル, work ディレクトリ, make package で作成したパッケージが含まれていないこと を確認してください. 以前, 新しい port をわれわれの ftp サイト (ftp.freebsd.org) にアップロードするようにお願いしたことがありますが, 現在このサイトの incoming ディレクトリは読み出し不可になっており, いまでは推奨されていません. 沢山の海賊版ソフトウェアがそこに置かれたためです. 私たちは, 何か不明な点があったらあなたに確認したのち, それをツリーへ置きます. あなたの名前は, FreeBSD ハンドブックやその他のファイルの “Additional FreeBSD contributors” のリストにも載るでしょう. う〜ん, 素晴らし い. :) 本格的なport 残念ながら, 移植がそう簡単ではなく, 動かすために多少の変更が 必要な場合も多いでしょう. この節では, portsコレクション の方法論にのっとって, そのような場合にどのように変更を施し, 動 くようにしたらよいかを順を追って説明します. port構築の詳細 まず, あなたがportのディレクトリで make とタイ プしてから起こる一連の出来事について,順を追って説明しま す. ここを読むときには, 他のウィンドウで同時に bsd.port.mk も開いておくとよいかもしれません. しかし, bsd.port.mkが何をしているのか, 完全に理解 できなくても心配する必要はありません. そう多くの人が理解して いるわけではないですから... f(^_^;) まず, fetch というターゲットが実行されます. このfetchターゲットは ローカルディスクのDISTDIRに配布ファ イルがあるようにするのが役目です. もし, fetchが必要なファ イルをDISTDIRに見つけることが できなけ れば, Makefileに指定されているURL MASTER_SITES, そして私たちのFTPサイトで ある ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/ (ここ には, 私たちが取ってきたファイルを バックアップとして置いてあ ります) に探しにいきます. そして, ユーザのサイトがインター ネットに 直接接続されている場合には, FETCH を使って, その名前のファイルを取っ てきて, DISTDIRに保存します. 次に実行されるのは extract ターゲットです. これは, DISTDIRにある, 配布ファイル (普通は gzipされたtarファイル) を読み, ソースを一時的な作業ディレ クトリWRKDIR (デフォルトは work) に展開します. 次に, patch というターゲットが実行されます. まず, PATCHFILESに定義されている, すべてのパッ チをあてます. 次にもしPATCHDIR (デフォ ルトは patches サブディレクトリ) にパッチが存在す れば, これらをアルファベット順にあてます. 次に実行されるターゲットは configureです. これには, い ろいろな場合があります. もし存在すれば, scripts/configure が実行されます. もし, HAS_CONFIGURE あるいは GNU_CONFIGURE がセットされていれば, WRKSRC/configure が実行されます. もし, USE_IMAKE がセットされていれば, XMKMF (デフォルト: xmkmf -a) が実行されます. 最後に, build というターゲットが実行されます. これは, その port の専用の作業ディレクトリ (WRKSRC) にい き, コンパイルするのが役目です. もし USE_GMAKE がセットされていれば, GNU make が使用されます. さもなければFreeBSDの make が使用されます. 上記はデフォルトのルールです. さらに, pre-何とか や post-何とか というターゲット が定義してあった り,そのような名前のスクリプトが scripts サブディレクトリに置いてある場合には, それらはデフォルトの動作の前 後に実行されます. たとえば, post-extract というターゲットがMakefile で定義されていて, pre-build というファイルが, scripts サブディレクトリにあるとすると, post-extractターゲットは, 通常の展開動作のあとに呼 び出され, pre-build スクリプトはデフォルトのコンパイ ルのルールが実行される前に実行されます. もし動作が簡単であれ ば, Makefile のターゲットを使用することが推奨されています. な ぜならば, そのportが何らかのデフォルトではない動作を必要とす るのかどうかが一箇所にまとめて書いてあった方が他の人に 理解しやす いからです. デフォルトの動作は bsd.port.mk の do- 何とか というターゲットでおこなわれます. たとえば, portを展開するコマンドは, do-extract というターゲットにあります. もし, デフォルトのターゲットに 不満があれば, do- something というターゲッ トを再定義することによって, どのようにでも直すことができます. “メイン”のターゲット (例えば, extract, configure等) は, すべての前段階が実行されていること を確認して, 実際のターゲットやスクリプトを呼び出す以外のこと はしません. bsd.port.mkはこれらが変更されることは仮定してい ませんので, もし, 例えば, 展開の仕方を直したいときには, do-extract を直し, 絶対にextractには手を 触れないでください. これで, ユーザが make と入力したときに何が起こ るのかが理解できたと思います. では, 完璧なportを手順を追っ て作ってみましょう. オリジナルのソースの入手 オリジナルのソースを, (普通は) 圧縮されたtarファイルの形 ( foo.tar.gz あるいは foo.tar.Z) で入手して, それを DISTDIR にコピーします. 可能なかぎり, 広 く使われている主流の ソースを使用するようにしてください. もし, ネットワークへの接続のよい FTP/HTTP サイトを見つけるこ とができなかったり, 頭にくるような非標準的な形式しか持ってい ないサイトしか見つけられないときには, 自分で管理する確実な ftp か http サーバ (たとえば, あなたのホームページ)に置くこと ができます. MASTER_SITES に正しく反映されていることを確認してください. もしも, そのような都合の良く, 安心な置き場所が見つけられない 場合(あなたが FreeBSD の committer であれば, 自分の public_html ディレクトリに置けます), 私たちが, ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/distfiles/LOCAL_PORTS/ に置き場所を提供できます. この場所は, 変数 MASTER_SITE_LOCAL を使って参照してください. これについての問い合わせのメールは &a.ports へお願いします. その port の配布ファイルが特に理由もなく, しょっちゅう変る場合には, 配布ファイルをあなたのホームページに置いて MASTER_SITESの最初に入れてください. こうすることによって, ユーザ利用する場合に checksum mismatch エラーが起るのを防ぎ, 我々の ftp サイトの保守の負担を減らすことができます. もし, master site がたった一つしかない場合には, あなたのサイトにバックアップを置いて MASTER_SITES の2番目に加えてください. もし, あなたのportに必要ないくつかの追加パッチがインター ネット上で手に入るのならば, それらも取ってきて, DISTDIR に置きます. もし, それらがメイン のソースのtarファイルとは別のサイトにあっても, 心配する必要 はありません. そのような状況にはちゃんと対応できるようになっ ています. (以下のPATCHFILESの記述 をご覧ください). Portの修正 適当なディレクトリにtarファイルを展開して, FreeBSDの最新の バージョン上で, 正しくコンパイルできるために必要なあらゆる変 更を施します. 最終的に処理は自動化するわけですから, 何をおこなっ たかを注意深く記録しておきましょう. あなたのport が完成した暁には, ファイルの削除, 追加, 修正を含むすべての処 理が, 自動化されたスクリプトやパッチファイルで おこなえるようになっ ていないといけません. もし, あなたの port のコンパイルやインストールのために必要 な手作業があまりに多いようならば, Larry Wall の模範的な Configure スクリプトでも参考にしたほうがいいかもしれませ ん. 新しいportsコレクションは, 最小のディスクスペースで, 個々のportがエンドユーザにできるだけ“プラグ & プレ イ”の状態でmakeできることをめざしています. あなたが作成し FreeBSD の ports に寄付されたパッチファイル, スクリプトおよびその他のファイルは, 明示的に記述されている場合 を除いては, BSDの標準的な著作権条件によりカバーされていると見な されます. パッチをあてる port の過程で追加されたり変更されたファイルは再帰的diffで変 更点を取り出すことができます. パッチは適当にまとめて, patch-xx という名前のファイルに入れてくだ さい. xx はパッチが適用される順番を示します — これらは, アルファベット順, つまり aa が 最初, つぎに ab などとなります. これらのファイル をPATCHDIRに置いておくと, 自動的に適用さ れるようになっています. すべてのパッチは WRKSRC (通常は, portのtarファイルが展 開されるところで, makeが実行されるところと同じです) からの相 対パスになります. 修正やアップグレードを容易にするため, 2つ 以上のパッチが同じファイルを修正するのは避けてください. (例, patch-aaとpatch-abが共にWRKSRC/foobar.c を修正する, など.) コンフィグレーション カスタマイズのために追加したいコマンドがあれば, configure という名前のスクリプトに入れて scripts サブディレクトリに置きます. 上で述べたよ うに, pre-configure あるいは post-configure という Makefile のターゲットおよび/あるいはスクリプトで処理す ることもできます. ユーザからの入力の扱い もし, そのportがビルド, コンフィグレーション, インストー ルの際にユーザからの入力を必要とするならば, Makefileで IS_INTERACTIVEをセットしてください. これによって, 深夜, 自動的にたくさんのportをコンパイルすることが可能にな ります. 環境変数BATCHがセットされていると IS_INTERACTIVE の定義されているportはスキップされ ます (そして, ユーザがINTERACTIVEという変数をセッ トすると入力を必要とする port のみコンパイルされま す). もし, 適切なデフォルト設定があるのであれば, PACKAGE_BUILDING 変数をチェックして,それが設 定されて いる場合には, ユーザ入力のスクリプトを起動しないように してください. こうすることによって, CD-ROM や ftp に 置く packageを我々が作成することができます. Makefileの作成 Makefileの作成は非常に単純です. 繰り返しになりますが, 始める まえに, すでにある例を見てみることをお奨めします. またこのハ ンドブックにはMakefileのお手本 があります. それを見て, Makefile内の変数の順番や空行を入れると ころなどの参考にしてください. そうすると他の人々にも読みやすい ものとなります. では, Makefileをデザインするときに問題となるところを順に追っ て見てみましょう. オリジナルのソース ソースはDISTDIRに, 標準的なgzipされた tarファイルとして置かれていますか? そうであれば, 次のステッ プに進めます. そうでなければ, 変数 EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX, DISTFILES を適当に書き換えないといけません. どれだけ変更しないといけないかは, あなたのportの 配布ファイルがどの程度標準からかけはなれているかによりま す. (最もよくある場合は, gzipではなく普通のcompressコマンド でtarファイルが圧縮されている場合で, EXTRACT_SUFX=.tar.Z とするだけです.) 最悪の場合には, 自分で do-extract ターゲットを作 成して, デフォルトを上書きすることもできます. しかし, そこま でする必要があることはめったにないでしょう. <makevar>DISTNAME</makevar> DISTNAME には port の名前の基幹部分を入れ ます. デフォルトのルールでは, 配布ファイルのリスト (DISTFILES) は DISTNAME EXTRACT_SUFX という名前 になっています. 例えば, foozolix-1.0.tar.gzの場 合, 通常のtarファイルだと, DISTNAME=foozolix-1.0 のようになります. さらにデフォルトのルールでは, tarファイルは work/DISTNAME というサブディレクトリ に展開されることを仮定しています, 例えば work/foozolix-1.0/ といった具合いです. これらの動作はもちろんすべて変更可能です. デフォルトのルー ルは最も標準的な場合を仮定しているだけです. まず, port が複 数の配布ファイルを必要とするときには, 単に明示的に DISTFILESを設定してください. もし, DISTFILES の一部だけが実際に展開される場合 には, それらをEXTRACT_ONLY に設定してくだ さい. この変数が定義されている場合には, 展開時に DISTFILESに優先して利用されます. 残りのファ イルもDISTDIRに取ってきますが, 展開時に はなにもせずに後で使うためにそのまま置いておかれます. <makevar>PKGNAME</makevar> もし, DISTNAME が我々の package の名前についてのガイドライン に沿ったものでない場合には, PKGNAME にもっと良い名前を設定してください. 詳細は上記のガイドラインを参照してください. <makevar>CATEGORIES</makevar> (分類) 完成した package の実体は /usr/ports/packages/All に置かれます. また, 1つかそれ以上の /usr/ports/packages のサブディレクトリからのシンボリッ クリンクが作られます. それらのサブディレクトリの名前が CATEGORIES という変数によって指定されます. これは, ユーザがFTPサイトやCD-ROMのpackageの山を渡り歩 くことを容易にするためです. 現在存在する カテゴリを見て, そ のportに適したもを選んでください. このリストは, この port が port tree のどこに import されるかも決定します. 2つ以上のカテゴリを指定した場合には 最初のカテゴリで指定されるサブディレクトリに置かれること になります. 適切なカテゴリを選ぶ方法については, カテゴリ の節を参照してください. もしその port が本当に現在存在するすべてのものとは異なって いる場合には, 新しいカテゴリ名を作ることもできます. その際には, &a.ports 宛てに新しいカテゴリ名を提案する メールを送ってください. カテゴリ名については, なんのエラーチェックも行なわれません.ミスタイプがあっても make package はなにも考えずに 新しいディレクトリを作ってしまいますので, 注意してください. <makevar>MASTER_SITES</makevar> オリジナルの配布ファイルを指し示す FTP または HTTP の URL のディ レクトリ部分までを MASTER_SITES に記録しま す. スラッシュ (/) を最後につけることをお忘れなく. 配布ファイルがシステム上に存在しないときに, makeマクロは FETCH でこの変数に指定されたサイトから取っ てきます. 複数の, できれば異なる大陸のサイトをこのリストに入れておく ことが推奨されています. これによって, 広域ネットワークにトラ ブルがあった場合でも成功する可能性が高くなります. 私たちはさら に, 自動的に最も近いマスタサイトを検出して, そこから取って くるメカニズムの導入を計画しています. オリジナルのtar ファイルが, X-contrib, GNU, Perl CPAN, TeX CTAN または Linux Sunsite などの有名なアーカイブにある場合には, MASTER_SITE_XCONTRIB, MASTER_SITE_GNU, MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN および MASTER_SITE_SUNSITE を利用することで, 簡単にこれらのサイトを 指定することができます. あとは MASTER_SITE_SUBDIR にアーカイ ブ内でのパスを指定するだけです. 以下に例を示します. MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications ユーザは/etc/make.conf中で MASTER_SITE_* 変数を設定 することによって, デフォルトの FTP サイトではなく, これらの 有名なアーカイブの ミラーの中で好みのものを使用することが可能 です. <makevar>PATCHFILES</makevar> もし, オリジナルの配布ファイル以外にもFTPかHTTPで手に入る パッチが必要な場合には, PATCHFILESにファ イル名を, PATCH_SITESにサイトとディレクト リの名前を MASTER_SITES と同様に設定してく ださい. そのパッチ内のファイル名ががソースツリーの 一番上のディレク トリ (WKRSRC) からの相対パスになっていな い場合には, PATCH_DIST_STRIPを指定してく ださい. 例えば, パッチ内のファイル名にすべて余計な foozolix-1.0/ がついている場合には, PATCH_DIST_STRIP=-p1としてください. これらのパッチは圧縮されていても大丈夫です. ファイル名が .gz か .Z で終わる場合には自動的に復元 されるようになっています. もしパッチが, 文書などその他のファイルと一緒に gzip された tarファイルで配布されている場合には，単純に PATCHFILES を使うことはできません. このような場合には, このパッチの tar ファイルの名前と場所を DISTFILES と MASTER_SITES に加えます. それから, pre-patch ターゲットで, パッチコマンドを走らせるか, パッチファイルを PATCHDIR ディレクトリに patch-xx という名前でコピーするかして, パッチを適用するようにします． 普通の gzip か compress された tar ファイルであれば, 通常のソースファイルと一緒にその時までに 展開されていますので, 明示的に展開する必要はありません. もし, 後者の方法を使用する場合には, すでにそのディレクトリにある なにかを上書きしないように, 注意する必要があります. さらに, pre-clean ターゲットにコピーしたパッチファイル を削除するコマンドを追加するのを忘れないでください. <makevar>MAINTAINER</makevar> あなたのメールアドレスをここに入れてください. お願いします. :) 保守担当者(maintainer)の責任についての詳細は， Makefile 中の MAINTAINER の節をご覧ください． 依存関係 このプログラムが他のportに依存する場合には, 必要なものが 自動的に作られるようにすることができます. そのために, 以下の 5つの変数が用意されています. よくあるケースのためにあらかじめ設定された依存変数や, いくつかの依存関係の制御のための変数があります. <makevar>LIB_DEPENDS</makevar> Port が必要とする非標準の共有ライブラリを この変数で指定 します. これは lib: dir: target という組のリストで, うち lib が共有ライブラリの名前, そして dir がそのライブラリが見つからない場合にインストールする port のあるディレクトリで, target はそのディレクトリで呼ばれるターゲットです. 例えば, LIB_DEPENDS= jpeg.9:${PORTSDIR}/graphics/jpeg:install と指定してあれば, まずメジャーバージョンが9のjpegライブ ラリがあるかどうか確認し, ない場合にはportsツリーの中の graphics/jpeg というサブディレクトリに移動し, そこ でコンパイルとインストールを行ないます. target の 部分は, DEPENDS_TARGET (デフォルトは install) と等しいときには省略できます. 前半の lib 部分は ldconfig -r | grep -wF への引数になります. この変数には正規表現を入れられません. この依存関係は2度チェックされます. まず extract ターゲットで, 次に install でチェックされます. (これは, その port を作成するマシンとインストールする マシンが違う場合でも, きちんとそのライブラリが利用できる ことを確認するためです.) また, 依存するもの名前は package の中にも含まれますので, ユーザのシステムに存在しなければ, pkg_add が自動的にインストールします. <makevar>RUN_DEPENDS</makevar> Port を使用する際に必要となるファイルまたはプログラムがある ときにはこの変数で指定します. これは path: dir :target とい う組のリストで, path がファイルまたはプログラムの 名前, そして dir がそれが見つからない場合に作成する ためのディレクトリ名で target はそのディレクトリで呼ばれるターゲットです. path の最初の文字がスラッ シュ (/) の場合にはファイルかディレクトリ とみなし, その存在を test -e でチェックします; そうでない場合には 実行可能であると仮定し, which -s を使って そのプログラムがユーザのサーチパス上に あるかどうか確認します. 例えばMakefileに以下のように書いてあるとします. RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \ wish8.0:${PORTSDIR}/x11-toolkits/tk80 まず, /usr/local/etc/innd というファイルかディレクトリが存在 するか確認し, ない場合にはportsツリーの中の news/inn というサブディレクトリから作られます. ま た, wish8.0 というプログラムがユーザのサーチパス中 にあるかどうか探し, ない場合には同じくportsツリーの x11-toolkits/tk80 というサブディレクトリから作られます. この例で, innd は実際にはプログラムです; この ように, プログラムであっても標準のサーチパス以外のところに あるようなものの場合には, 絶対パスで指定してください. この依存関係はinstall ステージのはじめでチェック されます. また, packageを作る際に必要となるportのpackage名 が記録され, pkg_addを使用すると ユーザのシステムに存在しない場合には自動的にそちら のpackageもインストールされるようになります. target の部分は, DEPENdS_TARGET と同じ場合には省略可能です. <makevar>BUILD_DEPENDS</makevar> Port のコンパイルに必要なファイルまたはプログラムがある ときは, この変数で指定してください. RUN_DEPENDSと同 様に, これは path: dir :target という組のリストです. 例 えば, BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip は unzip という名前のプログラムを探し, 見つから ない場合にはarchivers/unzip サブディレクトリで作 れという意味になります. ここでは “コンパイル” と一口にいいましたが, この変数は実際 にはファイルの展開から実際のコンパイル・リンクまで 全部をま とめて面倒を見てくれます. この依存関係は extract ステージからチェックされます. target の部分は DEPENDS_TARGET と同じ場合には省略可能です. <makevar>FETCH_DEPENDS</makevar> この変数は, portを取ってくるのに必要なファイルまたはプロ グラムを指定するのに使います. 上の二つと同様に, これは path: dir :target という組のリストです. 例えば, FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2 としておけば, ncftp2 という名前のプログラムを探 し, 見つからない場合にはnet/ncftp2 サブディレク トリにいってインストールします. この依存関係は fetch ステージからチェックされます. target の部分は DEPENDS_TARGET と同じ場合には省略可能です. <makevar>DEPENDS</makevar> 上記の四つのいずれにもあてはまらないような 依存関係がある場 合, または他の port がインストールされれているだけではなく, ソースが展開されている必要がある場合にはこの変数 を使います. これは dir :target という形式のリスト になります. 上記の四つと違って特に “確認”するものがありませんので. よくある依存関係を表す変数 もし ports が X Window System を必要とするのであれば, USE_XLIB=yes を定義してください. (これは USE_IMAKEも意味します) BSD make の代りに GNU make を必要とする場合には, USE_GMAKE=yes を定義. 動作するのに GNU autoconf を必要とする場合には, USE_AUTOCONF=yes を定義. 最新の qt toolkit を使用 する場合には USE_QT=yes を定義. perl 言語のバージョン5 を必要とする場合には, USE_PERL5=yes を定義してください. (特に最後のは重要で, FreeBSD のいくつかの バージョンでは基本システムに perl5 を含みますが, 他のものは含んでいません.) 依存関係に関する注意 上で述べたように, 依存する ports が必要になったときに呼ばれるデフォルトのターゲットは DEPENDS_TARGET で, そのデフォルトは install です. これは, ユーザの使用する変数で, port の Makefile で定義されるものではありません. もし, あなたのportが特別な方法で, 依存関係を扱う必要が ある場合には, DEPENDS_TARGET を再定義するのではなく, *_DEPENDS 変数の :target の部分を利用してください. make clean とタイプしたときには, 依存する port も自動的に clean されます. もしそうしたくない場合には, NOCLEANDEPENDS を環境変数として設定してください. 無条件に他の port に依存させるには, 特別に nonexistent という文字列を BUILD_DEPENDS あるいは RUN_DEPENDS の最初のフィールドに使用してください. これは, 他の port のソースが必要なときのみ使用してください. target も指定することによって, コンパイルの時間を節約することができます. 例えば, BUILD_DEPENDS= /nonexistent:${PORTSDIR}/graphics/jpeg:extract これは, 常に JPEG port の directory に行きソースの展開を行ないます. あなたがやりたいことが他の方法ではできない場合以外は, DEPENDS を使わないでください. これは常に 他の port の作成を行い(さらにデフォルトでインストール を行い), package も作成します. もし本当にこれがあなたの やりたいことでしたら, 代りにこれを BUILD_DEPENDS と RUN_DEPENDS で書くことをお勧めします — 少なくとも意図が明確になります. コンパイル時の特別な指定 GNUのmakeを使う場合には, USE_GMAKE=yes と指定してください. Port に GNU の configure が含まれ ている場合には, GNU_CONFIGURE=yes を使います(これは, HAS_CONFIGURE も意味します). configure に追加の引数 (デフォルトでは, GNU の configure では --prefix=${PREFIX}, GNUでない configure では空) を渡したい場合には追加部分を CONFIGURE_ARGS で指定してください. そのパッケージが autoconf を使用する場合には, USE_AUTOCONF=yes を使います. これは, GNU_CONFIGURE も意味し, configure の前に autoconf を実行します. X Window Systemのアプリケーションなど, imakeを 使って Imakefile から Makefile を作成するportの場合には USE_IMAKE=yes を指定してください. コンフィグレー ションステージで自動的にxmkmf -a が実行されます. も し フラグが問題をもたらすなら, さらに XMKMF=xmkmfとしてください. もし, port が imake を使用するけれども, install.man ターゲットがない場合には, NO_INSTALL_MANPAGES=yes を指定してください. ついでに, その port のオリジナルの作者を探し出して八つ裂きにすると いいでしょう.:> Portの Makefile が all 以外のものをメインのター ゲットとしている場合には, ALL_TARGET でそ れを指定してください. install と INSTALL_TARGET も同様です. もし, port の元の Makefile が all 以外のターゲットをメインのターゲットとしている場合には, ALL_TARGET をそれに合わせて設定してください. install と INSTALL_TARGET についても同様です. <makevar>NO_INSTALL_MANPAGES</makevar> あなたの port がimakeは使うものの install.man ターゲットを持っていない場合, NO_INSTALL_MANPAGES=yes を指定してください. つい でに, 作者を探し出して八つ裂きにするといいでしょ う. (-_-#) 特別な配慮 Portを作成する場合, 考慮しなくてはいけないことがさらにいくつかあります. この節では, それらのうちもっともありがちなものについて説明します. ldconfig 共有ライブラリをインストールするときには, 共有ライブラリのキャッシュを更新するために port の Makefile の post-installtarget から${LDCONFIG} -m を走らせてください. このコマンドの引数は共有ライブラリのインストールしてある ディレクトリ (通常 PREFIX/lib) です. また, pkg/PLIST に @exec /sbin/ldconfig -m と @unexec /sbin/ldconfig -R の組を入れて, package をインストールした場合にも共有ライブラリがすぐ使え, 削除の際にも, システムがまだライブラリが存在すると 誤認しないようにしてください. この行は共有ライブラリを指定する行のすぐ後に 書くのがよいでしょう: lib/libtvl80.so.1 @exec /sbin/ldconfig -m %D/lib @unexec /sbin/ldconfig -R 絶対に引数なしでただ ldconfig とだけ書いてある行を Makefile や pkg/PLIST ファイルに入れないでください. このコマンドを実行すると, 共有ライブラリのキャッシュが /usr/lib の内容のみとなり, ユーザのマシンにさまざまな問題をもたらします (「ぎゃぁ! このportをインストールしたら xinit が使えなくなっちゃった!」). この掟を破った者は, 永久に地獄の底で苦しみ続けるように, 閻魔様に頼んでおきます. ELF 対応 FreeBSD は 3.0-RELEASE で ELF に移行しましたので, シェアードライブラリを作成するたくさんの port を ELF 対応 にする必要があります. 3.0 システムは ELF としても a.out としてmも 動作しますし, 我々は非公式ではありますが, できるだけ長い間 2.2 システムのサポートをしたいと思っていますので, 複雑な状況です. 以下は a.out のみに対応している port をどのように a.out と ELF 両方に対応させるかのガイドライ ンです. このリストの一部は, 移行時にしかあてはまらないものもありますが, 古い port をアップグレードしたい場合に参考になるように, しばらくのあいだは残しておきます. a.out ライブラリの退避 a.out ライブラリは, /usr/local/lib から, aout サブディレクトリ に移動しなくはなりません. (もし移動しないと, ELF ports がそれらをあっさり上書きして しまいます.) 3.0-CURRENT の src/Makefile にある move-aout-libs ターゲット (aout-to-elf から呼ばれます) がその移動をしてくれます. a.out ライブラリを移動するだけなので, ELF と a.out の両方のライブラリが標準的な ディレクトリにあるシステムでは, このターゲットを実行しても安全です. フォーマット port ツリーは package をそのマシンのフォーマットで作成します. つまり, 2.2 では a.out, また 3.0 では `objformat` の結果によって, a.out か ELF になります. また, いったん a.out ライブラリをサブディレクトリに移動すると a.out ライブラリの作成はサポートされません. (つまり, あなたがにをすれば良いのかを理解しているのならば, うまく作成できるかもしれませんが, 自力でやらなければならないということです) もし port が aout でしか動作しないのなら, BROKEN_ELF に原因を説明する文字列を設定してください. この変数が設定された port は, ELF システム上でのビルドの際スキップされます. PORTOBJFORMAT bsd.port.mk において PORTOBJFORMAT は aout か elf に設定され, 環境変数 CONFIGURE_ENV, SCRIPTS_ENV, MAKE_ENV の中で export されます. (2.2-STABLE では常に aout になります). また, PORTOBJFORMAT=${PORTOBJFORMAT} として PLIST_SUB に渡されます. (以下にある ldconfig に関するコメントを参照して下さい.) この変数は, 以下のようにして bsd.port.mk 中で設定されます. PORTOBJFORMAT!= test -x /usr/bin/objformat && /usr/bin/objformat || echo aout この変数を使って, port の make の過程で何をすべきかを決定すべきですが, もし port の configure スクリプトが元々, ELF システムを自動的に検出するのであれば, PORTOBJFORMAT を参照する必要はありません. 共有ライブラリの作成 以下は, a.out と ELF での共有ライブラリの扱いの違いです. 共有ライブラリのバージョン ELF の共有ライブラリは, libfoo.so.M という名前になっていなければなりません. ここで M は単一の バージョン番号を表します. 一方 a.out のライブラリは libfoo.so.M. N という名前で, M はメジャーバージョン番号, N はマイナーバージョン番号になっている必要があります. これらを混同しないでください. libfoo.so.N. M という名のELF 共有ライブラリや libfoo.so.N という名の a.out 共有ライブラリ (あるいはシンボリックリンク) は 絶対にinstallしないでください. リンカコマンドライン 直接 ld を使用せずに, cc -shared を使用してください. たった一つの違いは, ELF には, コマンドラインにを加える必要があることです. ELF のリンカを満足させるためには, libfoo.so から libfoo.so.N へのシンボリックリンクを作る必要があります. これは, PLIST にも加えなくては いけませんし, a.out の場合でも害にはならないので (一部の port ではダイナミックリンクローディングのために 必要でもあります), PORTOBJFORMAT の設定を気にせずに, ただ単純にリンクを作成してください. <makevar>LIB_DEPENDS</makevar> すべての port の Makefile を編集して, LIB_DEPENDS からマイナー番号を除去する必要があり, 正規表現のサポートも除去する必要があります. (例えば, foo\\.1\\.\\(33|40\\) から foo.2) マッチングは grep -wF を使って行われます. <filename>PLIST</filename> PLIST は, a.out のマイナー番号が0であれば, 短い (ELFの) 共有ライブラリの名前を含み, さもなくば長い (a.outの) 名前を含んでいる必要があります. bsd.port.mk は 自動的に, PORTOBJFORMAT が aout であれば, .0 を 短い共有ライブラリの名前の行に付け加え, PORTOBJFORMAT が elf であれば, マイナー番号を 長い共有ライブラリの名前から削除します. ELF システムで 2 つのバージョン番号を持つ共有ライブラリを インストールしたり, aout システムで 1 つのバージョン番号しか持たない共有ライブラリを インストールするのが避けられない場合 (例えば他のオペレーティングシステム用の 互換ライブラリをインストールする port など), NO_FILTER_SHLIBS 変数を定義すれば, 前節で説明されている PLIST 編集の機能が停止されます. <literal>ldconfig</literal> Makefile 中の ldconfig の行は以下のようになります. ${SETENV} OBJFORMAT=${PORTOBJFORMAT} ${LDCONFIG} -m .... また PLIST 中では: @exec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -m ... @unexec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -R となります. これは, システムのデフォルトフォーマットではなく パッケージのフォーマットに応じて, 正しい ldconfig が呼ばれることを保証するためのものです. <makevar>MASTERDIR</makevar> もし, あなたの port が 変数(例えば 解像度とか紙のサイズなど)を変えたりした, ちょっと違うバージョンを作成する必要があるときには, ユーザが分りやすいように, package ごとに別々のサブディレクトリを作成し, ただし, できるだけ port 間でファイルを共有するようにしてください. 典型的な例では, うまく変数を使えば, とても短いMakefileだけ, 1つ以外のすべてのディレクトリに置くだけで済みます. その短い Makefile には MASTERDIR を使って, 残りのファイルがあるディレクトリを指定できます. また PKGNAME の一部に変数に使って, package が別々の名前を持つようにしてください. 以下が, とても良い例になるでしょう. これは japanese/xdvi300/Makefile の一部です: PKGNAME= ja-xdvi${RESOLUTION}-17 : # default RESOLUTION?= 300 .if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \ ${RESOLUTION} != 300 && ${RESOLUTION} != 400 @${ECHO} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\"" @${ECHO} "Possible values are: 118, 240, 300 (default) and 400." @${FALSE} .endif japanese/xdvi300 は通常のパッチ, package ファイルももっています. そこで, make と入力すると, デフォルトの解像度(300)を使って, 普通に port の作成を行います. 他の解像度に関してですが, これが, xdvi118/Makefile の(コメントを除いた) すべてです. RESOLUTION= 118 MASTERDIR= ${.CURDIR}/../xdvi300 .include ${MASTERDIR}/Makefile (xdvi240/Makefile と xdvi400/Makefile も同様です). MASTERDIR が bsd.port.mk に PATCHDIR や PKGDIR などの通常のサブディレクトリが xdvi300 にあることを教えます. RESOLUTION=118 の行が, xdvi300/Makefile の RESOLUTION=300 の行を無効にし, port は解像度を118として作成されます. 共有ライブラリのバージョン まず, 共有ライブラリのバージョンについての指針 を読んで, 共有ライブラリのバージョンを 一般的にどうすれば良いかを理解してください. 盲目的に, ソフトウエアの作者がちゃんと理解していると 信じててはいけません, 多くの場合違います. 細い点まで考慮することは大変重要なことです, なぜなら我々は互換性がないかもしれない大量の ソフトウェアを共存させようとする, 特殊な状況にあるからです. 不注意な port の導入が共有ライブラリに関して, 多大な問題を引き起したことが過去にあります (今まで, jpeg-6b がなぜ 9.0 といバージョン番号を持っているか不思議に 思ったことはありませんか?). もし, 疑問があれば, &a.ports; にメールを送ってください. ほとんどの時間は, 正しいシェアードライブラリのバージョンを決めることと, それを実現するためのパッチを作成することに終始します. しかしながら, が同じソフトウェアの違ったバージョンの ソフトウェアが既にツリーにあるばあいには, 状況は非常に複雑です. つまり, FreeBSD では, ユーザがリンカにどのバージョンの共有ライブラリを 使用するかを指定できないからです (リンカは常にもっとも高いバージョンを選びます). これは, もし, libfoo.so.3.2 と libfoo.so.4.0 がシステムに存在するときには, リンカに特別なアプリケーションだけ libfoo.so.3.2 をリンクするように指示する方法がないことを意味します. これは, コンパイル時のリンクという意味では完全に見劣りします. この場合の唯一の解決方法は, 共有ファイルの名前の ベース 部分を変えることです. 例えば, libfoo.so.4.0 を libfoo4.so.1.0 へ変えることによって, バージョン 3.2 とバージョン 4.0 共に他の port からリンクされることができるようになります. マニュアル MAN[1-9LN] 変数を使用すると, 自動的にすべてのマニュアルを pkg/PLIST に加えます (つまり, マニュアルを PLIST に加えては いけません — PLIST の生成 を参照してください). またマニュアルを /etc/make.conf 中の NOMANCOMPRESS の設定に応じて, install時に自動的に圧縮したり伸長したりします. マニュアルをインストール時に圧縮するかどうかを 指定するには, MANCOMPRESSED 変数を使用します. この変数は, 3つの値をとることができます, yes, no そして maybe です. yes はマニュアルが既に圧縮されて インストールされている, no はされていない, maybe はそのソフトウェアがすでに, NOMANCOMPRESS に合わせており bsd.port.mk が特別なにもする必要がないことを意味します. USE_IMAKE がセットされていて, NO_INSTALL_MANPAGES がセットされていなければ, MANCOMPRESSED は自動的に yes に設定され, それ以外の場合には, no になります. デフォルトがあなたの port に合わない場合以外は明示的に設定する必要がありません. PREFIX 以外のディレクトリの下に マニュアルを置くような port では MANPREFIX を指定することができます. さらに, 特定のセクションのマニュアルだけ, 標準ではない場所にインストールする場合, 例えばいくつかの Perl のモジュールの ports など, には個々のマニュアルのパスを MANsectPREFIX (sect は, 1-9, または, L か N を表わします) によって指定できます. ができます. マニュアルが, 言語特有のサブディレクトリに 置かれる場合には, 言語名を MANLANG に設定してください. この変数のデフォルト値は, "" になっています (つまり, 英語のみ). これは, 全部をまとめた例です. MAN1= foo.1 MAN3= bar.3 MAN4= baz.4 MANLANG= "" ja MAN3PREFIX= ${PREFIX}/share/foobar MANCOMPRESSED= yes 以下の6個のファイルがこの port でインストールされます. ${PREFIX}/man/man1/foo.1.gz ${PREFIX}/man/ja/man1/foo.1.gz ${PREFIX}/share/foobar/man/man3/bar.3.gz ${PREFIX}/share/foobar/man/ja/man3/bar.3.gz ${PREFIX}/man/man4/baz.4.gz ${PREFIX}/man/ja/man4/baz.4.gz Motifを必要とするport 最近はコンパイルに Motif を必要とするアプリケーションが増えて きました. (Motif自体は有料のものがいくつかの会社から手に入りま すし, 多くのアプリケーションがコンパイル可能な無料の互換ライブラリ が x11-toolkits/lesstifにあります) Motifはかなり広く使われていますし, 製品のライ センスではライブラリを静的にリンクした 実行形式は再配布が認めら れている場合が多いので, Motifを必要とするソフトウェアを簡単に 動的(port からコンパイルする人々のために)/静的(package を配布 する人々のために)にリンクできるような しくみが用意されています. <makevar>REQUIRES_MOTIF</makevar> Motif がないとコンパイルできないportのMakefileではこの変 数を指定してください. これによって, Motifを持っていない人が このportをコンパイルしようとするのを未然に防ぎます. <makevar>MOTIFLIB</makevar> この変数は bsd.port.mk によって Motif ライブラリの指 定に置き換えられます. ソース内のMakefileやImakefileで Motif ライブラリを指定しているところをこの変数に置き換えるよ うにパッチをあててください. 代表的な例としては以下の二つがあげられます: MakefileかImakefileの中でMotifライブラリが として使われている場合には, かわりに MOTIFLIB と書いてください. Imakefileの中で XmClientLibs が使われている 場合には, それを ${MOTIFLIB} ${XTOOLLIB} ${XLIB} と書きかえてください. MOTIFLIB は通常 -L/usr/X11R6/lib -lXm か /usr/X11R6/lib/libXm.a に置き換えら れます. したがって前に や をつけ る必要はありません. X11 のフォント もし, あなたの port が X window system のフォントをインストールするのであれば, それらを X11BASE/lib/X11/fonts/local に置くようにしてください. このディレクトリは XFree86 release 3.3.3 で新設されたものです. もし, それが存在しなければ作成し, ユーザに XFree86 を 3.3.3 かそれより新しいものに更新か, すくなくとも, このディレクトリを /etc/XF86Config の font path に加えるように促すメッセージを出力するようにしてください. Info ファイル 新しい版の texinfo(2.2.2-RELEASE およびそれ以降に入っています) には, install-info というコマンドが含まれており, dir ファイルに項目を追加したり, 削除したりすることがで きます. もし, あなたの port が info ドキュメントをインストー ルするのであれば, 以下の指示に従って, その port および package が正しく, ユーザの ${PREFIX}/info/dir ファイル を更新するようにしてください. (この節は, とても長くてすいません, しかし info ファイルを作りあげるためには, これらは不可欠 です. 正しく行なえば, 美しい リストができますので, 辛抱してください! :) まず, これを知っておかなければなりません: &prompt.user; install-info --help install-info [OPTION]... [INFO-FILE [DIR-FILE]] Install INFO-FILE in the Info directory file DIR-FILE. (訳注: Info ディレクトリの INO-FILE を DIR-FILE にインストールする) Options: --delete Delete existing entries in INFO-FILE; don't insert any new entries. (訳注: INFO-FILE の中の項目を削除, 新しい項目は一切追加しない.) : --entry=TEXT Insert TEXT as an Info directory entry. (訳注: TEXT を Info ディレクトリの項目として追加する.) : --section=SEC Put this file's entries in section SEC of the directory. (訳注: このファイルの項目を Info ディレクトリの SEC という節に置く.) : このプログラムは, 実際には info ファイルをインストール しません, 単に dir ファイルにエントリーを挿入したり削除し たりするだけです. これから, install-info を使用するように, ports を変換す る7段階の工程を示します. 例として editors/emacsを 使用します. まず, texinfo のソースを見て, @dircategory と @direntry 文がないファイルについて, それらを追加するパッチを作成します. 以下は, ここでの例での patchの一部です: --- ./man/vip.texi.org Fri Jun 16 15:31:11 1995 +++ ./man/vip.texi Tue May 20 01:28:33 1997 @@ -2,6 +2,10 @@ @setfilename ../info/vip @settitle VIP +@dircategory The Emacs editor and associated tools +@direntry +* VIP: (vip). A VI-emulation for Emacs. +@end direntry @iftex @finalout : フォーマットについては見ればわかると思います. dir というファイルに必要な項目を書いておいてくれる作者 も多いので, まず自分で書く前にさがしてみてください. また, 関係 する ports も調べて, 節(section)の名前や, インデントなどが きちんと合っているかどうかを確認してください (項目のテキスト は, すべて4つめのタブ・ストップ(tab stop)から始めることを推 奨します). 1つのファイルに対して1つの info の項目しか書けないことに注 意してください, これは, install-info --delete が, そのバグにより, @direntry セクションに複数の項目を書 いても, 初めの1つの項目しか削除してくれないからです. texinfo のソースにパッチをあてるかわりに, dir の項目 を install-info の 引数((, ) として与えることもできます. これはあまり良い方法とは 思えません, なぜなら, 同じ情報を3ヶ所(Makefile, PLIST の @exec/@unexec: 以下参照) に重複して, 書く必要があるからです. しかしながら, もし日本語(あるいは, 他のマルチバイト文字)の info ファイルがあるのならば, install-info の特別な引数を使用する必要があるでしょう, なぜならば, makeinfo がこのような texinfo ソースファイル を扱えないからです. (このようなものをどう扱うかの例としては, japanese/skk の Makefile と PLIST を見て ください.) portのディレクトリに戻って, make clean; make をして, info ファイルが texinfo ソースファイルから再び生成さ れることを確認してください. texinfo ソースファイルのほうが info ファイルよりも新しいので, make とタイプすれば, info ファイルは再構築されるはずですが, 多くの Makefile には info ファイルの正しい依存関係が書かれていません. emacs の場合, info ファイルの再構築ため, man サブディレクトリ に降りていくようにするために, メインの Makefile.in にパッ チをあてる必要がありました. --- ./Makefile.in.org Mon Aug 19 21:12:19 1996 +++ ./Makefile.in Tue Apr 15 00:15:28 1997 @@ -184,7 +184,7 @@ # Subdirectories to make recursively. `lisp' is not included # because the compiled lisp files are part of the distribution # and you cannot remake them without installing Emacs first. -SUBDIR = lib-src src +SUBDIR = lib-src src man # The makefiles of the directories in $SUBDIR. SUBDIR_MAKEFILES = lib-src/Makefile man/Makefile src/Makefile oldXMenu/Makefile lwlib/Makefile --- ./man/Makefile.in.org Thu Jun 27 15:27:19 1996 +++ ./man/Makefile.in Tue Apr 15 00:29:52 1997 @@ -66,6 +66,7 @@ ${srcdir}/gnu1.texi \ ${srcdir}/glossary.texi +all: info info: $(INFO_TARGETS) dvi: $(DVI_TARGETS) man サブディレクトリでのデフォルトターゲットは, info で呼ばれるのに対して, メインの Makefile では, all で呼びたいので, 2つめのpatchが必要でした. また, info info ファイルのインストールも削除しました, なぜなら, 同じものが同じ名前で既に /usr/share/info にあるからです. (このパッチはここにはありません.) もし, Makefile に dir ファイルをインストールす る個所があれば, 削除します. あなたの port がインストー ルしてはいけません. また, dir ファイルを壊してしまうよう なコマンドの類も削除します. --- ./Makefile.in.org Mon Aug 19 21:12:19 1996 +++ ./Makefile.in Mon Apr 14 23:38:07 1997 @@ -368,14 +368,8 @@ if [ `(cd ${srcdir}/info && /bin/pwd)` != `(cd ${infodir} && /bin/pwd)` ]; \ then \ (cd ${infodir}; \ - if [ -f dir ]; then \ - if [ ! -f dir.old ]; then mv -f dir dir.old; \ - else mv -f dir dir.bak; fi; \ - fi; \ cd ${srcdir}/info ; \ - (cd $${thisdir}; ${INSTALL_DATA} ${srcdir}/info/dir ${infodir}/dir); \ - (cd $${thisdir}; chmod a+r ${infodir}/dir); \ for f in ccmode* cl* dired-x* ediff* emacs* forms* gnus* info* message* mh-e* sc* vip*; do \ (cd $${thisdir}; \ ${INSTALL_DATA} ${srcdir}/info/$$f ${infodir}/$$f; \ chmod a+r ${infodir}/$$f); \ (これは, 既存のportを修正するときのみ必要です.) pkg/PLIST を見て, info/dir にパッチをあて ようとするものすべてを削除します. これらは, pkg/INSTALL やその他のファイルにもあるかもしれない ので, いろいろさがしてみてください. Index: pkg/PLIST =================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v retrieving revision 1.15 diff -u -r1.15 PLIST --- PLIST 1997/03/04 08:04:00 1.15 +++ PLIST 1997/04/15 06:32:12 @@ -15,9 +15,6 @@ man/man1/emacs.1.gz man/man1/etags.1.gz man/man1/ctags.1.gz -@unexec cp %D/info/dir %D/info/dir.bak -info/dir -@unexec cp %D/info/dir.bak %D/info/dir info/cl info/cl-1 info/cl-2 post-install ターゲットを Makefile に加えて, dir ファイルが存在しなければ作成するようにします. また, インストールされた info ファイルについては, install-info を実行するようします. Index: Makefile =================================================================== RCS file: /usr/cvs/ports/editors/emacs/Makefile,v retrieving revision 1.26 diff -u -r1.26 Makefile --- Makefile 1996/11/19 13:14:40 1.26 +++ Makefile 1997/05/20 10:25:09 1.28 @@ -20,5 +20,11 @@ post-install: .for file in emacs-19.34 emacsclient etags ctags b2m strip ${PREFIX}/bin/${file} .endfor + if [ ! -f ${PREFIX}/info/dir ]; then \ + ${SED} -ne '1,/Menu:/p' /usr/share/info/dir > ${PREFIX}/info/dir; \ + fi +.for info in emacs vip viper forms gnus mh-e cl sc dired-x ediff ccmode + install-info ${PREFIX}/info/${info} ${PREFIX}/info/dir +.endfor .include <bsd.port.mk> 新しい info ファイルを作成するのに, /usr/share/info/dir と上のコマンド, 以外は使用しな いでください. 実際のところ, もし port する人がこれに関して PLIST に自らまったく手を加える必要がないのであれば, 上 のパッチのはじめの3行を bsd.port.mk に加えたでしょう. PLIST を編集して, 同じ働きをする @exec 文, そ れにpkg_delete のために @unexec 文を加えてくださ い. @unexec を使用して info/dir を削除する必 要はありません. Index: pkg/PLIST =================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v retrieving revision 1.15 diff -u -r1.15 PLIST --- PLIST 1997/03/04 08:04:00 1.15 +++ PLIST 1997/05/20 10:25:12 1.17 @@ -16,7 +14,15 @@ man/man1/etags.1.gz man/man1/ctags.1.gz +@unexec install-info --delete %D/info/emacs %D/info/dir : +@unexec install-info --delete %D/info/ccmode %D/info/dir info/cl info/cl-1 @@ -87,6 +94,18 @@ info/viper-3 info/viper-4 +@exec [ -f %D/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > %D/info/dir +@exec install-info %D/info/emacs %D/info/dir : +@exec install-info %D/info/ccmode %D/info/dir libexec/emacs/19.34/i386--freebsd/cvtmail libexec/emacs/19.34/i386--freebsd/digest-doc @unexec install-info --delete コマンドは, info ファイル自身より先に置き, コマンドがファイルを読めるようにし ておかなければならないことに注意してください. また, @exec install-info コマンドは info ファイルおよび dir ファイルを作る @exec コマンドより後に おかなければなりません. テスト をして出来栄えに感服しましょう :) 各段階の前後に, dir ファイルをチェックしましょう. <filename>pkg/</filename> サブディレクトリ まだ触れていない, いくつかのこつが pkg/ サブディレクトリにはあり, 時として便利でしょう. <filename>MESSAGE</filename> もし, インストールする人にメッセージを表示する 必要がある場合には, そのメッセージを pkg/MESSAGE に置けます. この機能は, pkg_add の後の追加のインストール手続きを表示するときなどに, 重宝します. pkg/MESSAGE ファイルは pkg/PLIST に加える必要はありません. また, もしユーザが package ではなく port を使用して いる場合には自動的には表示されませんので, 明示的に post-install で表示するようにするべきでしょう. <filename>INSTALL</filename> バイナリパッケージが pkg_add でインストールされるときに, 実行される必要がある コマンドがあれば, pkg/INSTALL スクリプトを使って実行することができます. このスクリプトは自動的に package に加えられ, pkg_add によって2度実行されます. はじめは INSTALL ${PKGNAME} PRE-INSTALL と実行され, 2度目には, INSTALL ${PKGNAME} POST-INSTALL と実行されます. どちらのモードで実行されているかは, $2 を調べることによってわかります. 環境変数 PKG_PREFIX には package がインストールされるディレクトリが設定されます. 詳細は &man.pkg.add.1; を見てください. port を make install で インストールするときには, このスクリプトは自動的に実行されません. もし, 実行される必要があるならば, port の Makefile から明示的に呼ぶ必要があります. <filename>REQ</filename> port が(インストールされるシステムの状態によって) インストールされるべきか, されないべきか区別する必要が あるときには, “要件(requirements)” スクリプト pkg/REQ を作ることができます. これは, インストール及びデインストール (package の削除)の時に自動的に実行され, それらが処理されるべきかを決定します. make の変数にあわせた <filename>PLIST</filename> の変更 いくつかの port, 特に p5- portsなど, は configure のオプション (あるいは, p5- ports の場合は perl のバージョン)によって, PLIST を変える必要があります. これを容易に実現するために, PLIST 中の %%OSREL%%, %%PERL_VER%%, %%PERL_VERSION%% は, 適切に置き換えられるようになっています. %%OSREL%% の値は, オペレーティングシステムの数字で表されたリビジョンです (例えば, 2.2.7). %%PERL_VERSION%% は perl のバージョン番号全体(例えば, 5.00502 )で, %%PERL_VER%% はバージョン番号から, パッチレベルを引いてものです(例えば, 5.005). 他の置き換えが必要であれば, PLIST_SUB 変数に VAR=VALUE という形式のペアのリストを設定することによって, PLIST 中の %%VAR%% は VALUE に置き換えられます. 例えば, バージョンに固有の沢山のファイルを インストールする場合には, Makefile に OCTAVE_VERSION= 2.0.13 PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} と書いて, PLIST 中のバージョン番号が表われるすべてのところに, %%OCTAVE_VERSION%% と書きます. このようにしておけば, port をアップグレードするときに, 何十行(ときとして, 何百行)も PLIST を書き替えないですみます. この書き換えは ( マニュアル の追加も) do-install と post-install ターゲット のあいだに, PLIST を読み TMPPLIST (デフォルトは, WRKDIR/.PLIST.mktmp ) に書き込むことによって行なわれます. もし, あなたの port が PLIST を実行時に生成するのであれば, do-install のあいだか, その前に行うようにしてください. また, 書きかえられたあとのファイルを編集する必要がある場合には, post-install で, TMPPLIST を書きかえてください. <filename>pkg</filename> サブディレクトリにあるファイル名の変更 pkg サブディレクトリにあるファイルは全て, 変数を 使用して定義されていますので, 必要であれば Makefile 中で 変更可能です. いくつかの ports で 一つの pkg サブディレクトリを共有する場合や, 上記のファイルに書き込む 必要があるときなど, 特に便利です. (pkg サブディレクトリに直接書き込むのが良くない理由に ついては WRKDIR 以外への書きこみ を参照してください.) 以下が変数名とそのデフォルト値の表です. Variable Default value COMMENT ${PKGDIR}/DESCR DESCR ${PKGDIR}/DESCR PLIST ${PKGDIR}/PLIST PKGINSTALL ${PKGDIR}/PKGINSTALL PKGDEINSTALL ${PKGDIR}/PKGDEINSTALL PKGREQ ${PKGDIR}/REQ PKGMESSAGE ${PKGDIR}/MESSAGE PKG_ARGSを上書きせずに, これらの変数を変更 するようにしてください. PKG_ARGSを変更すると これらのファイルは port から正しく /var/db/pkg にインストールされなくなります. ライセンス上の問題 ソフトウェアによっては制限の厳しい ライセンスがついてきたり, 法律的に問題があるかもしれません. (PKPの公開鍵暗号化, ITAR (暗 号化ソフトウェアの輸出) などが例としてあげられます). それらを どう扱えばいいかはライセンスの文面によって さまざまな場合があり ます. ソフトウェア移植者として, あなたにはライセンスをよく読み, FreeBSD プロジェクトが FTP または CD-ROM で配布してはいけないソフ トウェアを配布してしまうことのないよう, 注意する義務があります. なにか疑問がある場合には, &a.ports;に聞いてみてください. よく見られるケースに対処するために, 二つの変数が用意されてい ます: ソフトウェアに “有償再配布を禁ずる” という趣旨のライセン スがついてきた場合には NO_CDROM という変数にその理由を記述して ください. 私たちはこれがついているportはCD-ROMリリースに入 れないようにしますが, オリジナルのソースファイルとpackage はFTPでは取れるようにしておきます. もしも, 生成される package が個々のサイトで独自に構築さ れる必要があったり, ライセンスによって生成されるバイナリが 配布できない場合には, NO_PACKAGE 変数にその理由を記述してくだ さい. そのような package が FTP サイトに置かれたり, リリース 時の CD-ROM へ入らないようにします. ただし, いずれの場合も distfile は(FTP や CD-ROM に)含まれるようになります. Portが, 使用者によっては法律上の問題が生じる時 (暗号化ソフ トウェアなど), または“商用利用を禁ずる”とライセンスに書い てある場合には RESTRICTEDという変数にその理由を入れ てください. この場合には, ソースファイルやpackageは私たちの FTPサイトにも置かれません. GNU一般公有使用許諾書 (GPL) はバージョン1, 2とも port作成上は何ら問題にはなりません. もしあなたが，ソースツリー管理者 (committer) であれば， ソースツリーにこのようなportを入れる際に, ports/LEGAL ファイルを書き換えるのを忘れないようにし てください. アップグレード Port のバージョンが原作者からのものに比べて古いことに気がつ いたら, まずはあなたの持っているportが私たちの最新のもの (ミラー サイトの ports/ports-current というディレクトリにあります) であることを確認してください. 次に, portの Makefile にMAINTAINER (保守担当者) の アドレスが書いてある場合には, その人にメールを出してみましょう. 保守担当者の人がすでにアップグレードの準備を しているかもしれま せんし, (新しいバージョンの安定度に問題があるなど) あえてアッ プグレードをしない理由があるのかもしれません. 保守担当者にアップグレードをしてくれと頼まれた場合, あるいは そもそもportのMakefileに保守担当者が書いてない場合などは, あ なたがアップグレードをしてくださると助かります. その場合にはアッ プグレードをしたのち, 変更前と変更後のディレクトリの再帰的diff (unified diff と context diff のどちらでもいいのですが, port のコミッター達は unified diff のほうを好むようです) をとって送ってください. (例えば, 変更前のディレクトリが superedit.bak という名前でとってあり, 変更後のもの が superedit に入っているなら, diff -ruN superedit.bak superedit の結果を送ってください. ) diff の出力を見て, すべての変更が正しくなされているか確認して ください. 変更箇所については, &man.send-pr.1; (カテゴリーは, ports)に diff の出力結果を添えて, 私たちに送ってもらうのが一 番よいです. commit する際に CVS に明確に記述しなければならない ので, 付け加えたり削除したりしたファイルがあったら, それについ て書いておいてください. もし diff の大きさが 20 KB 程度を 超えるようであれば, 圧縮したものを uuencode して下さい. そうでなければそのまま PR に入れるだけでいいです. 繰り返しになりますが, ports の変更を送るときには, &man.shar.1; ではなく &man.diff.1; を使用してください. やっていいことといけないこと この節では, ソフトウェアをportする上でよくある落し穴などにつ いて説明します. このリストを使って, あなた自身が作成した port のチェックはもとより, PR データベースにある, 他の人が作成した port のチェックもできます. あなたがチェックした port について のコメントを バグ報告と一般的な論評 にしたがって, 送ってください. PR データベースにある port を チェックすることによって, 私達がそれらを commit するのを早くし, あなたが何をしているか理解していることも示します. バイナリのstrip バイナリは strip してください. オリジナルのソースがバイナリを strip してくれる場合は良いですが, そうでない場合には post-install ターゲットを指定して strip するようにするとよいでしょう. 例えば, こんな風になります: post-install: strip ${PREFIX}/bin/xdl インストールされた実行形式がすでに strip されているかどうかは file コマンドで確認できます. これが`not stripped'と言わなければ, stripされているということです. <makevar>INSTALL_*</makevar> マクロ あなた自身の *-install ターゲットでファイルの正しいモードと オーナを保証するために, 必ずbsd.port.mkで提供されて いるマクロを使用してください. マクロは以下のようなものがあります. ${INSTALL_PROGRAM} は実行可能なバイナリを インストールするコマンドです. ${INSTALL_SCRIPT} は実行可能なスクリプトを インストールするコマンドです. ${INSTALL_DATA} は共有可能なデータを インストールするコマンドです. ${INSTALL_MAN} はマニュアルとその他のドキュメ ントをインストールするコマンドです. (圧縮はしません) これらは基本的に install コマンドに適当なフラグを与え たものです. どのようにこれらを使用するかは以下の例を見てください. <makevar>WRKDIR</makevar> WKRDIR の外のファイルにはなにも書き込まないように してください. WRKDIR は ports のビルド中に書き込こめる ことが保証されている唯一の場所です( CDROM から ports をコンパイルを参照). PKGDIR にあるファイルを修正する必要がある ときには, 変数の再定義 によって行ない, 上書きはしないでください. <makevar>WRKDIRPREFIX</makevar> WRKDIRPREFIX を尊重していることを確認してください. 特に, 別の port の WRKDIR を参照している ときには気を付けてください. 正しい場所は, WRKDIRPREFIX PORTSDIR /subdir/ name/work, です, PORTSDIR/subdir/ name/work とか .CURDIR/../../subdir /name/work とかではありません. また, 自分で WRKDIR 定義するときには, 頭に ${WRKDIRPREFIX}${.CURDIR} が付いている 事を確認してください. OS や OS のバージョンの区別 Port の過程で, 修正や, どのバージョンの UNIX で動くかによる条件つきコンパイルなどが 必要なコードに出会うかもしれません. そのような条件つきコンパイルなどのための 変更をおこなうときには, FreeBSD 1.x システムへの移植や, CSRGの4.4BSD, BSD/386, 386BSD, NetBSD, OpenBSD などの他のBSDシステムへの移植が可能なように, できるだけ普遍的な変更をおこなうことを 心がけてください. 4.3BSD/Reno (1990) およびそれより新しい BSD 版を古いバージョンと区別するには BSD マクロを利用するのがよいでしょう. これは <sys/param.h> で定義されています. このファイルがすでにインクルードされていればよいのですが, もしそうでない場合には以下のコードを, その .c ファイルの適当な場所に加えてください. #if (defined(__unix__) || defined(unix)) && !defined(USG) #include <sys/param.h> #endif これらの 2 つのシンボルが定義されているすべてのシステムには sys/param.h があるはずです. もし, そうでないシステムを発見したら我々にも教えてください. &a.ports; までメールを送ってください. あるいは, GNU の Autoconf のスタイルを使用することもできます, #ifdef HAVE_SYS_PARAM_H #include <sys/param.h> #endif この方法を使用するときには, Makefile 中の CFLAGSに -DHAVE_SYS_PARAM_H を加えることを忘れないようにしてください. いったん sys/param.h がインクルードされると, #if (defined(BSD) && (BSD >= 199103)) このようにしてそのコードが 4.3 Net2 コードベース, またはそれより新しいもの (例: FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1とそれ以前) の上でコンパイルされているかを検出できます. #if (defined(BSD) && (BSD >= 199306)) これは, 4.4コードベース, またはそれより新しいもの (例: FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0とそれ以後) の上でコンパイルされているかどうかを 検出するために使用します. 4.4BSD-Lite2 コードベースでは, BSD マクロの値は 199506 になっています. これは参考程度の意味合いしかありません. 4.4-Lite ベースの FreeBSD と 4.4-Lite2 での変更がマージされたバージョンとを 区別するのに使用するべきものではありません. この目的のためには, __FreeBSD__ マクロをかわりに使用してください. 以下は控え目に使ってください. __FreeBSD__ はFreeBSDのすべての版で定義されています. 変更が FreeBSD だけに適用されるとき以外は使用しないでください. Portでよくある, strerror() ではなく sys_errlist[] を使うなどは, FreeBSDでの変更ではなく, BSD の流儀です. FreeBSD 2.xでは __FreeBSD__ が 2 と定義されています. それ以前の版では 1 になっています. その後の版では, そのメジャー番号に合うように上がっていきます. もし, FreeBSD 1.x システムと FreeBSD 2.x あるいは FreeBSD 3.x システムを区別する必要があれば, 上で述べた BSDマクロを使用するのが, 大抵の場合において正しい答です. もし, FreeBSD特有の変更であれば (ld を使うときのシェアードライブラリ用のなオプションなど), __FreeBSD__を使い #if __FreeBSD__ > 1 のようにFreeBSD 2.x および, それ以降のシステムを検出するのはかまいません. もし, 2.0-RELEASE以降のFreeBSDシステムを細かく検出したけれ ば, 以下を使用することができます. #if __FreeBSD__ >= 2 #include <osreldate.h> # if __FreeBSD_version >= 199504 /* 2.0.5+ release specific code here */ # endif #endif Release - _FreeBSD_version + __FreeBSD_version 2.0-RELEASE 119411 2.1-CURRENT's 199501, 199503 2.0.5-RELEASE 199504 2.1 以前の 2.2-CURRENT 199508 2.1.0-RELEASE 199511 2.1.5 以前の 2.2-CURRENT 199512 2.1.5-RELEASE 199607 2.1.6 以前の 2.2-CURRENT 199608 2.1.6-RELEASE 199612 2.1.7-RELEASE 199612 2.2-RELEASE 220000 2.2.1-RELEASE 220000 (2.2-RELEASE と同じです) 2.2.1-RELEASE 以後の 2.2-STABLE 220000 (これも同じです) texinfo-3.9 以後の 2.2-STABLE 221001 top 導入以後の 2.2-STABLE 221002 2.2.2-RELEASE 222000 2.2.2-RELEASE 以後の 2.2-STABLE 222001 2.2.5-RELEASE 225000 2.2.5-RELEASE 以後の 2.2-STABLE 225001 ldconfig -R 以後の 2.2-STABLE 225002 2.2.6-RELEASE 226000 2.2.7-RELEASE 227000 2.2.7-RELEASE 以後の 2.2-STABLE 227001 semctl(2) 変更後の 2.2-STABLE 227002 2.2.8-RELEASE 228000 2.2.8-RELEASE 以後の 2.2-STABLE 228001 mount(2) 変更以前の 3.0-CURRENT 300000 mount(2) 変更以後の 3.0-CURRENT 300001 semctl(2) 変更以後の 3.0-CURRENT 300002 ioctl 引数変更後の 3.0-CURRENT 300003 ELF 移行後の 3.0-CURRENT 300004 3.0-RELEASE 300005 3.0-RELEASE 以後の 3.0-CURRENT 300006 3/4 の分岐後の 3.0-STABLE 300007 3.1-RELEASE 310000 3.1-RELEASE 以後の 3.1-STABLE 310001 3/4 の分岐後の 4.0-CURRENT 400000 (2.2-STABLE は, 2.2.5-RELESE 以後, “2.2.5-STABLE” と呼ばれることがあります.) 見ての通り, これは年・月というフォーマットになっていましたが, バージョン 2.2 から, より直接的にメジャー/マイナー番号を使う ように変更になりました. 並行していくつかのブランチ(枝分かれし たバージョン)を開発する場合には, リリースされた日付でそれらの リリースを分類することが不可能だからです. (あなたが今 port を作成するときに, 古い -CURRENT 達について心配 する必要はありません. これは参考のために挙げられているにすぎま せん.) これまで, 何百ものportが作られてきましたが, __FreeBSD__ が正しく使われたのは, 1つか2つの場合だけでしょう. 以前のportが誤った場所でそのマクロを使っているからと いって, それをまねする理由はありません. <filename>bsd.port.mk</filename> の後に書くこと .include <bsd.port.mk> の行の後には なにも書かないようにしてください. 大抵の場合は Makefile の 中程のどこかで, bsd.port.pre.mk を include して, 最後に bsd.port.pre.mk を include することによって避けることができます. pre.mk/post.mk のペアか bsd.port.mk だけのどちらかだけを include してください. 2つを混ぜないでください. 前者は, いくつかの変数の定義だけ をして, Makefile でのテストに使用し, 後者は残りを定義します. 以下は bsd.port.pre.mk で定義される重要な変数です. (これは, すべてではありません. 完全なリストは bsd.port.mk を参照してください.) 変数名 解説 ARCH uname -m で返される アーキテクチャ. (例, i386). OPSYS uname -s で返される オペレーティングシステム (例, FreeBSD). OSREL オペレーティングシステムの リリースバージョン (例., 2.1.5, 2.2.7). OSVERSION 数字形式のオペレーティングシステム のバージョン, 上記の __FreeBSD_version と同じです. PORTOBJFORMAT システムのオブジェクト フォーマット (aout あるいは elf). LOCALBASE “local” ツリーのベース. (例, /usr/local/). X11BASE “X11” ツリーのベース. (例, /usr/X11R6/). PREFIX portsのインストール先 ( PREFIXについてを参照). USE_IMAKE, USE_X_PREFIX あるいは MASTERDIR などの変数を定義する必要がある場合には, bsd.port.pre.mk を include する前に定義してください. 他のものは, bsd.port.pre.mk の前でも後でもかまいません. 以下は bsd.port.pre.mk の後に書けるものの例です: # no need to compile lang/perl5 if perl5 is already in system .if ${OSVERSION} > 300003 BROKEN= perl is in system .endif # only one shlib version number for ELF .if ${PORTOBJFORMAT} == "elf" TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR} .else TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR} .endif # software already makes link for ELF, but not for a.out post-install: .if ${PORTOBJFORMAT} == "aout" ${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so .endif 付加的ドキュメント 普通のマニュアルや info ファイルのほかにユーザにとって有用だ と思えるようなドキュメントがある場合には, PREFIX/share/doc の下にインストールしてく ださい. これは前記と同様, post-installターゲットの 中からするのがいいでしょう. まず, あなたのportのために新しいディレクトリを作りま す. どのportのドキュメントか簡単にわかるような名前にする必 要がありますので, 普通は PKGNAME からバージョ ン番号を除いた部分を使うといいでしょう. もちろん, ユーザが異 なるバージョンのものを同時に使うことが予想される port の場合 には, PKGNAME をそのまま使ってかまいません. ユーザが /etc/make.conf でこの部分を禁止するために NOPORTDOCS という変数をセットしている場合には， これらのドキュメントが インストールされないようにしてください. こんな具合です. post-install: .if !defined(NOPORTDOCS) ${MKDIR}${PREFIX}/share/doc/xv ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv .endif これらのファイルを pkg/PLIST に入れるのを忘れないよ うにしてください. (packageが/etc/make.conf内の 変数を読む方法は今のところ存在しませんので, NOPORTDOCS については気にしないでください.) インストール時に pkg/MESSAGE ファイルを利用して, メッセージを表示することができます. 詳細は pkg/MESSAGE を使う の節を参照してください. MESSAGE ファイルは pkg/PLIST に加える必要はありま せん. <makevar>DIST_SUBDIR</makevar> /usr/ports/distfiles ディレクトリ内をあまり散らかさ ないようにしてください. たくさんのファイルを取ってくるport や, 数は少なくてもほかのportのファイルと混同されるおそれが あるファイル (Makefile など) がある場合には, DIST_SUBDIR に port の名前 (PKGNAME からバージョン番号を取った部分を 使うといいでしょう) を入れてください. すると, DISTDIRがデフォルトの /usr/ports/distfiles から /usr/ports/distfiles/DIST_SUBDIR に変更され, 取ってきたファイルはすべてそのサブディレクトリの中に置か れるようになります. また, ファイルを取ってくるときにバックアップサイトとして使わ れる ftp.freebsd.org のディレクトリ名にもこの変数の 値が使われます. (DISTDIRを明示的に指定し た場合には, ローカルのファイルを置くところは変わりますが, こ のサイトのディレクトリ名は変わりませんので, 必ず DIST_SUBDIRを使うようにしてください.) この変数はMakefile中で明示的に指定された MASTER_SITES には影響しないことに注意して ください. RCS文字列 RCS が特別な意味を与えている文字列をパッチ内に入れないように してください. ファイルを私たちのソースツリーに入れる時にこれら の文字列はCVSによって書き換えられてしまい, あとでまたパッチ を使おうとした時にうまくいかないことがあります. RCS文字列は ドル記号 ($) で囲まれており, $Id や $RCS などで始まり ます. パッチ作成上の注意 diffの再帰 () フラグを使って再帰的なパッ チを作るのは大変結構なのですが, でき上がったパッチは必ず目で チェックして余計なゴミが入っていないことを確認してくださ い. よくあるのはバックアップファイル同士の変更点, あるいは Imake や GNU configure を使うソフトウェアの Makefile の変更点が入っている場合などです. また, configure.in を編集して, autoconf を使って configure を作り直す ときには, configure の diff は含めずに (それらは, 数千行になることもしばしばです), USE_AUTOCONF=yes を定義して, configure.in の diff をとってください. ファイルをまるごと消す場合にはパッチを使わずに post-extract ターゲットで消す方が簡単です. できあがった 差分に満足したら, それらをソースのファイルごとに別々の パッチファイルに分割してください. <makevar>PREFIX</makevar> なるべく port は PREFIX に対する相対パス にインストールすることができるように心がけてください. (この変数の値は USE_X_PREFIXか USE_IMAKEが指定してある時には X11BASE (デフォルト/usr/X11R6), そうでない場合にはLOCALBASE (デフォルト/usr/local) にセットされます.) サイトによってフリーソフトウェアが インストールされる場所が 違いますので, ソース内で /usr/local や /usr/X11R6 を明示的に書かないようにしてください. X のプログラムで imake を使うものについては, これは問題に はなりません. それ以外の場合には, ソース中のMakefileやスク リプトで /usr/local (imakeを使わないXのプログラ ムは /usr/X11R6) と書いてあるところを PREFIX に書き換えてください. この値は portのコンパイル, およびインストール時に自動的に環境変数として 下位makeに渡されます. USE_X_PREFIXは本当に必要な時 (つまり, X のライブラリなどとリンクしたり, X11BASE 以下にある ファイルを参照したりする必要がある時) 以外には設定しないでください. 変数 PREFIX の値は port の Makefile やユーザの環境で変更することもできます. しかし, 個々の port が Makefile でこの変数の値を明示的に設定することはなるべくしない でください. また, 他の port からインストールされるプログラムやファイル を指定するときには, 上で述べた変数を使用してください. 例えば, less のフルパスを PAGER というマクロに入れた い場合は, コンパイラに -DPAGER=\"/usr/local/bin/less\" と渡すかわりに -DPAGER=\"${PREFIX}/bin/less\" (Xを使うportの時は -DPAGER=\"${LOCALBASE}/bin/less\" ) を渡し てください. こうしておけば, `/usr/local' がまるごとどこか他 の場所に移してあるサイトでも, あなたのportがそのまま使える 可能性が高くなります. ディレクトリ構成 インストール時には PREFIX の正しいサブディ レクトリにファイルを置くように心がけてください. ソフトウェア によっては新しいディレクトリを 一つ作ってファイルを全部それに 入れてしまうものがありますが, それはよくありません. また, バ イナリ, ヘッダファイルとマニュアル以外のすべてを lib というディレクトリに入れてしまうportもあります が, これもBSD的なファイルシステム構成からいうと正しくありま せん. これは以下のように分散すべきです. etc にセッ トアップ/コンフィグレーションファイル, libexec に 内部で使用されるプログラム (コマンドラインから呼ばれることの ないコマンド), sbin に管理者用のコマンド, info に GNU Info 用のドキュメント, そして share にアーキテクチャに依存しないファイルが入り ます. 詳細については man &man.hier.7; を見てくださ い. /usrの構成方針はほとんどそのまま /usr/localにもあてはまります. USENET “ニュース”を 扱う ports は例外です. これらは, ファイルのインストール先として PREFIX/news を使用します. 空のディレクトリの除去 ports は デインストール(削除) の際には, 自分自身を消去したあとに, (ディレクトリの) 除去をするようにしてください. これは, 大抵の場合 @dirrm の行を ports が作成するすべてのディレクトリについて 加えることによって実現できます. 親ディレクトリは, 子ディレクトリを先に消さないと 消せないことに気をつけて下さい. : lib/X11/oneko/pixmaps/cat.xpm lib/X11/oneko/sounds/cat.au : @dirrm lib/X11/oneko/pixmals @dirrm lib/X11/oneko/sounds @dirrm lib/X11/oneko といった感じです. しかし, ときとして, 他の port をディレクトリを共有しているために @dirrm がエラーを返すことがあります. rmdir を @unexec から呼びだすことによって, 警告(warning)なしで 空のディレクトリのみを削除することができます: @unexec rmdir %D/share/doc/gimp 2>/dev/null || true これを使えば, たとえ, 他の port がファイルを インストールしていて, PREFIX/share/doc/gimp が空でない場合でも エラーメッセージは表示されませんし, pkg_delete が異常終了することもありません. UID もしあなたの portがインストールされるシステム上に特定のユー ザを必要とする場合は, pkg/INSTALL スクリプトから pw コマンドを実行して自動的にそのユーザを追加するよ うにしてください. net/cvsup-mirror の portが参考になるでしょう. もしあなたの port が, バイナリのパッケージとしてとして インストールされるときにも, コンパイルされたときと同じユーザー/グループ ID を使わなければならないのなら, 50 から 99 の間で空いている UID を選んで登録してください. japanese/Wnn の port が参考になるでしょう. 既にシステムや他の portで利用されている UIDを使わないように 十分注意してください. 現在の 50から 99までの間の UIDは以下の とおりです. majordom:*:54:54:Majordomo Pseudo User:/usr/local/majordomo:/nonexistent cyrus:*:60:60:the cyrus mail server:/nonexistent:/nonexistent gnats:*:61:1:GNATS database owner:/usr/local/share/gnats/gnats-db:/bin/sh uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67:X-10 daemon:/usr/local/xten:/nonexistent pop:*:68:6:Post Office Owner (popper):/nonexistent:/nonexistent wnn:*:69:7:Wnn:/nonexistent:/nonexistent ifmail:*:70:66:Ifmail user:/nonexistent:/nonexistent pgsql:*:70:70:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh ircd:*:72:72:IRCd hybrid:/nonexistent:/nonexistent alias:*:81:81:QMail user:/var/qmail/alias:/nonexistent qmaill:*:83:81:QMail user:/var/qmail:/nonexistent qmaild:*:82:81:QMail user:/var/qmail:/nonexistent qmailq:*:85:82:QMail user:/var/qmail:/nonexistent qmails:*:87:82:QMail user:/var/qmail:/nonexistent qmailp:*:84:81:QMail user:/var/qmail:/nonexistent qmailr:*:86:82:QMail user:/var/qmail:/nonexistent msql:*:87:87:mSQL-2 pseudo-user:/var/db/msqldb:/bin/sh このリストを最新の状態に保つためにも, この範囲の UID や GID を予約するような port を作ったり, 既存の port にそのような改変を行って我々に送るときには, UID の予約に関する注意書きをつけてください. 合理的な port Makefile は単純かつ適切であるべきです. もし, Makefile を数行短かくできたり, もっと読みやすくできるのであれば, そうしてください. 例えば, shell の if 構文を使う代りに, make の .if 構文を使う, EXTRACT* の再定義で代用できるのであれば, do-extract を再定義しない, CONFIGURE_ARGS += --prefix=${PREFIX} とするかわりに, GNU_CONFIGURE とする, などです. <makevar>CFLAGS</makevar> の尊重 CFLAGS 変数は尊重すべきです. その port がこれを無視するのであれば, NO_PACKAGE=ignores cflags を Makefile に加えてください. コンフィグレーション(設定)ファイル もしあなたの port が設定ファイルを PREFIX/etc に置く必要がある場合には, それを単純にインストールしたり, pkg/PLIST に加えてはいけません. こうしてしまうと, pkg_delete が ユーザが苦労して作ったファイルを消してしまったり, 新しく インストールすると上書きされてしまったりします. 代りに, 見本となるファイルを suffix ( filename.sample が良いでしょう) を付けて インストールして, message を表示して, ソフトウエアを動かす前に, ユーザがそのファイル をコピーして編集をしなければならないことを知らせましょう. Portlint 送付や commit をする前に portlint を使ってチェックしましょう. フィードバック Portを作るためにソフトウェアに変更を加えたら, なるべく原作者にその旨を伝えてパッチ等を送ってください. これらが次のリリースに取り入れられれば, アップグレードが楽になります. その他諸々 pkg/DESCR, pkg/COMMENT, pkg/PLIST などのファイルは, それぞれ2重にチェックしてください. 再検討してもっと良い記述があれば, それに置きかえてください. GNU General Public License (GNU一般公有使用許諾)のコピーは (すでにあるので)コピーしないでください, おねがいします. 法律に関することには, 十分注意をはらってください. 私達に法律に反するような形でソフトフェアの配布をさせない でください! 困ったら.... 私たちに質問を送る前に, 既存のportの例とbsd.port.mkを ちゃんと読んでください! ;) それでもわからないことがあったら, 一人で悩まないでどんどん 質問してください! :) <filename>Makefile</filename> のお手本 これはportの Makefile を作る際のお手本です. かぎかっこ ([])内のコメントは忘れずに取ってください. 変数の順番, 段落の間の空行など, Makefile を作るときはなるべくこ の形式にしたがってください. この形式は重要な情報が簡単に見つけられるように 設計されています. portlint を使って Makefile をチェックすることが 推奨されています. [ヘッダ -- どのようなportのMakefileかすぐにわかるようになっています] # New ports collection makefile for: xdvi # Version required: pl18 ["1.5alpha" みたいなのでも結構です] [この Makefile の最初の版が作成された日付です. この port をアップグ レードするときには変えないでください.] # Date created: 26 May 1995 [このソフトウェアを最初に FreeBSD に port した人の名前, つまり, この Makefile の最初の版を書いた人です. この port をアップグレー ドするとき, この行も変えないでください.] # Whom: Satoshi Asami <asami@FreeBSD.ORG> # # $Id$ [ ^^^^ この部分は, CVS ツリーに入れる時に自動的に RCS の ID 文字列に 置き換えられます.] # [Port自体, およびオリジナルのソースを取ってくるところを記述する部分. 最初は必ずDISTNAME, そして必要ならPKGNAME, CATEGORIES, 続いて MASTER_SITESがおかれ, さらに MASTER_SITE_SUBDIR がおかれることもあり ます. そのあと, EXTRACT_SUFX か DISTFILES を指定することも可能です] DISTNAME= xdvi PKGNAME= xdvi-pl18 CATEGORIES= print [MASTER_SITE_* マクロを使用しない場合は, 最後のスラッシュを忘れないように ("/")!] MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications [ソースファイルが標準の ".tar.gz" 形式でない時にこれを使いましょう] EXTRACT_SUFX= .tar.Z [配布パッチのセクション -- ない場合もあります] PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/ PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz [保守責任者 -- これは *必ず* 必要です. 担当者 (あなた) 自身, あるいは 担当者に素早く連絡をとれる人のアドレスを書いてください. どうしてもこ こに自分のアドレスを書くのがいやな人は "ports@FreeBSD.ORG" と書いて もいいです] MAINTAINER= asami@FreeBSD.ORG [依存するport -- ない場合もあります] RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript LIB_DEPENDS= Xpm.5:${PORTSDIR}/graphics/xpm [ここには標準のbsd.port.mkの変数で, 上のどれにもあてはまらないものを 書きます] [コンフィグレーション, コンパイル, インストールなどの時に質問をする なら...] IS_INTERACTIVE=yes [${DISTNAME}以外のディレクトリにソースが展開されるなら...] WRKSRC= ${WRKDIR}/xdvi-new [配布されているパッチが ${WRKSRC} に対する相対パスで作られてい い場合にこの変数の指定が必要かも...] PATCH_DIST_STRIP= -p1 [GNU autoconfによって生成された "configure" スクリプトを走らせたいなら...] GNU_CONFIGURE= yes [/usr/bin/makeでなく, GNU makeを使わないといけないなら...] USE_GMAKE= yes [これがXのアプリケーションで "xmkmf -a" を走らせたいなら...] USE_IMAKE= yes [などなど] [下の方のルールで使う非標準の変数] MY_FAVORITE_RESPONSE= "yeah, right" [そして, 特別なターゲット, 使用順に] pre-fetch: i go fetch something, yeah post-patch: i need to do something after patch, great pre-install: and then some more stuff before installing, wow [最後には必ず] .include <bsd.port.mk> Packageの名前 Package の名前は以下のルールにしたがってつけてください. こ れは package のディレクトリを見やすくするためで, 無秩序な名前 がたくさん並んでいるとユーザが使いづらくなるのでは という心配か らです. (FTPサイトなどにはたくさんpackageがありますからね.) Packageの名前は以下のようにしてください. 言語-名前-オプション バージョン.番号 DISTNAME が上記の形式になっていない場合に は, PKGNAME をそのようにしてください. FreeBSD はユーザの慣れ親しんだ言語のサポートに力を入れて います. 特定の言語のためのportのpackage名には 言語- に ISO-639 で定義されている言語名の略称を入れ てください. 例えば, 日本語なら ja, ロシア語なら ru, ベト ナム語なら vi, 中国語なら zh, 韓国語ならば ko, ドイツ 語なら de, といった具合です. 名前 の部分は原則的にはすべて英小文字 を使います. 例外はたくさんのプログラムが入っている巨大なport の場合で, XFree86 (ほんとにあるんですよ) やImageMagickな どがこれにあたります. そうでない場合には, 名前の大文字を小文 字に (少なくとも最初の一字だけは) 変えてください. もし, 大文字であることが重要な場合(例えば, 1文字の名前, R とか V)には, あなたの裁量で大文字を使うのも良いでしょう. Perl 5 のモジュールでは, 頭に p5- を付け, 2重コロン (::) のセパレータをハイフン( - ) に置きかえるしきたりになっています. 例えば, Data::Dumper は p5-Data-Dumper になります. また, その ソフトウェアの名前として通常使われるものに番号, ハイフン, あ るいは下線が入っている場合には, それらを使うことも構いません (kinput2 など). コンパイル時に環境変数や make の引数などで ハードコードされたデフォルト を変えてコンパイルできる場合, -compiled.specifics にそのコンパイル時のデフォルトを入れてください (ハイフンはあってもなくてもかまいません). 用紙のサイズ, あるいはフォントの解像度などがこれにあたります. バージョン番号は数字とアルファベットからなり, ピリオド (.) で区切ります. アルファベットは二文字以上続けてはいけませ ん. ただ一つの例外は「パッチレベル」を意味する pl で, それ 以外にバージョン番号が まったくついていない場合にのみ使うことがで きます. では, DISTNAMEを正しい PKGNAMEに直す例を見てみましょう: DISTNAME PKGNAME 理由 mule-2.2.2. mule-2.2.2 まったく問題なし XFree86-3.1.2 XFree86-3.1.2 同上 EmiClock-1.0.2 emiclock-1.0.2 プログラム一つだけの時は小文字のみ gmod1.4 gmod-1.4 `<名前>' のあとにハイフンが必要 xmris.4.0.2 xmris-4.0.2 同上 rdist-1.3alpha rdist-1.3a alphaのような文字列は使えない es-0.9-beta1 es-0.9b1 同上 v3.3beta021.src tiff-3.3 なんなんでしょう ;) tvtwm tvtwm-pl11 バージョン番号は必ず必要 piewm piewm-1.0 同上 xvgr-2.10pl1 xvgr-2.10.1 pl が使えるのは他にバージョン番号がない場合のみ gawk-2.15.6 ja-gawk-2.15.6 日本語バージョン psutils-1.13 psutils-letter-1.13 コンパイル時に用紙のサイズを指定 pkfonts pkfonts300-1.0 300dpiフォント用のpackage オリジナルのソースにまったくバージョン情報が見当たらず, また原作 者が新しいバージョンをリリースする可能性が低いときには, バージョ ン番号として 1.0 を使えばいいでしょう (上記のpiewmの例がこ れにあたります). そうでない場合には, 原作者に聞くか, 日付 ( 年.月 .日) を使うなどしてください. カテゴリ すでに御存知のように, ports はいくつかのカテゴリに 分類されています. これを有効に利用するためには, port を 行う人々とユーザが, そろぞれのカテゴリが何であるか, どのようにしてカテゴリに分類するかを理解する必要が あります. 現在のカテゴリのリスト まず, これが現在の port のカテゴリーのリストです. アスタリスク(*) が付いているものは, バーチャル(virtual) カテゴリです -- これらには対応するサブディレクトリが port ツリーにはありません. バーチャルカテゴリでないものは, そのサブディレクトリ内の pkg/COMMENT に1行の記述があります (例, archivers/pkg/COMMENT). Category Description afterstep* Ports to support AfterStep window manager archivers Archiving tools. astro Astronomical ports. audio Sound support. benchmarks Benchmarking utilities. biology Biology-related software. cad Computer aided design tools. chinese Chinese language support. comms Communication software. Mostly software to talk to your serial port. converters Character code converters. databases Databases. deskutils Things that used to be on the desktop before computers were invented. devel Development utilities. Do not put libraries here just because they are libraries—unless they truly don't belong to anywhere else, they shouldn't be in this category. editors General editors. Specialized editors go in the section for those tools (e.g., a mathematical-formula editor will go in math). elisp Emacs-lisp ports. emulators Emulators for other operating systems. Terminal emulators do not belong here—X-based ones should go to x11 and text-based ones to either comms or misc, depending on the exact functionality. games Games. german German language support. graphics Graphics utilities. japanese Japanese language support. kde* Ports that form the K Desktop Environment (kde). korean Korean language support. lang Programming languages. mail Mail software. math Numerical computation software and other utilities for mathematics. mbone MBone applications. misc Miscellaneous utilities—basically things that doesn't belong to anywhere else. This is the only category that should not appear with any other non-virtual category. If you have misc with something else in your CATEGORIES line, that means you can safely delete misc and just put the port in that other subdirectory! net Miscellaneous networking software. news USENET news software. offix* Ports from the OffiX suite. palm Software support for the 3Com Palm(tm) series. perl5* Ports that require perl version 5 to run. plan9* Various programs from Plan9. print Printing software. Desktop publishing tools (previewers, etc.) belong here too. python* Software written in python. russian Russian language support. security Security utilities. shells Command line shells. sysutils System utilities. tcl75* Ports that use tcl version 7.5 to run. tcl76* Ports that use tcl version 7.6 to run. tcl80* Ports that use tcl version 8.0 to run. tcl81* Ports that use tcl version 8.1 to run. textproc Text processing utilities. It does not include desktop publishing tools, which go to print/. tk41* Ports that use tk version 4.1 to run. tk42* Ports that use tk version 4.2 to run. tk80* Ports that use tk version 8.0 to run. tk81* Ports that use tk version 8.1 to run. vietnamese Vietnamese language support. windowmaker* Ports to support the WindowMaker window manager www Software related to the World Wide Web. HTML language support belong here too. x11 The X window system and friends. This category is only for software that directly support the window system. Do not put regular X applications here. If your port is an X application, define USE_XLIB (implied by USE_IMAKE) and put it in appropriate categories. Also, many of them go into other x11-* categories (see below). x11-clocks X11 clocks. x11-fm X11 file managers. x11-fonts X11 fonts and font utilities. x11-toolkits X11 toolkits. x11-wm X11 window managers. 適切なカテゴリの選択 多くのカテゴリに重なるので, どれを '第一' カテゴリにするかを決めなければならないことが たびたびあるでしょう. これを うまく決めるルールがいくつかあります. 以下はその優先順のリストで, 優先度の高いものから 低いものの順に書いてあります. 言語特有のカテゴリがまず最初です. 例えば日本語の X11 のフォントをインストールする port の場合, CATEGORIES 行は japanese x11-fonts となるでしょう. より特徴的なカテゴリが, 一般的なカテゴリより 優先されます. 例えば, HTML エディタの場合は www editors となり, 逆順にはしないでください. また, port が mail, mbone, news, security, www のいづれかに属するとには, net は必要ありません. x11 を第2カテゴリにするのは, 第1カテゴリが自然言語の場合のみにしてください. 特に X のアプリケーションには x11 を指定しないでください. もし, あなたの port が他のどのカテゴリにも 属しないばあいには, misc にしてください. もし, あなたがカテゴリについて自信が持てない場合には, そのことを send-pr するときに 書き加えてください. そうすれば import するまえに それについて議論できます. (もしあなたが commiter であれば, そのことを &a.ports に送って, 先に議論 するようにしてください — 新しい port が間違ったカテゴリに import されて, すぐ移動されることが多いので.) このドキュメントと ports システムの変更 もしあなたが, たくさんの ports の保守を しているのであれば, &a.ports メーリングリストの内容を フォロウすることを考えてください. Ports のしくみについての重要な変更点はここに アナウンスされます. 最新の変更点については, いつでも, the bsd.port.mk CVS log で詳細な情報を得ることができます. + url="http://www.FreeBSD.ORG/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk"> the bsd.port.mk CVS log で詳細な情報を得ることができます. やっとおしまい! いやはや, 長い文章ですみません. ここまで読んでくださった方に は感謝, 感謝でございます. (_ _) さあ, portの作り方がわかったところで, 世界中のソフトウェア をport化しましょう. FreeBSDプロジェクトに貢献するには, それ がもっとも簡単な方法です! :) diff --git a/ja_JP.eucJP/books/porters-handbook/book.sgml b/ja_JP.eucJP/books/porters-handbook/book.sgml index a36d1c49eb..f27bce571b 100644 --- a/ja_JP.eucJP/books/porters-handbook/book.sgml +++ b/ja_JP.eucJP/books/porters-handbook/book.sgml @@ -1,5231 +1,5233 @@ アプリケーションのインストール : ports コレクション 原作: &a.jraynard;. 訳: &a.jp.masaki;, &a.jp.saeki;. 11 November 1996. FreeBSD の ports コレクションを利用すると, 最小限の労力で 非常に幅広くのアプリケーションのコンパイルとインストールがおこなえます. やってみたことのある方はよくご存知でしょうが, オープンな規格とは 全くの誇大広告であって, あるプログラムを異なるバージョンの Unix 上で 動作させることは退屈で手間のかかる仕事です. 求めているプログラムが自分のシステムでうまくコンパイルでき, 正しいところにインストールできて, 完璧に動作するとしたらとてもラッキーです. しかし, あいにくこれは滅多にないことなのです. ほとんどのプログラムについて, あなたは髪を掻きむしることになるでしょうし, かなりのプログラムでは, 白髪混じりの頭になってしまったり, あるいは慢性の 脱毛症にすら なってしまうかもしれません... いくつかのソフトウェアディストリビューションでは, 設定用のスクリプトを 配布することでこの問題を解決しようとしています. これらのスクリプトの中には非常に精巧なものもありますが, 残念ながら, 中にはこれまで 聞いたこともないようなシステムの名前をしゃあしゃあと 言い放ったうえに, まるでシステムレベルの Unix プログラミングに関する 最終試験のような, たくさんの質問をしてくる場合があります. (例えば, このシステムの gethitlist 関数は fromboz への const ポインタを 返しますか? それとも const fromboz へのポインタを返しますか?, このシステムには Foonix スタイルの, 容認できない例外処理をおこなう ルーチンがありますか? もしもないとしたら, それはなぜですか?) 幸いなことに, ports コレクションがあれば, これらのきつい作業はすべて 完了しています. make install とタイプするだけで, 動作するプログラムを 入手することができるのです. なぜ ports コレクションを作ったのか? FreeBSD の基本システムは, 非常に多くのツールやユーティリティから 構成されています. しかし, よく使われるプログラムのうち多くのものが, この基本システムには含まれていません. その理由は:- ある Lisp ベースのエディタのように, それがないと生きていけないと 言う人もいれば, ディスクの無駄だと言う人もいるようなプログラム. 基本システムに組み込むには特殊すぎるプログラム. (CAD やデータベースなど.) “時間のある時に, ちょっと見ておかなければ”というような類の, それがシステムに含まれていないことが 致命的とは言えないプログラム. (おそらく, 何らかの言語などでしょう.) FreeBSD のような真面目なオペレーティングシステムの一部として 供給するには遊びが過ぎるようなプログラム. ;-) たくさんのプログラムを基本システムに組み込んだとしても, もっともっと 組み込みたいという要求が出てくるので, どこかで制限を引かなくてはならないため. (そうしなければ FreeBSD の配布物は, とてつもなく膨大になってしまうでしょう.) すべての人が自分のお気に入りの プログラムを手作業で移植しなければ ならないとしたら, (途方もない膨大な作業の繰り返しをさておいたとしても) それは明らかに不合理な話です. そこで, FreeBSD プロジェクトでは, 標準のツールを使って移植のプロセスを 自動化する巧妙な方法を考え出しました. なお, これは単純ながら非常に柔軟なツールを組み合わせることで, 非常に強力な働きをさせるという“Unix 流”の作業の優れた実例です. ports コレクションはどのように動くのでしょうか? インターネットでは通常, tarball の形で プログラムが配布されています. これは, Makefile とソースコードで構成され, 普通は何らかの説明書 (あいにく, いつもわかりやすく書かれているとは 限りませんが) が付属しています. ことによるとコンフィグレーションスクリプトも 含まれているかもしれません. 標準的な手順では, FTP で tarball を入手して, 適当なディレクトリで展開します. 次に説明書を読んで, 必要な変更をおこないます. そして, 設定スクリプトを実行し, 標準の make コマンドを使ってソースのコンパイルとインストールを おこないます. FreeBSD の ports も tarball の仕組みを利用していますが, これはユーザが 苦労して作業することを期待したものではなく, どのようにすれば FreeBSD 上で そのプログラムが動くようになるかという「ノウハウ」を スケルトン を使用して収めているものです. スケルトンは, カスタマイズ済みの Makefile も 提供していますので, ほとんどすべての ports は同じ手順でインストールすることが できます. もしあなたが (あなたの FreeBSD システム または FTP サイト にある) ports スケルトンを見ていて, そこに潜んでいる あらゆる種類の先端的な ロケット工学的なものを見つけられると期待していると, つまらなそうなファイルやディレクトリがそこにあるだけなのを見て, がっかりするかもしれません. (ports を手に入れる方法については, すぐに FreeBSD ports コレクションの入手方法 の節でお話します.) “一体どうしたらいいんだ? ここにはソースコードが ないじゃないか?” というあなたの叫びが聞こえるようです. 心配いりません. おとなしく読んでいけば, すべてが (たぶん) 明らかに なるでしょう. 試しに ports をインストールして, 何が起きるのかを見てみましょう. ここではサンプルとして開発者向けの便利なツール, ElectricFence を選択します. このスケルトンを選んだ理由は, 他の ports に比べても素直で理解しやすく 書かれているからです. 自宅で試してみる場合には, root になる必要があるでしょう. &prompt.root; cd /usr/ports/devel/ElectricFence &prompt.root; make install >> Checksum OK for ElectricFence-2.0.5.tar.gz. ===> Extracting for ElectricFence-2.0.5 ===> Patching for ElectricFence-2.0.5 ===> Applying FreeBSD patches for ElectricFence-2.0.5 ===> Configuring for ElectricFence-2.0.5 ===> Building for ElectricFence-2.0.5 [大量のメッセージをコンパイラが出力します...] ===> Installing for ElectricFence-2.0.5 ===> Warning: your umask is "0002". If this is not desired, set it to an appropriate value and install this port again by ``make reinstall''. install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.a /usr/local/lib install -c -o bin -g bin -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.3 /usr/local/man/man3 ===> Compressing manual pages for ElectricFence-2.0.5 ===> Registering installation for ElectricFence-2.0.5 ここではあなたが混乱しないように, コンパイル時の出力を すべて取り除いてあります. もしもあなた自身で実行されたら, 最初にこのような 出力結果が得られるはずです:- &prompt.root; make install >> ElectricFence-2.0.5.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://ftp.doc.ic.ac.uk/Mirrors/sunsite.unc.edu/pub/Linux/devel/lang/c/. make プログラムは, あなたの手元にソースコードがないことを検出し, 処理を続けられるようにソースを FTP でダウンロードしようとします. この例では, あらかじめ手動でソースコードを用意してあったので, 持ってくる必要はありませんでした. では, 続けて make プログラムが何をしているのか見てみましょう. ソースコード tarball のありかを 確認します. 手元にファイルが存在しなければ, FTP サイトから入手しようとします. チェックサム テストを実行して, その tarball が事故か何かで途中で切れていたり, ASCII モードで ダウンロードされていたり, 転送中にニュートリノによって傷められたりして 改変されたりしていないかどうかを確認します. tarball を一時的な作業用ディレクトリに展開します. FreeBSD 上でコンパイルしたり, 動作させるのに必要な すべての パッチ をソースコードに当てます. 構築のために必要な コンフィグレーションスクリプトを実行します. コンフィグレーションスクリプトの 質問には正確に答えてください. (いよいよ!) ソースコードをコンパイルします. 実行形式のプログラム, マニュアル, その他のサポートファイルを, システムのプログラムと混ざってしまわないように /usr/local 以下に インストールします. ports はすべて同じ場所にインストールされ, システムのあちこちにばらまかれることはありません. インストール結果はデータベースに登録されます. これにより, インストールしたプログラムがもしも気に入らなかったときも, システムから すべての痕跡をきれいに 消去 することができます. 以上のステップが make の出力と一致しているかどうか確認してください. 今まで確認していなかったのなら, 今からするようにしてください! FreeBSD ports コレクションの入手 あるプログラムの FreeBSD port を入手するには二つの方法があります. ひとつは FreeBSD CD-ROM を使う方法で, もうひとつは インターネット接続 を使う方法です. CD-ROM からコンパイルする FreeBSD CD-ROM がドライブに入っており, /cdrom にマウントされていると仮定すると (マウントポイントが /cdrom である必要があります), ただ普通に実行するだけで ports を構築できるようになり, tarball をネットワーク経由でダウンロードするのではなく /cdrom/ports/distfiles/ からさがすようになります (そこにあればの話ですが). CD-ROM にある port スケルトンを使いたければ, 他に /etc/make.conf の 変数を以下のようにセットする方法があります: PORTSDIR= /cdrom/ports DISTDIR= /tmp/distfiles WRKDIRPREFIX= /tmp (任意の十分な空きスペースの場所を /tmp とおいています). 次に, /cdrom/ports 下の適宜のサブディレクトリに cd して, 例のごとく make install とタイプします. WRKDIRPREFIX は port に /tmp/cdrom/ports の下でビルドさせようとします; 例えば, games/oneko は /tmp/cdrom/ports/games/oneko の下で ビルドされるでしょう. ライセンスの制限により, いくつかの ports でオリジナルのソースコードを CD-ROM に入れることができなかったものがあることに注意してください. この場合, インターネット経由で ports をコンパイルする の 節を参照してください. インターネット経由で ports をコンパイルする CD-ROM を持っていなかったり, その ports の最新バージョンを確実に入手したい 場合は, その ports の スケルトン を ダウンロードする必要があります. ところで, これは落し穴が たくさんある作業に見えるかもしれませんが, 実際には非常に簡単です. 初めに, あなたの動かしている FreeBSD がリリースバージョンなら ports ページ でその FreeBSD 用の “アップグレードキット” を手にいれてください. このパッケージには, 最新の ports をコンパイルするのに必要な, リリース以降に更新されたファイルが含まれています. FreeBSD の FTP サーバーがその場で tarball を作成できることを利用してスケルトンを入手すると 非常に便利です. ここでは例として databases ディレクトリにある gnats プログラムを使って説明します. (角型かっこの中の文はコメントなので, 実際に実行する場合には, これをタイプしないでください!):- &prompt.root; cd /usr/ports &prompt.root; mkdir databases &prompt.root; cd databases &prompt.root; ftp ftp.freebsd.org [ユーザ名 `ftp' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] > cd /pub/FreeBSD/ports/ports/databases > get gnats.tar [gnats スケルトンの tarballs を取得] > quit &prompt.root; tar xf gnats.tar [gnats スケルトンの展開] &prompt.root; cd gnats &prompt.root; make install [gnats の構築とインストール] さて何が起きるでしょうか? FTP サイトにいつも通りに接続して, データベースの サブディレクトリに移動します. get gnats.tar とコマンドを入力すると, FTP サイトでは gnats ディレクトリを tarred にしてくれるのです. gnats スケルトンを展開したら, gnats ディレクトリへ移動して ports を構築します. すでに 説明したように, make の過程で 手元にソースコードがないことを検出すると, ソースコードを取得してから 展開し, パッチ当てと構築をおこないます. それでは, 少し冒険をしてみましょう. 一つの ports スケルトンを 取得するかわりに, たとえば ports コレクションの中のデータベースの スケルトンをすべて, サブディレクトリ全体を取得してみましょう. やり方はほとんど同じです:- &prompt.root; cd /usr/ports &prompt.root; ftp ftp.freebsd.org [ユーザ名 `ftp' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] > cd /pub/FreeBSD/ports/ports > get databases.tar [データベースディレクトリの tarballs を取得] > quit &prompt.root; tar xf databases.tar [すべてのスケルトンを展開] &prompt.root; cd databases &prompt.root; make install [データベース ports 全部の構築とインストール] わずかばかりの簡単なコマンドで, この FreeBSD マシン上にデータベース プログラムを一揃い手に入れてしまいました! 一つの ports スケルトンを取ってきて それを構築する場合との違いは, すべてのディレクトリを一度に取得して, 全部を一度にコンパイルしたということだけです. かなり感動的だと思いませんか? たくさんの ports をインストールする つもりなら, おそらくすべての ports ディレクトリをダウンロードしておく 価値があるでしょう. スケルトン スケルトン (訳注: skeleton とは骸骨のことです) とは, 締め切りを守るため, 食事をするのを忘れるほど仕事にのめり込んだ ハッカーたちのなれの果ての ことでしょうか? FreeBSD の屋根裏に潜む, なにか気持ちの悪いものでしょうか? いいえ, ここでスケルトンの意味するところは, ports の魔術を実現するのに 必要とされるすべてのものを提供する最小の骨組みのことです. <filename>Makefile</filename> スケルトンのもっとも重要な要素は Makefile です. Makefile は ports を どのようにコンパイルし, インストールをおこなうかを指示する いろいろな命令を含んでいます. 以下に ElectricFence の Makefile を示します:- # New ports collection makefile for: Electric Fence # Version required: 2.0.5 # Date created: 13 November 1997 # Whom: jraynard # # $Id$ # DISTNAME= ElectricFence-2.0.5 CATEGORIES= devel MASTER_SITES= ${MASTER_SITE_SUNSITE} MASTER_SITE_SUBDIR= devel/lang/c MAINTAINER= jraynard@freebsd.org MAN3= libefence.3 do-install: ${INSTALL_DATA} ${WRKSRC}/libefence.a ${PREFIX}/lib ${INSTALL_MAN} ${WRKSRC}/libefence.3 ${PREFIX}/man/man3 .include <bsd.port.mk> "#" で始まる行は, 人間のためのコメント行です. (ほとんどの Unix のスクリプトと同じですね.) DISTNAME は tarball の名前から拡張子を取ったものです. CATEGORIES はこのプログラムの種類を示します. この場合, 開発者向けのユーティリティということになります. 完全なリストはこのハンドブックの カテゴリ をみてください. MASTER_SITES はマスタ FTP サイトの URL です. もしローカルシステムに tarball がない場合には, ここから取得します. これは信頼できると考えられているサイトで, 通常はそのプログラムを インターネット上で公式に配布しているサイトです. (そのソフトウェアがインターネット上で「公式に」 配布されているとしたら) MAINTAINER は, 例えば新しいバージョンのプログラムが出た場合に, 必要であれば スケルトンの更新をおこなう保守担当者の 電子メールアドレスです. 次の数行はとりあえず飛ばします. .include <bsd.port.mk> この行は, この ports に必要なその他の命令やコマンドは bsd.port.mk に 入っているということを示しています. これらはすべての ports で共通のものなので, それぞれの Makefile に書いておく必要はありません. そのため単一の標準ファイルに まとめられているのです. ここでは Makefile がどう働くかを詳細に調査するのが目的ではありませんので, MAN3 で始まる行は, インストールの後に ElectricFence のマニュアルを 圧縮するために使用される, と言っておくだけで充分でしょう. これにより, 貴重なディスクスペースが保護されているわけです. オリジナルの port では install ターゲットが用意されていないので, do-install からの 3 行が この ports によって生成されたファイルを 正しい場所に置くために使用されます. <filename>files</filename> ディレクトリ ports のチェックサム算出には MD5 アルゴリズムを使用しているので, この チェックサム を含んでいる ファイルは md5 と呼ばれます. ちょっと混乱するかもしれませんが, このファイルは files という 名前のディレクトリに置かれています. このディレクトリは, ports に必要だけれども, 他のどこにも属さない 雑多なファイルも含んでいます. <filename>patches</filename> ディレクトリ このディレクトリには, FreeBSD ですべてを正常に動作させるのに 必要な パッチ が含まれています. <filename>pkg</filename> ディレクトリ このディレクトリには, 非常に役立つ三つのファイルが含まれています:- COMMENT — プログラムについての 1 行の説明. DESCR — より詳細な説明. PLIST — プログラムのインストール時に作成される, すべてのファイルのリスト. ports が動かないのですが, どうしたらよいでしょう おやおや. では, 次の四つのどれかをやってみてください: 自分で修正する. ports の仕組みに関する技術的な詳細については, アプリケーションの移殖方法をご覧ください. 苦情をいう. これは電子メールで だけ にしてください! このようなメールの宛先は &a.ports; です. なお, 必ず port の名前やバージョン, その port のソースや distfile(s) を どこから入手したか, どんなエラーが発生したのかを書いておいてください. 忘れてしまう. これはほとんどの場合最も簡単な方法です. ports のプログラムのうち必要不可欠な物はごくわずかです. FTP サイトからコンパイル済みのパッケージを入手する. “マスター”パッケージコレクションは FreeBSD の FTP サイトの パッケージディレクトリ に置いてありますが, まずあなたの近くのローカルミラーサイトを確認してください! ソースからのコンパイルに挑戦するよりも, パッケージを使うほうが (全体的に見て) ずっと確実に動作するでしょうし, より手っ取り早い方法でもあります. システムにパッケージをインストールするには, &man.pkg.add.1; を使ってください. 質問と回答集 Q. 私はモデムについての議論を しているのかと思っていました??! A.なるほど, あなたはきっとコンピュータの背面についている シリアルポートのことだと思ってしまったのでしょう. あるバージョンの Unixから別のバージョンの Unix へとプログラムを 移殖することを “porting” というのですが, ここで我たちは “porting” の結果 という意味で “port” を使っています. (コンピュータに関わる人々の悪しき習慣として, ひとつの同じ言葉を複数の まったく違う意味として使うことがあるのです.) Q. 私は, 標準以外のプログラムのインストールには packages を使うと 思っていたのですが. A. そのとおり. 通常は packages が最も手早くて簡単な方法です. Q. それではどうして面倒な ports があるのですか? A. いくつかの理由があります:- いくつかのソフトウェアのライセンス条件には, バイナリではなくソースコードでの 配布を求めているものがあります. バイナリ配布を信用していない人もいます. 少なくともソースコード があれば, ソースコードを読んで, (理論的には) 潜在的な問題点を自分で 見つけ出すこともできるはずです. ローカルなパッチを入手した場合, それを自分で追加するために ソースコードが必要になります. プログラムがいかにコンパイルされるべきかについて, あなたはパッケージを作った人とは 異なる見解を持っているかもしれません. どんな最適化オプションをつけるべきかとか, デバッグバージョンを作ってから それを strip するべきだとか, いや, そうするべきでない, などなど, 確固たる見解を持っている人もいるでしょう. ソースコードを手元に置いておきたい人たちもいます. 彼らは, 退屈したときに眺めたり, あちこち解析してみたり, ソースコードを 借用したり (もちろん, ライセンスが許せばの話ですが) するのです. あなたがソースコードを持っていなければ, それはソフトウェアとは 言えませんね! ;-) Q. パッチとは何ですか? A. パッチとは, あるバージョンから他のバージョンへどのように変更するかを 示す, (通常は) 小さなファイルです. “23 行目を削除”, “468 行目の後に これらの 2 行を追加”, または“197 行目をこのように変更”というような 内容を含んでいます. これは, “diff” という名前のプログラムで生成されます. Q. tarball とは一体何ですか? A. .tar または .tar.gz という拡張子を持つファイルです. (.tar.Z のようなバリエーションも ありますし, DOS のファイルシステム用に .tgz と短縮される場合もあります.) これは基本的に, 一つのファイルに固めた (.tar) ディレクトリツリーです. 圧縮されている (.gz) 場合もあります. これは元々 Tape ARchives (訳注: テープアーカイブ) (このため tar という名前なのです) で使われていたものなのですが, インターネット上でプログラムのソースコードを配布するために 広く使われている方法です. これらのファイルの中身を見たり, 展開したりすることもできます. FreeBSD の基本システムに付属する Unix 標準の tar コマンドを使ってみると 次のようになります:- &prompt.user; tar tvzf foobar.tar.gz &prompt.user; tar xzvf foobar.tar.gz &prompt.user; tar tvf foobar.tar &prompt.user; tar xvf foobar.tar Q. チェックサムとは何ですか? A. これは, チェックしたいファイル中のすべてのデータを加えて生成した 数値です. 何か文字が書き換わっていたら, チェックサムが一致しなくなります. そのため, 単純な比較だけで違いを見つけることができるのです. (実際には, 文字の位置が入れ替わるなどの, 単純な加算ではわからない問題も 見つけることができる複雑な方法で計算されています.) Q. 私は, CD-ROM から ports をコンパイルする にしたがって ports をインストールしていました. kermit をインストールしようとするまではうまくいっていました:- &prompt.root; make install >> cku190.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://kermit.columbia.edu/kermit/archives/. なぜ cku190.tar.gz が見つからないのでしょうか? 不良品の CD-ROM を買ってしまったのでしょうか? A. Kermit の権利を持つチームは, 私たちの CDROM に kermit の tarball を 入れることを許可しませんでした. 申し分けありませんが, 手動でファイルを 入手してください. このようなエラーメッセージが出たのは, あなたがそのときインターネットに 接続していなかったためです. あらかじめ上記のサイトのいずれかからファイルを ダウンロードしておけば, プロセスを再開することができます. (ダウンロードの際には, あなたに最も近いサイトを選ぶようにしてください. そうすれば, 時間とインターネットの帯域の節約になります) Q. kermit の tarball を入手しましたが, /usr/ports/distfiles に ファイルを置こうとすると, 書き込み権がないというエラーがでます. A. ports のしくみは /usr/ports/distfiles から tarball を探します. しかし, これは read-only の CD-ROM へのシンボリックリンクなので, ここにファイルを置くことはできません. 次のようにすれば, 他の場所を探すよう ports に指示することができます. - &prompt.root; make DISTDIR=/where/you/put/it install + &prompt.root; make DISTDIR=/where/you/put/it install Q. ports では, すべてを /usr/ports に置いたときだけ動作するのでしょうか? システムの管理者によると, 私の個人的なファイルは /u/people/guests/wurzburger に入れなければならないのですが, これでは うまくいかないように思います. A. PORTSDIR 変数と PREFIX 変数を変更することで, 違うディレクトリを 使用することができます. 例えば, &prompt.root; make PORTSDIR=/u/people/guests/wurzburger/ports install とすると, ports は /u/people/guests/wurzburger/ports でコンパイルされ, すべて /usr/local 以下にインストールされます. &prompt.root; make PREFIX=/u/people/guests/wurzburger/local install この場合, コンパイルは /usr/ports でおこない, /u/people/guests/wurzburger/local にインストールします. もちろん, 以下のように両者を組み合わせることも可能です. &prompt.root; make PORTSDIR=.../ports PREFIX=.../local install (省略せずに記述したら, このページに収めるには長すぎるのですが, 考え方は理解していただけたと思います) もし ports をインストールするたびに, これらを毎回タイプするのが 気に入らないのであれば, (正直に言って, 誰もそう思わないでしょう) これらを環境変数にセットしてしまうという手があります. Q. 私は, FreeBSD の CD-ROM を持っていませんが, 私はすべての tarball を 私のシステムに置いておきたいのです. そうすれば, 私は ports をインストール するたびに, 毎回ダウンロードが終わるのを待たなくてすむでしょう. これを一度におこなう簡単な方法はありませんか? A. ports コレクション全体の tarball を持ってくるには, 次のようにしてください. &prompt.root; cd /usr/ports &prompt.root; make fetch ports の下のディレクトリひとつの tarball を持ってくるには, 次のように してください. - &prompt.root; cd /usr/ports/directory + &prompt.root; cd /usr/ports/directory &prompt.root; make fetch ports をひとつだけ持ってくる方法は, きっと既にご存知だと思います. Q. マスタ FTP サイトから tarball を持ってくるより, 近くにある FreeBSD の ミラーサイトから持ってきた方が速いはずです. MASTER_SITES に書かれている サイト以外から持ってくるように ports に指示する方法はありませんか? A. もちろんあります. 例えば ftp.FreeBSD.ORG が MASTER_SITES に書かれている サイトより近いとしたら, 以下のようにしてください. - &prompt.root; cd /usr/ports/directory + &prompt.root; cd /usr/ports/directory &prompt.root; make MASTER_SITE_OVERRIDE=ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/distfiles/ fetch Q. ダウンロードをする前に, どんなファイルが必要なのか知りたいのですが. A. make fetch-list とすると, ports に必要なファイルの一覧を表示できます. Q. ports のコンパイルを途中で止める方法はありますか? 私はインストールをする前に いろいろとソースコードを解析したいのですが, 毎回 control-C を打たなければならないのが少し面倒です. A. make extract を実行すると, ファイル転送とソースコードの展開まで おこなったところで停止します. Q. 自分で ports を作ろうとしています. 私の作ったパッチが 正しく処理できることを確認できるように, コンパイルを止めたいのです. パッチのための make extract のようなものはありませんか? A. あります. make patch があなたのお望みのものです. おそらく PATCH_DEBUG オプションも同様に お役に立つことでしょう. ところで, あなたの努力に感謝いたします!! Q. あるコンパイルオプションはバグの 原因になるという話を聞きました. 本当なのでしょうか? どうやったら正しい設定で ports をコンパイルできますか? A. 本当です. gcc の バージョン 2.6.3 (FreeBSDの 2.1.0 と 2.1.5 に付属している バージョン) では, オプションを オプションなしで 使うと, バグのあるコードを出力します (ほとんどの ports は オプションを 使いません). コンバイラオプションは次のように定義 すべき です. &prompt.root; make CFLAGS='-O2 -fno-strength-reduce' install これを /etc/make.conf に書いておくこともできますが, 残念なことに すべての ports がこの指定を尊重してくれる 訳ではありません. もっとも確実なのは make configure を実行し, ソースディレクトリの Makefile を見て手で修整することですが, ソースが 多くのサブディレクトリにわかれていて, 各々に Makefile がある場合は 大変な仕事になります. Q. ports がたくさんありすぎて, 私の欲しいものがなかなか見つけられません. どんな ports が使えるのか, リストはどこかにありませんか? A. /usr/ports の中にある INDEX ファイルを見てみましょう. あるキーワードで ports コレクションを検索したければ, それも可能です. たとえば, 以下のようにすればプログラミング言語 LISP に関連した ports を見つけることができます: &prompt.user; cd /usr/ports &prompt.user; make search key=lisp Q. foo ports をインストールしたいのですが, それのコンパイルは すぐに停止して, bar ports のコンパイルが始まってしまいます. 一体どうして? A. foo ports が, bar ports の提供する何らかの機能を必要としているからです. 例えば foo が画像を使うとすると, bar は画像処理に必要な ライブラリを持っている, などです. または, bar は foo をコンパイルするのに必要なツールなのかもしれません. Q. ports から grizzle プログラムをインストールしましたが, まったく ディスクスペースの浪費です. 削除したいのですが, すべてのファイルが どこへインストールされたのかわかりません. 何か手がかりはありませんか? A. 大丈夫, 次のようにしてください. &prompt.root; pkg_delete grizzle-6.5 Q. ちょっと待ってください. 削除しようとするコマンドのバージョン番号を 知っていなくてはならないのでしょうか? あなたは, 私がバージョン番号を 覚えていることを本気で当てにしているのでしょうか? A. そんなことはありません. バージョン番号は次のようにすればわかります. &prompt.root; pkg_info -a | grep grizzle Information for grizzle-6.5: grizzle-6.5 - the combined piano tutorial, LOGO interpreter and shoot 'em up arcade game. Q. ディスク容量のことなのですが, ports のディレクトリは非常に膨大な容量を 使うように見えます. 残しておいた方がよいのでしょうか? 削除してしまっても よいのでしょうか? A. はい. インストールが首尾よく終わり, もうソースコードが必要でないと思うなら, それらを残しておく理由はないでしょう. 一番よい方法は, 次の通りです. &prompt.root; cd /usr/ports &prompt.root; make clean これは, すべての ports のサブディレクトリを調べ, 各 ports のスケルトン以外の削除をおこないます. Q. これを試してみたのですが, tarball や ports で使われたファイルが distfiles ディレクトリに残っています. これも削除してしまっても大丈夫ですか? A. はい. それを使った作業が終わったのであれば, 削除してしまっても大丈夫です. Q. 私はとてもとてもたくさんのプログラムを楽しみたいのです. 一度にすべての ports をインストールする方法はありませんか? A. 次のようにしてください. &prompt.root; cd /usr/ports &prompt.root; make install Q. やってみました. 時間がとてもかかるだろうと思ったので, そのまま実行を 続けさせて, 私は寝ました. 翌朝コンピュータを見てみると, 三つ半の ports しか 処理が終わっていませんでした. なにか悪かったのでしょうか? A. これは ports の中には私たちの決められないこと (例えば, あなたが A4 の 用紙に印刷したいのか, US レターサイズの用紙に印刷したいのかなど) について 質問してくるものがあるからです. それらの質問には手動で答える必要があります. Q. 私は一日中モニタの前に座って過ごしたりしたくないのですが. 何かよいアイデアはありませんか? A. では, あなたが寝に / 仕事に / 公園にいく前に以下を実行してください:- &prompt.root; cd /usr/ports &prompt.root; make -DBATCH install これでユーザの入力を要求しないすべての ports をインストールします. そして, 戻ってきてから, 次のように実行してください. &prompt.root; cd /usr/ports &prompt.root; make -DIS_INTERACTIVE install そして, 残りの作業を実行してください. Q. 私たちは ports コレクションにある frobble を使っています. ですが, 私たちの必要に応じて ports を変更したところがあるのです. 自分でパッケージを作って, それを私たちのサイトのまわりに 簡単に配布できるような方法がありますか? A. もちろんあります. 変更点をパッチにする方法は知っていますよね:- - &prompt.root; cd /usr/ports/somewhere/frobble + &prompt.root; cd /usr/ports/somewhere/frobble &prompt.root; make extract &prompt.root; cd work/frobble-2.8 [あなたのパッチを当ててください] &prompt.root; cd ../.. &prompt.root; make package Q. この ports の技術は本当に賢いですね. どのようにして動いているのか 私はどうしても知りたいと思います. その秘密は何ですか? A. 秘密は一切ありません. Makefiles + URL="file://localhost/usr/ports/Mk/">Makefiles ディレクトリ にある bsd.ports.mk と bsd.ports.subdir.mk ファイルを見るだけです. 複雑なシェルスクリプトを嫌う読者は, このリンクを追いかけないほうが よいでしょう. 自分で port を作る 原作: &a.jkh;, &a.gpalmer;, &a.asami;, &a.obrien; and &a.hoek;. 28 August 1996. 訳: &a.jp.simokawa;, &a.asami;. 10 November 1996. 自分で port を作ることに興味がありますか, すばらしい! これから, FreeBSD 用のportを作る際の, いくつかのガイドラインを 説明します. 実際にportをコンパイルするときのほとんどの仕事は - /usr/share/mk/bsd.port.mk + /usr/ports/Mk/bsd.port.mk というファイルでおこないます. Portsコレクションについてのさらに細かい内部の働きについては, そちらの ファイルを参照してください. これにはコメントが細かく書いてありますので, Makefile を読むのにあまり慣れていない人でも, 得るものはとても大きいで しょう. ここでは, 変更可能な変数の一部についてのみ記述しています. ほとんどの変数はbsd.port.mk の始めに記述があります. また, このファイルは非標準のタブの設定になっています. Emacs や Vim はファイルのロード時にこれを認識しますが, viやexでは, ファイルをロードしたら :set tabstop=4 のようにして正しい値を設定する ことができます. 3分porting この節では, 簡単なportの方法について説明します. 多くの場合これ では不十分ですが, まあうまくいくかどうか試してみて損はないでしょ う. まず, 元のtarファイルをDISTDIRに置きます. デフォルトは/usr/ports/distfilesです. 以下では, ソフトウェアはそのままコンパイルされるとします. つまり, FreeBSDのマシンで動かすために, 変更がまったく必要ない とします. もしなにか変更が必要な場合には次の節も参照する必要 があります. <filename>Makefile</filename> の作成 最小限のMakefile は次のようなものです: # New ports collection makefile for: oneko # Version required: 1.1b # Date created: 5 December 1994 # Whom: asami # # $Id$ # DISTNAME= oneko-1.1b CATEGORIES= games MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ MAINTAINER= asami@FreeBSD.ORG MAN1= oneko.1 MANCOMPRESSED= yes USE_IMAKE= yes .include <bsd.port.mk> おわかりになりますでしょうか. $Id$があ る行の内容については, 気にしないでください. これはこのファイル がportsツリーに書き込まれるときにCVSによって自動的に書 き込まれます. もっと詳しい例が見たければ, Makefileのお手本 の節をご覧ください. Package記述ファイルの作成 どのようなportでも, packageにするしないに関わらず, 3つ の記述ファイルが必要です. pkgサブディレクトリにある, COMMENT, DESCR, それに PLISTです. <filename>COMMENT</filename> これには, そのportについての説明を1行で書きます. Package の名前, バージョン番号等は 含めないでください. たとえば, こんな具合です: A cat chasing a mouse all over the screen. <filename>DESCR</filename> これは, そのソフトウェアについての, すこし長い説明を記述します. その port が何をするのかについての数段落程度の 簡潔な解説があれば十分です. このファイルはマニュアルでもなければ, 使用方法やコンパイル方法についての細かい 説明書でもありません. 特に, READMEファイル manpage をコピーしようとしてしている場合には 注意してください. これらは多くの場合, そのポートの簡潔な説明に なっていなかったり, 扱いにくい形式(manpage の場合, 行を揃えるために空白が調整されます)になっていたりします. もしこのソフトウエアに公式の WWW のホームページがあれば, - ここに書いて下さい. + ここに書いて下さい. 自動化ツールが正しく動作するように, + Web サイトのうちの ひとつ には, 前に + WWW: を付け加えてください. このファイルの最後にあなたの名前を書くことが 推奨されています. たとえば, こんな具合です. This is a port of oneko, in which a cat chases a poor mouse all over the screen. : (うんぬん.) -http://www.oneko.org/ +WWW: http://www.oneko.org/ - Satoshi asami@cs.berkeley.edu <filename>PLIST</filename> このファイルには, このportによってインストールされるファ イルが列挙されます. このファイルはpackageを作る際のリス トとして使われるため, `packing list' とも呼ばれます. ここ に書かれているファイル名は, インストール時のプレフィックス (普通は /usr/local か /usr/X11R6) からの 相対パスです. MANn 変数を使用する場合(使用することが推奨されています)には, マニュアルはここに入れないでください. 簡単な例を載せておきましょう: bin/oneko lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpm @dirrm lib/X11/oneko 'Packing list'の詳細については, &man.pkg.create.1; の マニュアルを参照してください. すべてファイルを列挙しなければなりませんが, ディレクトリ名は必要ありません. また, ports がインストール時にディレクトリを作成する場合には, @dirrm の行を加えて, その port が削除されるとき, そのディレクトリも削除されるようにしてください. このファイルには, ファイル名をアルファベット順に並べるようにしてください. port のアップグレートのとき, 楽に確認ができるようになります. チェックサムファイルの作成 ただ, make makesum と入力するだけです. bsd.port.mk にルールがあるので, 自動的にfiles/md5が生成されます. Portのテスト そのportが正しく動くことを, package化を含めて確認してください. 以下の重要なポイントを確認してください. PLIST にその port がインストールしないものが含まれていないこと. PLIST にその port がインストールする全てのものが含まれていること. reinstall ターゲットを使うことによって, 何度でもインストールが可能こと. deintall の際に 後片付け をすること. 推奨されるテストの手順 make install make package make deinstall pkg_add `make package-name` make deinstall make reinstall make package package および deinstall の段階で, どんな警告(warning)も出力されないことを確認してください. ステップ3の後, 新しいディレクトリが全て正しく消去されているかを 確認してください. また, ステップ4の後にそのソフトウェアを使用してみて, package からインストールされた場合に正しく動作するかを 確認してください. <command>portlint</command> でチェック portlintを使って, あなたの port が我々のガイドラインそっているかを確認してください. portlint プログラムは ports コレクションに含まれています. 特に, Makefile が正しい形式になっているか, package の名前が正しいか, をチェックするのに良いでしょう. Portの送付 まず, やってよいことといけないこと についての節を読んでください. さあ, あなたのportに満足したら, あとはそれをFreeBSDのメイ ンのportsツリーに置いて, 皆に使ってもらうだけです. いまある work ディレクトリや pkgname.tgz パッケージは必要ありませんから, まず消去してください. あとは, バグレポートの中に shar `find port_dir` の出力を, &man.send-pr.1; プログラムを使用して送ってください. &man.send-pr.1; についての詳細は, バグ報告と一般的な論評 を参照してください.) もし, 圧縮していない状態で, 20KB以上あるようなポートであれば, 圧縮して tar ファイルにして, バグレポートに入れる前に &man.uuencode.1; を使用してください. (20KB以下のものでも, tar ファイルにして送ってもよいですが, あまり歓迎されません). バクレポートの category は ports, class は change-requestを必ず使用してください. (レポートを confidential (内密) にしないようにしてください!) もう一度, オリジナルのソースファイル, work ディレクトリ, make package で作成したパッケージが含まれていないこと を確認してください. 以前, 新しい port をわれわれの ftp サイト (ftp.freebsd.org) にアップロードするようにお願いしたことがありますが, 現在このサイトの incoming ディレクトリは読み出し不可になっており, いまでは推奨されていません. 沢山の海賊版ソフトウェアがそこに置かれたためです. 私たちは, 何か不明な点があったらあなたに確認したのち, それをツリーへ置きます. あなたの名前は, FreeBSD ハンドブックやその他のファイルの “Additional FreeBSD contributors” のリストにも載るでしょう. う〜ん, 素晴らし い. :) 本格的なport 残念ながら, 移植がそう簡単ではなく, 動かすために多少の変更が 必要な場合も多いでしょう. この節では, portsコレクション の方法論にのっとって, そのような場合にどのように変更を施し, 動 くようにしたらよいかを順を追って説明します. port構築の詳細 まず, あなたがportのディレクトリで make とタイ プしてから起こる一連の出来事について,順を追って説明しま す. ここを読むときには, 他のウィンドウで同時に bsd.port.mk も開いておくとよいかもしれません. しかし, bsd.port.mkが何をしているのか, 完全に理解 できなくても心配する必要はありません. そう多くの人が理解して いるわけではないですから... f(^_^;) まず, fetch というターゲットが実行されます. このfetchターゲットは ローカルディスクのDISTDIRに配布ファ イルがあるようにするのが役目です. もし, fetchが必要なファ イルをDISTDIRに見つけることが できなけ れば, Makefileに指定されているURL MASTER_SITES, そして私たちのFTPサイトで ある ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/ (ここ には, 私たちが取ってきたファイルを バックアップとして置いてあ ります) に探しにいきます. そして, ユーザのサイトがインター ネットに 直接接続されている場合には, FETCH を使って, その名前のファイルを取っ てきて, DISTDIRに保存します. 次に実行されるのは extract ターゲットです. これは, DISTDIRにある, 配布ファイル (普通は gzipされたtarファイル) を読み, ソースを一時的な作業ディレ クトリWRKDIR (デフォルトは work) に展開します. 次に, patch というターゲットが実行されます. まず, PATCHFILESに定義されている, すべてのパッ チをあてます. 次にもしPATCHDIR (デフォ ルトは patches サブディレクトリ) にパッチが存在す れば, これらをアルファベット順にあてます. 次に実行されるターゲットは configureです. これには, い ろいろな場合があります. もし存在すれば, scripts/configure が実行されます. もし, HAS_CONFIGURE あるいは GNU_CONFIGURE がセットされていれば, WRKSRC/configure が実行されます. もし, USE_IMAKE がセットされていれば, XMKMF (デフォルト: xmkmf -a) が実行されます. 最後に, build というターゲットが実行されます. これは, その port の専用の作業ディレクトリ (WRKSRC) にい き, コンパイルするのが役目です. もし USE_GMAKE がセットされていれば, GNU make が使用されます. さもなければFreeBSDの make が使用されます. 上記はデフォルトのルールです. さらに, pre-何とか や post-何とか というターゲット が定義してあった り,そのような名前のスクリプトが scripts サブディレクトリに置いてある場合には, それらはデフォルトの動作の前 後に実行されます. たとえば, post-extract というターゲットがMakefile で定義されていて, pre-build というファイルが, scripts サブディレクトリにあるとすると, post-extractターゲットは, 通常の展開動作のあとに呼 び出され, pre-build スクリプトはデフォルトのコンパイ ルのルールが実行される前に実行されます. もし動作が簡単であれ ば, Makefile のターゲットを使用することが推奨されています. な ぜならば, そのportが何らかのデフォルトではない動作を必要とす るのかどうかが一箇所にまとめて書いてあった方が他の人に 理解しやす いからです. デフォルトの動作は bsd.port.mk の do- 何とか というターゲットでおこなわれます. たとえば, portを展開するコマンドは, do-extract というターゲットにあります. もし, デフォルトのターゲットに 不満があれば, do- something というターゲッ トを再定義することによって, どのようにでも直すことができます. “メイン”のターゲット (例えば, extract, configure等) は, すべての前段階が実行されていること を確認して, 実際のターゲットやスクリプトを呼び出す以外のこと はしません. bsd.port.mkはこれらが変更されることは仮定してい ませんので, もし, 例えば, 展開の仕方を直したいときには, do-extract を直し, 絶対にextractには手を 触れないでください. これで, ユーザが make と入力したときに何が起こ るのかが理解できたと思います. では, 完璧なportを手順を追っ て作ってみましょう. オリジナルのソースの入手 オリジナルのソースを, (普通は) 圧縮されたtarファイルの形 ( foo.tar.gz あるいは foo.tar.Z) で入手して, それを DISTDIR にコピーします. 可能なかぎり, 広 く使われている主流の ソースを使用するようにしてください. もし, ネットワークへの接続のよい FTP/HTTP サイトを見つけるこ とができなかったり, 頭にくるような非標準的な形式しか持ってい ないサイトしか見つけられないときには, 自分で管理する確実な ftp か http サーバ (たとえば, あなたのホームページ)に置くこと ができます. MASTER_SITES に正しく反映されていることを確認してください. もしも, そのような都合の良く, 安心な置き場所が見つけられない 場合(あなたが FreeBSD の committer であれば, 自分の public_html ディレクトリに置けます), 私たちが, ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/distfiles/LOCAL_PORTS/ に置き場所を提供できます. この場所は, 変数 MASTER_SITE_LOCAL を使って参照してください. これについての問い合わせのメールは &a.ports へお願いします. その port の配布ファイルが特に理由もなく, しょっちゅう変る場合には, 配布ファイルをあなたのホームページに置いて MASTER_SITESの最初に入れてください. こうすることによって, ユーザ利用する場合に checksum mismatch エラーが起るのを防ぎ, 我々の ftp サイトの保守の負担を減らすことができます. もし, master site がたった一つしかない場合には, あなたのサイトにバックアップを置いて MASTER_SITES の2番目に加えてください. もし, あなたのportに必要ないくつかの追加パッチがインター ネット上で手に入るのならば, それらも取ってきて, DISTDIR に置きます. もし, それらがメイン のソースのtarファイルとは別のサイトにあっても, 心配する必要 はありません. そのような状況にはちゃんと対応できるようになっ ています. (以下のPATCHFILESの記述 をご覧ください). Portの修正 適当なディレクトリにtarファイルを展開して, FreeBSDの最新の バージョン上で, 正しくコンパイルできるために必要なあらゆる変 更を施します. 最終的に処理は自動化するわけですから, 何をおこなっ たかを注意深く記録しておきましょう. あなたのport が完成した暁には, ファイルの削除, 追加, 修正を含むすべての処 理が, 自動化されたスクリプトやパッチファイルで おこなえるようになっ ていないといけません. もし, あなたの port のコンパイルやインストールのために必要 な手作業があまりに多いようならば, Larry Wall の模範的な Configure スクリプトでも参考にしたほうがいいかもしれませ ん. 新しいportsコレクションは, 最小のディスクスペースで, 個々のportがエンドユーザにできるだけ“プラグ & プレ イ”の状態でmakeできることをめざしています. あなたが作成し FreeBSD の ports に寄付されたパッチファイル, スクリプトおよびその他のファイルは, 明示的に記述されている場合 を除いては, BSDの標準的な著作権条件によりカバーされていると見な されます. パッチをあてる port の過程で追加されたり変更されたファイルは再帰的diffで変 更点を取り出すことができます. パッチは適当にまとめて, patch-xx という名前のファイルに入れてくだ さい. xx はパッチが適用される順番を示します — これらは, アルファベット順, つまり aa が 最初, つぎに ab などとなります. これらのファイル をPATCHDIRに置いておくと, 自動的に適用さ れるようになっています. すべてのパッチは WRKSRC (通常は, portのtarファイルが展 開されるところで, makeが実行されるところと同じです) からの相 対パスになります. 修正やアップグレードを容易にするため, 2つ 以上のパッチが同じファイルを修正するのは避けてください. (例, patch-aaとpatch-abが共にWRKSRC/foobar.c を修正する, など.) コンフィグレーション カスタマイズのために追加したいコマンドがあれば, configure という名前のスクリプトに入れて scripts サブディレクトリに置きます. 上で述べたよ うに, pre-configure あるいは post-configure という Makefile のターゲットおよび/あるいはスクリプトで処理す ることもできます. ユーザからの入力の扱い もし, そのportがビルド, コンフィグレーション, インストー ルの際にユーザからの入力を必要とするならば, Makefileで IS_INTERACTIVEをセットしてください. これによって, 深夜, 自動的にたくさんのportをコンパイルすることが可能にな ります. 環境変数BATCHがセットされていると IS_INTERACTIVE の定義されているportはスキップされ ます (そして, ユーザがINTERACTIVEという変数をセッ トすると入力を必要とする port のみコンパイルされま す). もし, 適切なデフォルト設定があるのであれば, PACKAGE_BUILDING 変数をチェックして,それが設 定されて いる場合には, ユーザ入力のスクリプトを起動しないように してください. こうすることによって, CD-ROM や ftp に 置く packageを我々が作成することができます. Makefileの作成 Makefileの作成は非常に単純です. 繰り返しになりますが, 始める まえに, すでにある例を見てみることをお奨めします. またこのハ ンドブックにはMakefileのお手本 があります. それを見て, Makefile内の変数の順番や空行を入れると ころなどの参考にしてください. そうすると他の人々にも読みやすい ものとなります. では, Makefileをデザインするときに問題となるところを順に追っ て見てみましょう. オリジナルのソース ソースはDISTDIRに, 標準的なgzipされた tarファイルとして置かれていますか? そうであれば, 次のステッ プに進めます. そうでなければ, 変数 EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX, DISTFILES を適当に書き換えないといけません. どれだけ変更しないといけないかは, あなたのportの 配布ファイルがどの程度標準からかけはなれているかによりま す. (最もよくある場合は, gzipではなく普通のcompressコマンド でtarファイルが圧縮されている場合で, EXTRACT_SUFX=.tar.Z とするだけです.) 最悪の場合には, 自分で do-extract ターゲットを作 成して, デフォルトを上書きすることもできます. しかし, そこま でする必要があることはめったにないでしょう. <makevar>DISTNAME</makevar> DISTNAME には port の名前の基幹部分を入れ ます. デフォルトのルールでは, 配布ファイルのリスト (DISTFILES) は DISTNAME EXTRACT_SUFX という名前 になっています. 例えば, foozolix-1.0.tar.gzの場 合, 通常のtarファイルだと, DISTNAME=foozolix-1.0 のようになります. さらにデフォルトのルールでは, tarファイルは work/DISTNAME というサブディレクトリ に展開されることを仮定しています, 例えば work/foozolix-1.0/ といった具合いです. これらの動作はもちろんすべて変更可能です. デフォルトのルー ルは最も標準的な場合を仮定しているだけです. まず, port が複 数の配布ファイルを必要とするときには, 単に明示的に DISTFILESを設定してください. もし, DISTFILES の一部だけが実際に展開される場合 には, それらをEXTRACT_ONLY に設定してくだ さい. この変数が定義されている場合には, 展開時に DISTFILESに優先して利用されます. 残りのファ イルもDISTDIRに取ってきますが, 展開時に はなにもせずに後で使うためにそのまま置いておかれます. <makevar>PKGNAME</makevar> もし, DISTNAME が我々の package の名前についてのガイドライン に沿ったものでない場合には, PKGNAME にもっと良い名前を設定してください. 詳細は上記のガイドラインを参照してください. <makevar>CATEGORIES</makevar> (分類) 完成した package の実体は /usr/ports/packages/All に置かれます. また, 1つかそれ以上の /usr/ports/packages のサブディレクトリからのシンボリッ クリンクが作られます. それらのサブディレクトリの名前が CATEGORIES という変数によって指定されます. これは, ユーザがFTPサイトやCD-ROMのpackageの山を渡り歩 くことを容易にするためです. 現在存在する カテゴリを見て, そ のportに適したもを選んでください. このリストは, この port が port tree のどこに import されるかも決定します. 2つ以上のカテゴリを指定した場合には 最初のカテゴリで指定されるサブディレクトリに置かれること になります. 適切なカテゴリを選ぶ方法については, カテゴリ の節を参照してください. もしその port が本当に現在存在するすべてのものとは異なって いる場合には, 新しいカテゴリ名を作ることもできます. その際には, &a.ports 宛てに新しいカテゴリ名を提案する メールを送ってください. カテゴリ名については, なんのエラーチェックも行なわれません.ミスタイプがあっても make package はなにも考えずに 新しいディレクトリを作ってしまいますので, 注意してください. <makevar>MASTER_SITES</makevar> オリジナルの配布ファイルを指し示す FTP または HTTP の URL のディ レクトリ部分までを MASTER_SITES に記録しま す. スラッシュ (/) を最後につけることをお忘れなく. 配布ファイルがシステム上に存在しないときに, makeマクロは FETCH でこの変数に指定されたサイトから取っ てきます. 複数の, できれば異なる大陸のサイトをこのリストに入れておく ことが推奨されています. これによって, 広域ネットワークにトラ ブルがあった場合でも成功する可能性が高くなります. 私たちはさら に, 自動的に最も近いマスタサイトを検出して, そこから取って くるメカニズムの導入を計画しています. オリジナルのtar ファイルが, X-contrib, GNU, Perl CPAN, TeX CTAN または Linux Sunsite などの有名なアーカイブにある場合には, MASTER_SITE_XCONTRIB, MASTER_SITE_GNU, MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN および MASTER_SITE_SUNSITE を利用することで, 簡単にこれらのサイトを 指定することができます. あとは MASTER_SITE_SUBDIR にアーカイ ブ内でのパスを指定するだけです. 以下に例を示します. MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications ユーザは/etc/make.conf中で MASTER_SITE_* 変数を設定 することによって, デフォルトの FTP サイトではなく, これらの 有名なアーカイブの ミラーの中で好みのものを使用することが可能 です. <makevar>PATCHFILES</makevar> もし, オリジナルの配布ファイル以外にもFTPかHTTPで手に入る パッチが必要な場合には, PATCHFILESにファ イル名を, PATCH_SITESにサイトとディレクト リの名前を MASTER_SITES と同様に設定してく ださい. そのパッチ内のファイル名ががソースツリーの 一番上のディレク トリ (WKRSRC) からの相対パスになっていな い場合には, PATCH_DIST_STRIPを指定してく ださい. 例えば, パッチ内のファイル名にすべて余計な foozolix-1.0/ がついている場合には, PATCH_DIST_STRIP=-p1としてください. これらのパッチは圧縮されていても大丈夫です. ファイル名が .gz か .Z で終わる場合には自動的に復元 されるようになっています. もしパッチが, 文書などその他のファイルと一緒に gzip された tarファイルで配布されている場合には，単純に PATCHFILES を使うことはできません. このような場合には, このパッチの tar ファイルの名前と場所を DISTFILES と MASTER_SITES に加えます. それから, pre-patch ターゲットで, パッチコマンドを走らせるか, パッチファイルを PATCHDIR ディレクトリに patch-xx という名前でコピーするかして, パッチを適用するようにします． 普通の gzip か compress された tar ファイルであれば, 通常のソースファイルと一緒にその時までに 展開されていますので, 明示的に展開する必要はありません. もし, 後者の方法を使用する場合には, すでにそのディレクトリにある なにかを上書きしないように, 注意する必要があります. さらに, pre-clean ターゲットにコピーしたパッチファイル を削除するコマンドを追加するのを忘れないでください. <makevar>MAINTAINER</makevar> あなたのメールアドレスをここに入れてください. お願いします. :) 保守担当者(maintainer)の責任についての詳細は， Makefile 中の MAINTAINER の節をご覧ください． 依存関係 このプログラムが他のportに依存する場合には, 必要なものが 自動的に作られるようにすることができます. そのために, 以下の 5つの変数が用意されています. よくあるケースのためにあらかじめ設定された依存変数や, いくつかの依存関係の制御のための変数があります. <makevar>LIB_DEPENDS</makevar> Port が必要とする非標準の共有ライブラリを この変数で指定 します. これは lib: dir: target という組のリストで, うち lib が共有ライブラリの名前, そして dir がそのライブラリが見つからない場合にインストールする port のあるディレクトリで, target はそのディレクトリで呼ばれるターゲットです. 例えば, LIB_DEPENDS= jpeg.9:${PORTSDIR}/graphics/jpeg:install と指定してあれば, まずメジャーバージョンが9のjpegライブ ラリがあるかどうか確認し, ない場合にはportsツリーの中の graphics/jpeg というサブディレクトリに移動し, そこ でコンパイルとインストールを行ないます. target の 部分は, DEPENDS_TARGET (デフォルトは install) と等しいときには省略できます. 前半の lib 部分は ldconfig -r | grep -wF への引数になります. この変数には正規表現を入れられません. この依存関係は2度チェックされます. まず extract ターゲットで, 次に install でチェックされます. (これは, その port を作成するマシンとインストールする マシンが違う場合でも, きちんとそのライブラリが利用できる ことを確認するためです.) また, 依存するもの名前は package の中にも含まれますので, ユーザのシステムに存在しなければ, pkg_add が自動的にインストールします. <makevar>RUN_DEPENDS</makevar> Port を使用する際に必要となるファイルまたはプログラムがある ときにはこの変数で指定します. これは path: dir :target とい う組のリストで, path がファイルまたはプログラムの 名前, そして dir がそれが見つからない場合に作成する ためのディレクトリ名で target はそのディレクトリで呼ばれるターゲットです. path の最初の文字がスラッ シュ (/) の場合にはファイルかディレクトリ とみなし, その存在を test -e でチェックします; そうでない場合には 実行可能であると仮定し, which -s を使って そのプログラムがユーザのサーチパス上に あるかどうか確認します. 例えばMakefileに以下のように書いてあるとします. RUN_DEPENDS= ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \ wish8.0:${PORTSDIR}/x11-toolkits/tk80 まず, /usr/local/etc/innd というファイルかディレクトリが存在 するか確認し, ない場合にはportsツリーの中の news/inn というサブディレクトリから作られます. ま た, wish8.0 というプログラムがユーザのサーチパス中 にあるかどうか探し, ない場合には同じくportsツリーの x11-toolkits/tk80 というサブディレクトリから作られます. この例で, innd は実際にはプログラムです; この ように, プログラムであっても標準のサーチパス以外のところに あるようなものの場合には, 絶対パスで指定してください. この依存関係はinstall ステージのはじめでチェック されます. また, packageを作る際に必要となるportのpackage名 が記録され, pkg_addを使用すると ユーザのシステムに存在しない場合には自動的にそちら のpackageもインストールされるようになります. target の部分は, DEPENdS_TARGET と同じ場合には省略可能です. <makevar>BUILD_DEPENDS</makevar> Port のコンパイルに必要なファイルまたはプログラムがある ときは, この変数で指定してください. RUN_DEPENDSと同 様に, これは path: dir :target という組のリストです. 例 えば, BUILD_DEPENDS= unzip:${PORTSDIR}/archivers/unzip は unzip という名前のプログラムを探し, 見つから ない場合にはarchivers/unzip サブディレクトリで作 れという意味になります. ここでは “コンパイル” と一口にいいましたが, この変数は実際 にはファイルの展開から実際のコンパイル・リンクまで 全部をま とめて面倒を見てくれます. この依存関係は extract ステージからチェックされます. target の部分は DEPENDS_TARGET と同じ場合には省略可能です. <makevar>FETCH_DEPENDS</makevar> この変数は, portを取ってくるのに必要なファイルまたはプロ グラムを指定するのに使います. 上の二つと同様に, これは path: dir :target という組のリストです. 例えば, FETCH_DEPENDS= ncftp2:${PORTSDIR}/net/ncftp2 としておけば, ncftp2 という名前のプログラムを探 し, 見つからない場合にはnet/ncftp2 サブディレク トリにいってインストールします. この依存関係は fetch ステージからチェックされます. target の部分は DEPENDS_TARGET と同じ場合には省略可能です. <makevar>DEPENDS</makevar> 上記の四つのいずれにもあてはまらないような 依存関係がある場 合, または他の port がインストールされれているだけではなく, ソースが展開されている必要がある場合にはこの変数 を使います. これは dir :target という形式のリスト になります. 上記の四つと違って特に “確認”するものがありませんので. よくある依存関係を表す変数 もし ports が X Window System を必要とするのであれば, USE_XLIB=yes を定義してください. (これは USE_IMAKEも意味します) BSD make の代りに GNU make を必要とする場合には, USE_GMAKE=yes を定義. 動作するのに GNU autoconf を必要とする場合には, USE_AUTOCONF=yes を定義. 最新の qt toolkit を使用 する場合には USE_QT=yes を定義. perl 言語のバージョン5 を必要とする場合には, USE_PERL5=yes を定義してください. (特に最後のは重要で, FreeBSD のいくつかの バージョンでは基本システムに perl5 を含みますが, 他のものは含んでいません.) 依存関係に関する注意 上で述べたように, 依存する ports が必要になったときに呼ばれるデフォルトのターゲットは DEPENDS_TARGET で, そのデフォルトは install です. これは, ユーザの使用する変数で, port の Makefile で定義されるものではありません. もし, あなたのportが特別な方法で, 依存関係を扱う必要が ある場合には, DEPENDS_TARGET を再定義するのではなく, *_DEPENDS 変数の :target の部分を利用してください. make clean とタイプしたときには, 依存する port も自動的に clean されます. もしそうしたくない場合には, NOCLEANDEPENDS を環境変数として設定してください. 無条件に他の port に依存させるには, 特別に nonexistent という文字列を BUILD_DEPENDS あるいは RUN_DEPENDS の最初のフィールドに使用してください. これは, 他の port のソースが必要なときのみ使用してください. target も指定することによって, コンパイルの時間を節約することができます. 例えば, BUILD_DEPENDS= /nonexistent:${PORTSDIR}/graphics/jpeg:extract これは, 常に JPEG port の directory に行きソースの展開を行ないます. あなたがやりたいことが他の方法ではできない場合以外は, DEPENDS を使わないでください. これは常に 他の port の作成を行い(さらにデフォルトでインストール を行い), package も作成します. もし本当にこれがあなたの やりたいことでしたら, 代りにこれを BUILD_DEPENDS と RUN_DEPENDS で書くことをお勧めします — 少なくとも意図が明確になります. コンパイル時の特別な指定 GNUのmakeを使う場合には, USE_GMAKE=yes と指定してください. Port に GNU の configure が含まれ ている場合には, GNU_CONFIGURE=yes を使います(これは, HAS_CONFIGURE も意味します). configure に追加の引数 (デフォルトでは, GNU の configure では --prefix=${PREFIX}, GNUでない configure では空) を渡したい場合には追加部分を CONFIGURE_ARGS で指定してください. そのパッケージが autoconf を使用する場合には, USE_AUTOCONF=yes を使います. これは, GNU_CONFIGURE も意味し, configure の前に autoconf を実行します. X Window Systemのアプリケーションなど, imakeを 使って Imakefile から Makefile を作成するportの場合には USE_IMAKE=yes を指定してください. コンフィグレー ションステージで自動的にxmkmf -a が実行されます. も し フラグが問題をもたらすなら, さらに XMKMF=xmkmfとしてください. もし, port が imake を使用するけれども, install.man ターゲットがない場合には, NO_INSTALL_MANPAGES=yes を指定してください. ついでに, その port のオリジナルの作者を探し出して八つ裂きにすると いいでしょう.:> Portの Makefile が all 以外のものをメインのター ゲットとしている場合には, ALL_TARGET でそ れを指定してください. install と INSTALL_TARGET も同様です. もし, port の元の Makefile が all 以外のターゲットをメインのターゲットとしている場合には, ALL_TARGET をそれに合わせて設定してください. install と INSTALL_TARGET についても同様です. <makevar>NO_INSTALL_MANPAGES</makevar> あなたの port がimakeは使うものの install.man ターゲットを持っていない場合, NO_INSTALL_MANPAGES=yes を指定してください. つい でに, 作者を探し出して八つ裂きにするといいでしょ う. (-_-#) 特別な配慮 Portを作成する場合, 考慮しなくてはいけないことがさらにいくつかあります. この節では, それらのうちもっともありがちなものについて説明します. ldconfig 共有ライブラリをインストールするときには, 共有ライブラリのキャッシュを更新するために port の Makefile の post-installtarget から${LDCONFIG} -m を走らせてください. このコマンドの引数は共有ライブラリのインストールしてある ディレクトリ (通常 PREFIX/lib) です. また, pkg/PLIST に @exec /sbin/ldconfig -m と @unexec /sbin/ldconfig -R の組を入れて, package をインストールした場合にも共有ライブラリがすぐ使え, 削除の際にも, システムがまだライブラリが存在すると 誤認しないようにしてください. この行は共有ライブラリを指定する行のすぐ後に 書くのがよいでしょう: lib/libtvl80.so.1 @exec /sbin/ldconfig -m %D/lib @unexec /sbin/ldconfig -R 絶対に引数なしでただ ldconfig とだけ書いてある行を Makefile や pkg/PLIST ファイルに入れないでください. このコマンドを実行すると, 共有ライブラリのキャッシュが /usr/lib の内容のみとなり, ユーザのマシンにさまざまな問題をもたらします (「ぎゃぁ! このportをインストールしたら xinit が使えなくなっちゃった!」). この掟を破った者は, 永久に地獄の底で苦しみ続けるように, 閻魔様に頼んでおきます. ELF 対応 FreeBSD は 3.0-RELEASE で ELF に移行しましたので, シェアードライブラリを作成するたくさんの port を ELF 対応 にする必要があります. 3.0 システムは ELF としても a.out としてmも 動作しますし, 我々は非公式ではありますが, できるだけ長い間 2.2 システムのサポートをしたいと思っていますので, 複雑な状況です. 以下は a.out のみに対応している port をどのように a.out と ELF 両方に対応させるかのガイドライ ンです. このリストの一部は, 移行時にしかあてはまらないものもありますが, 古い port をアップグレードしたい場合に参考になるように, しばらくのあいだは残しておきます. a.out ライブラリの退避 a.out ライブラリは, /usr/local/lib から, aout サブディレクトリ に移動しなくはなりません. (もし移動しないと, ELF ports がそれらをあっさり上書きして しまいます.) 3.0-CURRENT の src/Makefile にある move-aout-libs ターゲット (aout-to-elf から呼ばれます) がその移動をしてくれます. a.out ライブラリを移動するだけなので, ELF と a.out の両方のライブラリが標準的な ディレクトリにあるシステムでは, このターゲットを実行しても安全です. フォーマット port ツリーは package をそのマシンのフォーマットで作成します. つまり, 2.2 では a.out, また 3.0 では `objformat` の結果によって, a.out か ELF になります. また, いったん a.out ライブラリをサブディレクトリに移動すると a.out ライブラリの作成はサポートされません. (つまり, あなたがにをすれば良いのかを理解しているのならば, うまく作成できるかもしれませんが, 自力でやらなければならないということです) もし port が aout でしか動作しないのなら, BROKEN_ELF に原因を説明する文字列を設定してください. この変数が設定された port は, ELF システム上でのビルドの際スキップされます. PORTOBJFORMAT bsd.port.mk において PORTOBJFORMAT は aout か elf に設定され, 環境変数 CONFIGURE_ENV, SCRIPTS_ENV, MAKE_ENV の中で export されます. (2.2-STABLE では常に aout になります). また, PORTOBJFORMAT=${PORTOBJFORMAT} として PLIST_SUB に渡されます. (以下にある ldconfig に関するコメントを参照して下さい.) この変数は, 以下のようにして bsd.port.mk 中で設定されます. PORTOBJFORMAT!= test -x /usr/bin/objformat && /usr/bin/objformat || echo aout この変数を使って, port の make の過程で何をすべきかを決定すべきですが, もし port の configure スクリプトが元々, ELF システムを自動的に検出するのであれば, PORTOBJFORMAT を参照する必要はありません. 共有ライブラリの作成 以下は, a.out と ELF での共有ライブラリの扱いの違いです. 共有ライブラリのバージョン ELF の共有ライブラリは, libfoo.so.M という名前になっていなければなりません. ここで M は単一の バージョン番号を表します. 一方 a.out のライブラリは libfoo.so.M. N という名前で, M はメジャーバージョン番号, N はマイナーバージョン番号になっている必要があります. これらを混同しないでください. libfoo.so.N. M という名のELF 共有ライブラリや libfoo.so.N という名の a.out 共有ライブラリ (あるいはシンボリックリンク) は 絶対にinstallしないでください. リンカコマンドライン 直接 ld を使用せずに, cc -shared を使用してください. たった一つの違いは, ELF には, コマンドラインにを加える必要があることです. ELF のリンカを満足させるためには, libfoo.so から libfoo.so.N へのシンボリックリンクを作る必要があります. これは, PLIST にも加えなくては いけませんし, a.out の場合でも害にはならないので (一部の port ではダイナミックリンクローディングのために 必要でもあります), PORTOBJFORMAT の設定を気にせずに, ただ単純にリンクを作成してください. <makevar>LIB_DEPENDS</makevar> すべての port の Makefile を編集して, LIB_DEPENDS からマイナー番号を除去する必要があり, 正規表現のサポートも除去する必要があります. (例えば, foo\\.1\\.\\(33|40\\) から foo.2) マッチングは grep -wF を使って行われます. <filename>PLIST</filename> PLIST は, a.out のマイナー番号が0であれば, 短い (ELFの) 共有ライブラリの名前を含み, さもなくば長い (a.outの) 名前を含んでいる必要があります. bsd.port.mk は 自動的に, PORTOBJFORMAT が aout であれば, .0 を 短い共有ライブラリの名前の行に付け加え, PORTOBJFORMAT が elf であれば, マイナー番号を 長い共有ライブラリの名前から削除します. ELF システムで 2 つのバージョン番号を持つ共有ライブラリを インストールしたり, aout システムで 1 つのバージョン番号しか持たない共有ライブラリを インストールするのが避けられない場合 (例えば他のオペレーティングシステム用の 互換ライブラリをインストールする port など), NO_FILTER_SHLIBS 変数を定義すれば, 前節で説明されている PLIST 編集の機能が停止されます. <literal>ldconfig</literal> Makefile 中の ldconfig の行は以下のようになります. ${SETENV} OBJFORMAT=${PORTOBJFORMAT} ${LDCONFIG} -m .... また PLIST 中では: @exec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -m ... @unexec /usr/bin/env OBJFORMAT=%%PORTOBJFORMAT%% /sbin/ldconfig -R となります. これは, システムのデフォルトフォーマットではなく パッケージのフォーマットに応じて, 正しい ldconfig が呼ばれることを保証するためのものです. <makevar>MASTERDIR</makevar> もし, あなたの port が 変数(例えば 解像度とか紙のサイズなど)を変えたりした, ちょっと違うバージョンを作成する必要があるときには, ユーザが分りやすいように, package ごとに別々のサブディレクトリを作成し, ただし, できるだけ port 間でファイルを共有するようにしてください. 典型的な例では, うまく変数を使えば, とても短いMakefileだけ, 1つ以外のすべてのディレクトリに置くだけで済みます. その短い Makefile には MASTERDIR を使って, 残りのファイルがあるディレクトリを指定できます. また PKGNAME の一部に変数に使って, package が別々の名前を持つようにしてください. 以下が, とても良い例になるでしょう. これは japanese/xdvi300/Makefile の一部です: PKGNAME= ja-xdvi${RESOLUTION}-17 : # default RESOLUTION?= 300 .if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \ ${RESOLUTION} != 300 && ${RESOLUTION} != 400 @${ECHO} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\"" @${ECHO} "Possible values are: 118, 240, 300 (default) and 400." @${FALSE} .endif japanese/xdvi300 は通常のパッチ, package ファイルももっています. そこで, make と入力すると, デフォルトの解像度(300)を使って, 普通に port の作成を行います. 他の解像度に関してですが, これが, xdvi118/Makefile の(コメントを除いた) すべてです. RESOLUTION= 118 MASTERDIR= ${.CURDIR}/../xdvi300 .include ${MASTERDIR}/Makefile (xdvi240/Makefile と xdvi400/Makefile も同様です). MASTERDIR が bsd.port.mk に PATCHDIR や PKGDIR などの通常のサブディレクトリが xdvi300 にあることを教えます. RESOLUTION=118 の行が, xdvi300/Makefile の RESOLUTION=300 の行を無効にし, port は解像度を118として作成されます. 共有ライブラリのバージョン まず, 共有ライブラリのバージョンについての指針 を読んで, 共有ライブラリのバージョンを 一般的にどうすれば良いかを理解してください. 盲目的に, ソフトウエアの作者がちゃんと理解していると 信じててはいけません, 多くの場合違います. 細い点まで考慮することは大変重要なことです, なぜなら我々は互換性がないかもしれない大量の ソフトウェアを共存させようとする, 特殊な状況にあるからです. 不注意な port の導入が共有ライブラリに関して, 多大な問題を引き起したことが過去にあります (今まで, jpeg-6b がなぜ 9.0 といバージョン番号を持っているか不思議に 思ったことはありませんか?). もし, 疑問があれば, &a.ports; にメールを送ってください. ほとんどの時間は, 正しいシェアードライブラリのバージョンを決めることと, それを実現するためのパッチを作成することに終始します. しかしながら, が同じソフトウェアの違ったバージョンの ソフトウェアが既にツリーにあるばあいには, 状況は非常に複雑です. つまり, FreeBSD では, ユーザがリンカにどのバージョンの共有ライブラリを 使用するかを指定できないからです (リンカは常にもっとも高いバージョンを選びます). これは, もし, libfoo.so.3.2 と libfoo.so.4.0 がシステムに存在するときには, リンカに特別なアプリケーションだけ libfoo.so.3.2 をリンクするように指示する方法がないことを意味します. これは, コンパイル時のリンクという意味では完全に見劣りします. この場合の唯一の解決方法は, 共有ファイルの名前の ベース 部分を変えることです. 例えば, libfoo.so.4.0 を libfoo4.so.1.0 へ変えることによって, バージョン 3.2 とバージョン 4.0 共に他の port からリンクされることができるようになります. マニュアル MAN[1-9LN] 変数を使用すると, 自動的にすべてのマニュアルを pkg/PLIST に加えます (つまり, マニュアルを PLIST に加えては いけません — PLIST の生成 を参照してください). またマニュアルを /etc/make.conf 中の NOMANCOMPRESS の設定に応じて, install時に自動的に圧縮したり伸長したりします. マニュアルをインストール時に圧縮するかどうかを 指定するには, MANCOMPRESSED 変数を使用します. この変数は, 3つの値をとることができます, yes, no そして maybe です. yes はマニュアルが既に圧縮されて インストールされている, no はされていない, maybe はそのソフトウェアがすでに, NOMANCOMPRESS に合わせており bsd.port.mk が特別なにもする必要がないことを意味します. USE_IMAKE がセットされていて, NO_INSTALL_MANPAGES がセットされていなければ, MANCOMPRESSED は自動的に yes に設定され, それ以外の場合には, no になります. デフォルトがあなたの port に合わない場合以外は明示的に設定する必要がありません. PREFIX 以外のディレクトリの下に マニュアルを置くような port では MANPREFIX を指定することができます. さらに, 特定のセクションのマニュアルだけ, 標準ではない場所にインストールする場合, 例えばいくつかの Perl のモジュールの ports など, には個々のマニュアルのパスを MANsectPREFIX (sect は, 1-9, または, L か N を表わします) によって指定できます. ができます. マニュアルが, 言語特有のサブディレクトリに 置かれる場合には, 言語名を MANLANG に設定してください. この変数のデフォルト値は, "" になっています (つまり, 英語のみ). これは, 全部をまとめた例です. MAN1= foo.1 MAN3= bar.3 MAN4= baz.4 MANLANG= "" ja MAN3PREFIX= ${PREFIX}/share/foobar MANCOMPRESSED= yes 以下の6個のファイルがこの port でインストールされます. ${PREFIX}/man/man1/foo.1.gz ${PREFIX}/man/ja/man1/foo.1.gz ${PREFIX}/share/foobar/man/man3/bar.3.gz ${PREFIX}/share/foobar/man/ja/man3/bar.3.gz ${PREFIX}/man/man4/baz.4.gz ${PREFIX}/man/ja/man4/baz.4.gz Motifを必要とするport 最近はコンパイルに Motif を必要とするアプリケーションが増えて きました. (Motif自体は有料のものがいくつかの会社から手に入りま すし, 多くのアプリケーションがコンパイル可能な無料の互換ライブラリ が x11-toolkits/lesstifにあります) Motifはかなり広く使われていますし, 製品のライ センスではライブラリを静的にリンクした 実行形式は再配布が認めら れている場合が多いので, Motifを必要とするソフトウェアを簡単に 動的(port からコンパイルする人々のために)/静的(package を配布 する人々のために)にリンクできるような しくみが用意されています. <makevar>REQUIRES_MOTIF</makevar> Motif がないとコンパイルできないportのMakefileではこの変 数を指定してください. これによって, Motifを持っていない人が このportをコンパイルしようとするのを未然に防ぎます. <makevar>MOTIFLIB</makevar> この変数は bsd.port.mk によって Motif ライブラリの指 定に置き換えられます. ソース内のMakefileやImakefileで Motif ライブラリを指定しているところをこの変数に置き換えるよ うにパッチをあててください. 代表的な例としては以下の二つがあげられます: MakefileかImakefileの中でMotifライブラリが として使われている場合には, かわりに MOTIFLIB と書いてください. Imakefileの中で XmClientLibs が使われている 場合には, それを ${MOTIFLIB} ${XTOOLLIB} ${XLIB} と書きかえてください. MOTIFLIB は通常 -L/usr/X11R6/lib -lXm か /usr/X11R6/lib/libXm.a に置き換えら れます. したがって前に や をつけ る必要はありません. X11 のフォント もし, あなたの port が X window system のフォントをインストールするのであれば, それらを X11BASE/lib/X11/fonts/local に置くようにしてください. このディレクトリは XFree86 release 3.3.3 で新設されたものです. もし, それが存在しなければ作成し, ユーザに XFree86 を 3.3.3 かそれより新しいものに更新か, すくなくとも, このディレクトリを /etc/XF86Config の font path に加えるように促すメッセージを出力するようにしてください. Info ファイル 新しい版の texinfo(2.2.2-RELEASE およびそれ以降に入っています) には, install-info というコマンドが含まれており, dir ファイルに項目を追加したり, 削除したりすることがで きます. もし, あなたの port が info ドキュメントをインストー ルするのであれば, 以下の指示に従って, その port および package が正しく, ユーザの ${PREFIX}/info/dir ファイル を更新するようにしてください. (この節は, とても長くてすいません, しかし info ファイルを作りあげるためには, これらは不可欠 です. 正しく行なえば, 美しい リストができますので, 辛抱してください! :) まず, これを知っておかなければなりません: &prompt.user; install-info --help install-info [OPTION]... [INFO-FILE [DIR-FILE]] Install INFO-FILE in the Info directory file DIR-FILE. (訳注: Info ディレクトリの INO-FILE を DIR-FILE にインストールする) Options: --delete Delete existing entries in INFO-FILE; don't insert any new entries. (訳注: INFO-FILE の中の項目を削除, 新しい項目は一切追加しない.) : --entry=TEXT Insert TEXT as an Info directory entry. (訳注: TEXT を Info ディレクトリの項目として追加する.) : --section=SEC Put this file's entries in section SEC of the directory. (訳注: このファイルの項目を Info ディレクトリの SEC という節に置く.) : このプログラムは, 実際には info ファイルをインストール しません, 単に dir ファイルにエントリーを挿入したり削除し たりするだけです. これから, install-info を使用するように, ports を変換す る7段階の工程を示します. 例として editors/emacsを 使用します. まず, texinfo のソースを見て, @dircategory と @direntry 文がないファイルについて, それらを追加するパッチを作成します. 以下は, ここでの例での patchの一部です: --- ./man/vip.texi.org Fri Jun 16 15:31:11 1995 +++ ./man/vip.texi Tue May 20 01:28:33 1997 @@ -2,6 +2,10 @@ @setfilename ../info/vip @settitle VIP +@dircategory The Emacs editor and associated tools +@direntry +* VIP: (vip). A VI-emulation for Emacs. +@end direntry @iftex @finalout : フォーマットについては見ればわかると思います. dir というファイルに必要な項目を書いておいてくれる作者 も多いので, まず自分で書く前にさがしてみてください. また, 関係 する ports も調べて, 節(section)の名前や, インデントなどが きちんと合っているかどうかを確認してください (項目のテキスト は, すべて4つめのタブ・ストップ(tab stop)から始めることを推 奨します). 1つのファイルに対して1つの info の項目しか書けないことに注 意してください, これは, install-info --delete が, そのバグにより, @direntry セクションに複数の項目を書 いても, 初めの1つの項目しか削除してくれないからです. texinfo のソースにパッチをあてるかわりに, dir の項目 を install-info の 引数((, ) として与えることもできます. これはあまり良い方法とは 思えません, なぜなら, 同じ情報を3ヶ所(Makefile, PLIST の @exec/@unexec: 以下参照) に重複して, 書く必要があるからです. しかしながら, もし日本語(あるいは, 他のマルチバイト文字)の info ファイルがあるのならば, install-info の特別な引数を使用する必要があるでしょう, なぜならば, makeinfo がこのような texinfo ソースファイル を扱えないからです. (このようなものをどう扱うかの例としては, japanese/skk の Makefile と PLIST を見て ください.) portのディレクトリに戻って, make clean; make をして, info ファイルが texinfo ソースファイルから再び生成さ れることを確認してください. texinfo ソースファイルのほうが info ファイルよりも新しいので, make とタイプすれば, info ファイルは再構築されるはずですが, 多くの Makefile には info ファイルの正しい依存関係が書かれていません. emacs の場合, info ファイルの再構築ため, man サブディレクトリ に降りていくようにするために, メインの Makefile.in にパッ チをあてる必要がありました. --- ./Makefile.in.org Mon Aug 19 21:12:19 1996 +++ ./Makefile.in Tue Apr 15 00:15:28 1997 @@ -184,7 +184,7 @@ # Subdirectories to make recursively. `lisp' is not included # because the compiled lisp files are part of the distribution # and you cannot remake them without installing Emacs first. -SUBDIR = lib-src src +SUBDIR = lib-src src man # The makefiles of the directories in $SUBDIR. SUBDIR_MAKEFILES = lib-src/Makefile man/Makefile src/Makefile oldXMenu/Makefile lwlib/Makefile --- ./man/Makefile.in.org Thu Jun 27 15:27:19 1996 +++ ./man/Makefile.in Tue Apr 15 00:29:52 1997 @@ -66,6 +66,7 @@ ${srcdir}/gnu1.texi \ ${srcdir}/glossary.texi +all: info info: $(INFO_TARGETS) dvi: $(DVI_TARGETS) man サブディレクトリでのデフォルトターゲットは, info で呼ばれるのに対して, メインの Makefile では, all で呼びたいので, 2つめのpatchが必要でした. また, info info ファイルのインストールも削除しました, なぜなら, 同じものが同じ名前で既に /usr/share/info にあるからです. (このパッチはここにはありません.) もし, Makefile に dir ファイルをインストールす る個所があれば, 削除します. あなたの port がインストー ルしてはいけません. また, dir ファイルを壊してしまうよう なコマンドの類も削除します. --- ./Makefile.in.org Mon Aug 19 21:12:19 1996 +++ ./Makefile.in Mon Apr 14 23:38:07 1997 @@ -368,14 +368,8 @@ if [ `(cd ${srcdir}/info && /bin/pwd)` != `(cd ${infodir} && /bin/pwd)` ]; \ then \ (cd ${infodir}; \ - if [ -f dir ]; then \ - if [ ! -f dir.old ]; then mv -f dir dir.old; \ - else mv -f dir dir.bak; fi; \ - fi; \ cd ${srcdir}/info ; \ - (cd $${thisdir}; ${INSTALL_DATA} ${srcdir}/info/dir ${infodir}/dir); \ - (cd $${thisdir}; chmod a+r ${infodir}/dir); \ for f in ccmode* cl* dired-x* ediff* emacs* forms* gnus* info* message* mh-e* sc* vip*; do \ (cd $${thisdir}; \ ${INSTALL_DATA} ${srcdir}/info/$$f ${infodir}/$$f; \ chmod a+r ${infodir}/$$f); \ (これは, 既存のportを修正するときのみ必要です.) pkg/PLIST を見て, info/dir にパッチをあて ようとするものすべてを削除します. これらは, pkg/INSTALL やその他のファイルにもあるかもしれない ので, いろいろさがしてみてください. Index: pkg/PLIST =================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v retrieving revision 1.15 diff -u -r1.15 PLIST --- PLIST 1997/03/04 08:04:00 1.15 +++ PLIST 1997/04/15 06:32:12 @@ -15,9 +15,6 @@ man/man1/emacs.1.gz man/man1/etags.1.gz man/man1/ctags.1.gz -@unexec cp %D/info/dir %D/info/dir.bak -info/dir -@unexec cp %D/info/dir.bak %D/info/dir info/cl info/cl-1 info/cl-2 post-install ターゲットを Makefile に加えて, dir ファイルが存在しなければ作成するようにします. また, インストールされた info ファイルについては, install-info を実行するようします. Index: Makefile =================================================================== RCS file: /usr/cvs/ports/editors/emacs/Makefile,v retrieving revision 1.26 diff -u -r1.26 Makefile --- Makefile 1996/11/19 13:14:40 1.26 +++ Makefile 1997/05/20 10:25:09 1.28 @@ -20,5 +20,11 @@ post-install: .for file in emacs-19.34 emacsclient etags ctags b2m strip ${PREFIX}/bin/${file} .endfor + if [ ! -f ${PREFIX}/info/dir ]; then \ + ${SED} -ne '1,/Menu:/p' /usr/share/info/dir > ${PREFIX}/info/dir; \ + fi +.for info in emacs vip viper forms gnus mh-e cl sc dired-x ediff ccmode + install-info ${PREFIX}/info/${info} ${PREFIX}/info/dir +.endfor .include <bsd.port.mk> 新しい info ファイルを作成するのに, /usr/share/info/dir と上のコマンド, 以外は使用しな いでください. 実際のところ, もし port する人がこれに関して PLIST に自らまったく手を加える必要がないのであれば, 上 のパッチのはじめの3行を bsd.port.mk に加えたでしょう. PLIST を編集して, 同じ働きをする @exec 文, そ れにpkg_delete のために @unexec 文を加えてくださ い. @unexec を使用して info/dir を削除する必 要はありません. Index: pkg/PLIST =================================================================== RCS file: /usr/cvs/ports/editors/emacs/pkg/PLIST,v retrieving revision 1.15 diff -u -r1.15 PLIST --- PLIST 1997/03/04 08:04:00 1.15 +++ PLIST 1997/05/20 10:25:12 1.17 @@ -16,7 +14,15 @@ man/man1/etags.1.gz man/man1/ctags.1.gz +@unexec install-info --delete %D/info/emacs %D/info/dir : +@unexec install-info --delete %D/info/ccmode %D/info/dir info/cl info/cl-1 @@ -87,6 +94,18 @@ info/viper-3 info/viper-4 +@exec [ -f %D/info/dir ] || sed -ne '1,/Menu:/p' /usr/share/info/dir > %D/info/dir +@exec install-info %D/info/emacs %D/info/dir : +@exec install-info %D/info/ccmode %D/info/dir libexec/emacs/19.34/i386--freebsd/cvtmail libexec/emacs/19.34/i386--freebsd/digest-doc @unexec install-info --delete コマンドは, info ファイル自身より先に置き, コマンドがファイルを読めるようにし ておかなければならないことに注意してください. また, @exec install-info コマンドは info ファイルおよび dir ファイルを作る @exec コマンドより後に おかなければなりません. テスト をして出来栄えに感服しましょう :) 各段階の前後に, dir ファイルをチェックしましょう. <filename>pkg/</filename> サブディレクトリ まだ触れていない, いくつかのこつが pkg/ サブディレクトリにはあり, 時として便利でしょう. <filename>MESSAGE</filename> もし, インストールする人にメッセージを表示する 必要がある場合には, そのメッセージを pkg/MESSAGE に置けます. この機能は, pkg_add の後の追加のインストール手続きを表示するときなどに, 重宝します. pkg/MESSAGE ファイルは pkg/PLIST に加える必要はありません. また, もしユーザが package ではなく port を使用して いる場合には自動的には表示されませんので, 明示的に post-install で表示するようにするべきでしょう. <filename>INSTALL</filename> バイナリパッケージが pkg_add でインストールされるときに, 実行される必要がある コマンドがあれば, pkg/INSTALL スクリプトを使って実行することができます. このスクリプトは自動的に package に加えられ, pkg_add によって2度実行されます. はじめは INSTALL ${PKGNAME} PRE-INSTALL と実行され, 2度目には, INSTALL ${PKGNAME} POST-INSTALL と実行されます. どちらのモードで実行されているかは, $2 を調べることによってわかります. 環境変数 PKG_PREFIX には package がインストールされるディレクトリが設定されます. 詳細は &man.pkg.add.1; を見てください. port を make install で インストールするときには, このスクリプトは自動的に実行されません. もし, 実行される必要があるならば, port の Makefile から明示的に呼ぶ必要があります. <filename>REQ</filename> port が(インストールされるシステムの状態によって) インストールされるべきか, されないべきか区別する必要が あるときには, “要件(requirements)” スクリプト pkg/REQ を作ることができます. これは, インストール及びデインストール (package の削除)の時に自動的に実行され, それらが処理されるべきかを決定します. make の変数にあわせた <filename>PLIST</filename> の変更 いくつかの port, 特に p5- portsなど, は configure のオプション (あるいは, p5- ports の場合は perl のバージョン)によって, PLIST を変える必要があります. これを容易に実現するために, PLIST 中の %%OSREL%%, %%PERL_VER%%, %%PERL_VERSION%% は, 適切に置き換えられるようになっています. %%OSREL%% の値は, オペレーティングシステムの数字で表されたリビジョンです (例えば, 2.2.7). %%PERL_VERSION%% は perl のバージョン番号全体(例えば, 5.00502 )で, %%PERL_VER%% はバージョン番号から, パッチレベルを引いてものです(例えば, 5.005). 他の置き換えが必要であれば, PLIST_SUB 変数に VAR=VALUE という形式のペアのリストを設定することによって, PLIST 中の %%VAR%% は VALUE に置き換えられます. 例えば, バージョンに固有の沢山のファイルを インストールする場合には, Makefile に OCTAVE_VERSION= 2.0.13 PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} と書いて, PLIST 中のバージョン番号が表われるすべてのところに, %%OCTAVE_VERSION%% と書きます. このようにしておけば, port をアップグレードするときに, 何十行(ときとして, 何百行)も PLIST を書き替えないですみます. この書き換えは ( マニュアル の追加も) do-install と post-install ターゲット のあいだに, PLIST を読み TMPPLIST (デフォルトは, WRKDIR/.PLIST.mktmp ) に書き込むことによって行なわれます. もし, あなたの port が PLIST を実行時に生成するのであれば, do-install のあいだか, その前に行うようにしてください. また, 書きかえられたあとのファイルを編集する必要がある場合には, post-install で, TMPPLIST を書きかえてください. <filename>pkg</filename> サブディレクトリにあるファイル名の変更 pkg サブディレクトリにあるファイルは全て, 変数を 使用して定義されていますので, 必要であれば Makefile 中で 変更可能です. いくつかの ports で 一つの pkg サブディレクトリを共有する場合や, 上記のファイルに書き込む 必要があるときなど, 特に便利です. (pkg サブディレクトリに直接書き込むのが良くない理由に ついては WRKDIR 以外への書きこみ を参照してください.) 以下が変数名とそのデフォルト値の表です. Variable Default value COMMENT ${PKGDIR}/DESCR DESCR ${PKGDIR}/DESCR PLIST ${PKGDIR}/PLIST PKGINSTALL ${PKGDIR}/PKGINSTALL PKGDEINSTALL ${PKGDIR}/PKGDEINSTALL PKGREQ ${PKGDIR}/REQ PKGMESSAGE ${PKGDIR}/MESSAGE PKG_ARGSを上書きせずに, これらの変数を変更 するようにしてください. PKG_ARGSを変更すると これらのファイルは port から正しく /var/db/pkg にインストールされなくなります. ライセンス上の問題 ソフトウェアによっては制限の厳しい ライセンスがついてきたり, 法律的に問題があるかもしれません. (PKPの公開鍵暗号化, ITAR (暗 号化ソフトウェアの輸出) などが例としてあげられます). それらを どう扱えばいいかはライセンスの文面によって さまざまな場合があり ます. ソフトウェア移植者として, あなたにはライセンスをよく読み, FreeBSD プロジェクトが FTP または CD-ROM で配布してはいけないソフ トウェアを配布してしまうことのないよう, 注意する義務があります. なにか疑問がある場合には, &a.ports;に聞いてみてください. よく見られるケースに対処するために, 二つの変数が用意されてい ます: ソフトウェアに “有償再配布を禁ずる” という趣旨のライセン スがついてきた場合には NO_CDROM という変数にその理由を記述して ください. 私たちはこれがついているportはCD-ROMリリースに入 れないようにしますが, オリジナルのソースファイルとpackage はFTPでは取れるようにしておきます. もしも, 生成される package が個々のサイトで独自に構築さ れる必要があったり, ライセンスによって生成されるバイナリが 配布できない場合には, NO_PACKAGE 変数にその理由を記述してくだ さい. そのような package が FTP サイトに置かれたり, リリース 時の CD-ROM へ入らないようにします. ただし, いずれの場合も distfile は(FTP や CD-ROM に)含まれるようになります. Portが, 使用者によっては法律上の問題が生じる時 (暗号化ソフ トウェアなど), または“商用利用を禁ずる”とライセンスに書い てある場合には RESTRICTEDという変数にその理由を入れ てください. この場合には, ソースファイルやpackageは私たちの FTPサイトにも置かれません. GNU一般公有使用許諾書 (GPL) はバージョン1, 2とも port作成上は何ら問題にはなりません. もしあなたが，ソースツリー管理者 (committer) であれば， ソースツリーにこのようなportを入れる際に, ports/LEGAL ファイルを書き換えるのを忘れないようにし てください. アップグレード Port のバージョンが原作者からのものに比べて古いことに気がつ いたら, まずはあなたの持っているportが私たちの最新のもの (ミラー サイトの ports/ports-current というディレクトリにあります) であることを確認してください. 次に, portの Makefile にMAINTAINER (保守担当者) の アドレスが書いてある場合には, その人にメールを出してみましょう. 保守担当者の人がすでにアップグレードの準備を しているかもしれま せんし, (新しいバージョンの安定度に問題があるなど) あえてアッ プグレードをしない理由があるのかもしれません. 保守担当者にアップグレードをしてくれと頼まれた場合, あるいは そもそもportのMakefileに保守担当者が書いてない場合などは, あ なたがアップグレードをしてくださると助かります. その場合にはアッ プグレードをしたのち, 変更前と変更後のディレクトリの再帰的diff (unified diff と context diff のどちらでもいいのですが, port のコミッター達は unified diff のほうを好むようです) をとって送ってください. (例えば, 変更前のディレクトリが superedit.bak という名前でとってあり, 変更後のもの が superedit に入っているなら, diff -ruN superedit.bak superedit の結果を送ってください. ) diff の出力を見て, すべての変更が正しくなされているか確認して ください. 変更箇所については, &man.send-pr.1; (カテゴリーは, ports)に diff の出力結果を添えて, 私たちに送ってもらうのが一 番よいです. commit する際に CVS に明確に記述しなければならない ので, 付け加えたり削除したりしたファイルがあったら, それについ て書いておいてください. もし diff の大きさが 20 KB 程度を 超えるようであれば, 圧縮したものを uuencode して下さい. そうでなければそのまま PR に入れるだけでいいです. 繰り返しになりますが, ports の変更を送るときには, &man.shar.1; ではなく &man.diff.1; を使用してください. やっていいことといけないこと この節では, ソフトウェアをportする上でよくある落し穴などにつ いて説明します. このリストを使って, あなた自身が作成した port のチェックはもとより, PR データベースにある, 他の人が作成した port のチェックもできます. あなたがチェックした port について のコメントを バグ報告と一般的な論評 にしたがって, 送ってください. PR データベースにある port を チェックすることによって, 私達がそれらを commit するのを早くし, あなたが何をしているか理解していることも示します. バイナリのstrip バイナリは strip してください. オリジナルのソースがバイナリを strip してくれる場合は良いですが, そうでない場合には post-install ターゲットを指定して strip するようにするとよいでしょう. 例えば, こんな風になります: post-install: strip ${PREFIX}/bin/xdl インストールされた実行形式がすでに strip されているかどうかは file コマンドで確認できます. これが`not stripped'と言わなければ, stripされているということです. <makevar>INSTALL_*</makevar> マクロ あなた自身の *-install ターゲットでファイルの正しいモードと オーナを保証するために, 必ずbsd.port.mkで提供されて いるマクロを使用してください. マクロは以下のようなものがあります. ${INSTALL_PROGRAM} は実行可能なバイナリを インストールするコマンドです. ${INSTALL_SCRIPT} は実行可能なスクリプトを インストールするコマンドです. ${INSTALL_DATA} は共有可能なデータを インストールするコマンドです. ${INSTALL_MAN} はマニュアルとその他のドキュメ ントをインストールするコマンドです. (圧縮はしません) これらは基本的に install コマンドに適当なフラグを与え たものです. どのようにこれらを使用するかは以下の例を見てください. <makevar>WRKDIR</makevar> WKRDIR の外のファイルにはなにも書き込まないように してください. WRKDIR は ports のビルド中に書き込こめる ことが保証されている唯一の場所です( CDROM から ports をコンパイルを参照). PKGDIR にあるファイルを修正する必要がある ときには, 変数の再定義 によって行ない, 上書きはしないでください. <makevar>WRKDIRPREFIX</makevar> WRKDIRPREFIX を尊重していることを確認してください. 特に, 別の port の WRKDIR を参照している ときには気を付けてください. 正しい場所は, WRKDIRPREFIX PORTSDIR /subdir/ name/work, です, PORTSDIR/subdir/ name/work とか .CURDIR/../../subdir /name/work とかではありません. また, 自分で WRKDIR 定義するときには, 頭に ${WRKDIRPREFIX}${.CURDIR} が付いている 事を確認してください. OS や OS のバージョンの区別 Port の過程で, 修正や, どのバージョンの UNIX で動くかによる条件つきコンパイルなどが 必要なコードに出会うかもしれません. そのような条件つきコンパイルなどのための 変更をおこなうときには, FreeBSD 1.x システムへの移植や, CSRGの4.4BSD, BSD/386, 386BSD, NetBSD, OpenBSD などの他のBSDシステムへの移植が可能なように, できるだけ普遍的な変更をおこなうことを 心がけてください. 4.3BSD/Reno (1990) およびそれより新しい BSD 版を古いバージョンと区別するには BSD マクロを利用するのがよいでしょう. これは <sys/param.h> で定義されています. このファイルがすでにインクルードされていればよいのですが, もしそうでない場合には以下のコードを, その .c ファイルの適当な場所に加えてください. #if (defined(__unix__) || defined(unix)) && !defined(USG) #include <sys/param.h> #endif これらの 2 つのシンボルが定義されているすべてのシステムには sys/param.h があるはずです. もし, そうでないシステムを発見したら我々にも教えてください. &a.ports; までメールを送ってください. あるいは, GNU の Autoconf のスタイルを使用することもできます, #ifdef HAVE_SYS_PARAM_H #include <sys/param.h> #endif この方法を使用するときには, Makefile 中の CFLAGSに -DHAVE_SYS_PARAM_H を加えることを忘れないようにしてください. いったん sys/param.h がインクルードされると, #if (defined(BSD) && (BSD >= 199103)) このようにしてそのコードが 4.3 Net2 コードベース, またはそれより新しいもの (例: FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1とそれ以前) の上でコンパイルされているかを検出できます. #if (defined(BSD) && (BSD >= 199306)) これは, 4.4コードベース, またはそれより新しいもの (例: FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0とそれ以後) の上でコンパイルされているかどうかを 検出するために使用します. 4.4BSD-Lite2 コードベースでは, BSD マクロの値は 199506 になっています. これは参考程度の意味合いしかありません. 4.4-Lite ベースの FreeBSD と 4.4-Lite2 での変更がマージされたバージョンとを 区別するのに使用するべきものではありません. この目的のためには, __FreeBSD__ マクロをかわりに使用してください. 以下は控え目に使ってください. __FreeBSD__ はFreeBSDのすべての版で定義されています. 変更が FreeBSD だけに適用されるとき以外は使用しないでください. Portでよくある, strerror() ではなく sys_errlist[] を使うなどは, FreeBSDでの変更ではなく, BSD の流儀です. FreeBSD 2.xでは __FreeBSD__ が 2 と定義されています. それ以前の版では 1 になっています. その後の版では, そのメジャー番号に合うように上がっていきます. もし, FreeBSD 1.x システムと FreeBSD 2.x あるいは FreeBSD 3.x システムを区別する必要があれば, 上で述べた BSDマクロを使用するのが, 大抵の場合において正しい答です. もし, FreeBSD特有の変更であれば (ld を使うときのシェアードライブラリ用のなオプションなど), __FreeBSD__を使い #if __FreeBSD__ > 1 のようにFreeBSD 2.x および, それ以降のシステムを検出するのはかまいません. もし, 2.0-RELEASE以降のFreeBSDシステムを細かく検出したけれ ば, 以下を使用することができます. #if __FreeBSD__ >= 2 #include <osreldate.h> # if __FreeBSD_version >= 199504 /* 2.0.5+ release specific code here */ # endif #endif Release - _FreeBSD_version + __FreeBSD_version 2.0-RELEASE 119411 2.1-CURRENT's 199501, 199503 2.0.5-RELEASE 199504 2.1 以前の 2.2-CURRENT 199508 2.1.0-RELEASE 199511 2.1.5 以前の 2.2-CURRENT 199512 2.1.5-RELEASE 199607 2.1.6 以前の 2.2-CURRENT 199608 2.1.6-RELEASE 199612 2.1.7-RELEASE 199612 2.2-RELEASE 220000 2.2.1-RELEASE 220000 (2.2-RELEASE と同じです) 2.2.1-RELEASE 以後の 2.2-STABLE 220000 (これも同じです) texinfo-3.9 以後の 2.2-STABLE 221001 top 導入以後の 2.2-STABLE 221002 2.2.2-RELEASE 222000 2.2.2-RELEASE 以後の 2.2-STABLE 222001 2.2.5-RELEASE 225000 2.2.5-RELEASE 以後の 2.2-STABLE 225001 ldconfig -R 以後の 2.2-STABLE 225002 2.2.6-RELEASE 226000 2.2.7-RELEASE 227000 2.2.7-RELEASE 以後の 2.2-STABLE 227001 semctl(2) 変更後の 2.2-STABLE 227002 2.2.8-RELEASE 228000 2.2.8-RELEASE 以後の 2.2-STABLE 228001 mount(2) 変更以前の 3.0-CURRENT 300000 mount(2) 変更以後の 3.0-CURRENT 300001 semctl(2) 変更以後の 3.0-CURRENT 300002 ioctl 引数変更後の 3.0-CURRENT 300003 ELF 移行後の 3.0-CURRENT 300004 3.0-RELEASE 300005 3.0-RELEASE 以後の 3.0-CURRENT 300006 3/4 の分岐後の 3.0-STABLE 300007 3.1-RELEASE 310000 3.1-RELEASE 以後の 3.1-STABLE 310001 3/4 の分岐後の 4.0-CURRENT 400000 (2.2-STABLE は, 2.2.5-RELESE 以後, “2.2.5-STABLE” と呼ばれることがあります.) 見ての通り, これは年・月というフォーマットになっていましたが, バージョン 2.2 から, より直接的にメジャー/マイナー番号を使う ように変更になりました. 並行していくつかのブランチ(枝分かれし たバージョン)を開発する場合には, リリースされた日付でそれらの リリースを分類することが不可能だからです. (あなたが今 port を作成するときに, 古い -CURRENT 達について心配 する必要はありません. これは参考のために挙げられているにすぎま せん.) これまで, 何百ものportが作られてきましたが, __FreeBSD__ が正しく使われたのは, 1つか2つの場合だけでしょう. 以前のportが誤った場所でそのマクロを使っているからと いって, それをまねする理由はありません. <filename>bsd.port.mk</filename> の後に書くこと .include <bsd.port.mk> の行の後には なにも書かないようにしてください. 大抵の場合は Makefile の 中程のどこかで, bsd.port.pre.mk を include して, 最後に bsd.port.pre.mk を include することによって避けることができます. pre.mk/post.mk のペアか bsd.port.mk だけのどちらかだけを include してください. 2つを混ぜないでください. 前者は, いくつかの変数の定義だけ をして, Makefile でのテストに使用し, 後者は残りを定義します. 以下は bsd.port.pre.mk で定義される重要な変数です. (これは, すべてではありません. 完全なリストは bsd.port.mk を参照してください.) 変数名 解説 ARCH uname -m で返される アーキテクチャ. (例, i386). OPSYS uname -s で返される オペレーティングシステム (例, FreeBSD). OSREL オペレーティングシステムの リリースバージョン (例., 2.1.5, 2.2.7). OSVERSION 数字形式のオペレーティングシステム のバージョン, 上記の __FreeBSD_version と同じです. PORTOBJFORMAT システムのオブジェクト フォーマット (aout あるいは elf). LOCALBASE “local” ツリーのベース. (例, /usr/local/). X11BASE “X11” ツリーのベース. (例, /usr/X11R6/). PREFIX portsのインストール先 ( PREFIXについてを参照). USE_IMAKE, USE_X_PREFIX あるいは MASTERDIR などの変数を定義する必要がある場合には, bsd.port.pre.mk を include する前に定義してください. 他のものは, bsd.port.pre.mk の前でも後でもかまいません. 以下は bsd.port.pre.mk の後に書けるものの例です: # no need to compile lang/perl5 if perl5 is already in system .if ${OSVERSION} > 300003 BROKEN= perl is in system .endif # only one shlib version number for ELF .if ${PORTOBJFORMAT} == "elf" TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR} .else TCL_LIB_FILE= ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR} .endif # software already makes link for ELF, but not for a.out post-install: .if ${PORTOBJFORMAT} == "aout" ${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so .endif 付加的ドキュメント 普通のマニュアルや info ファイルのほかにユーザにとって有用だ と思えるようなドキュメントがある場合には, PREFIX/share/doc の下にインストールしてく ださい. これは前記と同様, post-installターゲットの 中からするのがいいでしょう. まず, あなたのportのために新しいディレクトリを作りま す. どのportのドキュメントか簡単にわかるような名前にする必 要がありますので, 普通は PKGNAME からバージョ ン番号を除いた部分を使うといいでしょう. もちろん, ユーザが異 なるバージョンのものを同時に使うことが予想される port の場合 には, PKGNAME をそのまま使ってかまいません. ユーザが /etc/make.conf でこの部分を禁止するために NOPORTDOCS という変数をセットしている場合には， これらのドキュメントが インストールされないようにしてください. こんな具合です. post-install: .if !defined(NOPORTDOCS) ${MKDIR}${PREFIX}/share/doc/xv ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv .endif これらのファイルを pkg/PLIST に入れるのを忘れないよ うにしてください. (packageが/etc/make.conf内の 変数を読む方法は今のところ存在しませんので, NOPORTDOCS については気にしないでください.) インストール時に pkg/MESSAGE ファイルを利用して, メッセージを表示することができます. 詳細は pkg/MESSAGE を使う の節を参照してください. MESSAGE ファイルは pkg/PLIST に加える必要はありま せん. <makevar>DIST_SUBDIR</makevar> /usr/ports/distfiles ディレクトリ内をあまり散らかさ ないようにしてください. たくさんのファイルを取ってくるport や, 数は少なくてもほかのportのファイルと混同されるおそれが あるファイル (Makefile など) がある場合には, DIST_SUBDIR に port の名前 (PKGNAME からバージョン番号を取った部分を 使うといいでしょう) を入れてください. すると, DISTDIRがデフォルトの /usr/ports/distfiles から /usr/ports/distfiles/DIST_SUBDIR に変更され, 取ってきたファイルはすべてそのサブディレクトリの中に置か れるようになります. また, ファイルを取ってくるときにバックアップサイトとして使わ れる ftp.freebsd.org のディレクトリ名にもこの変数の 値が使われます. (DISTDIRを明示的に指定し た場合には, ローカルのファイルを置くところは変わりますが, こ のサイトのディレクトリ名は変わりませんので, 必ず DIST_SUBDIRを使うようにしてください.) この変数はMakefile中で明示的に指定された MASTER_SITES には影響しないことに注意して ください. RCS文字列 RCS が特別な意味を与えている文字列をパッチ内に入れないように してください. ファイルを私たちのソースツリーに入れる時にこれら の文字列はCVSによって書き換えられてしまい, あとでまたパッチ を使おうとした時にうまくいかないことがあります. RCS文字列は ドル記号 ($) で囲まれており, $Id や $RCS などで始まり ます. パッチ作成上の注意 diffの再帰 () フラグを使って再帰的なパッ チを作るのは大変結構なのですが, でき上がったパッチは必ず目で チェックして余計なゴミが入っていないことを確認してくださ い. よくあるのはバックアップファイル同士の変更点, あるいは Imake や GNU configure を使うソフトウェアの Makefile の変更点が入っている場合などです. また, configure.in を編集して, autoconf を使って configure を作り直す ときには, configure の diff は含めずに (それらは, 数千行になることもしばしばです), USE_AUTOCONF=yes を定義して, configure.in の diff をとってください. ファイルをまるごと消す場合にはパッチを使わずに post-extract ターゲットで消す方が簡単です. できあがった 差分に満足したら, それらをソースのファイルごとに別々の パッチファイルに分割してください. <makevar>PREFIX</makevar> なるべく port は PREFIX に対する相対パス にインストールすることができるように心がけてください. (この変数の値は USE_X_PREFIXか USE_IMAKEが指定してある時には X11BASE (デフォルト/usr/X11R6), そうでない場合にはLOCALBASE (デフォルト/usr/local) にセットされます.) サイトによってフリーソフトウェアが インストールされる場所が 違いますので, ソース内で /usr/local や /usr/X11R6 を明示的に書かないようにしてください. X のプログラムで imake を使うものについては, これは問題に はなりません. それ以外の場合には, ソース中のMakefileやスク リプトで /usr/local (imakeを使わないXのプログラ ムは /usr/X11R6) と書いてあるところを PREFIX に書き換えてください. この値は portのコンパイル, およびインストール時に自動的に環境変数として 下位makeに渡されます. USE_X_PREFIXは本当に必要な時 (つまり, X のライブラリなどとリンクしたり, X11BASE 以下にある ファイルを参照したりする必要がある時) 以外には設定しないでください. 変数 PREFIX の値は port の Makefile やユーザの環境で変更することもできます. しかし, 個々の port が Makefile でこの変数の値を明示的に設定することはなるべくしない でください. また, 他の port からインストールされるプログラムやファイル を指定するときには, 上で述べた変数を使用してください. 例えば, less のフルパスを PAGER というマクロに入れた い場合は, コンパイラに -DPAGER=\"/usr/local/bin/less\" と渡すかわりに -DPAGER=\"${PREFIX}/bin/less\" (Xを使うportの時は -DPAGER=\"${LOCALBASE}/bin/less\" ) を渡し てください. こうしておけば, `/usr/local' がまるごとどこか他 の場所に移してあるサイトでも, あなたのportがそのまま使える 可能性が高くなります. ディレクトリ構成 インストール時には PREFIX の正しいサブディ レクトリにファイルを置くように心がけてください. ソフトウェア によっては新しいディレクトリを 一つ作ってファイルを全部それに 入れてしまうものがありますが, それはよくありません. また, バ イナリ, ヘッダファイルとマニュアル以外のすべてを lib というディレクトリに入れてしまうportもあります が, これもBSD的なファイルシステム構成からいうと正しくありま せん. これは以下のように分散すべきです. etc にセッ トアップ/コンフィグレーションファイル, libexec に 内部で使用されるプログラム (コマンドラインから呼ばれることの ないコマンド), sbin に管理者用のコマンド, info に GNU Info 用のドキュメント, そして share にアーキテクチャに依存しないファイルが入り ます. 詳細については man &man.hier.7; を見てくださ い. /usrの構成方針はほとんどそのまま /usr/localにもあてはまります. USENET “ニュース”を 扱う ports は例外です. これらは, ファイルのインストール先として PREFIX/news を使用します. 空のディレクトリの除去 ports は デインストール(削除) の際には, 自分自身を消去したあとに, (ディレクトリの) 除去をするようにしてください. これは, 大抵の場合 @dirrm の行を ports が作成するすべてのディレクトリについて 加えることによって実現できます. 親ディレクトリは, 子ディレクトリを先に消さないと 消せないことに気をつけて下さい. : lib/X11/oneko/pixmaps/cat.xpm lib/X11/oneko/sounds/cat.au : @dirrm lib/X11/oneko/pixmals @dirrm lib/X11/oneko/sounds @dirrm lib/X11/oneko といった感じです. しかし, ときとして, 他の port をディレクトリを共有しているために @dirrm がエラーを返すことがあります. rmdir を @unexec から呼びだすことによって, 警告(warning)なしで 空のディレクトリのみを削除することができます: @unexec rmdir %D/share/doc/gimp 2>/dev/null || true これを使えば, たとえ, 他の port がファイルを インストールしていて, PREFIX/share/doc/gimp が空でない場合でも エラーメッセージは表示されませんし, pkg_delete が異常終了することもありません. UID もしあなたの portがインストールされるシステム上に特定のユー ザを必要とする場合は, pkg/INSTALL スクリプトから pw コマンドを実行して自動的にそのユーザを追加するよ うにしてください. net/cvsup-mirror の portが参考になるでしょう. もしあなたの port が, バイナリのパッケージとしてとして インストールされるときにも, コンパイルされたときと同じユーザー/グループ ID を使わなければならないのなら, 50 から 99 の間で空いている UID を選んで登録してください. japanese/Wnn の port が参考になるでしょう. 既にシステムや他の portで利用されている UIDを使わないように 十分注意してください. 現在の 50から 99までの間の UIDは以下の とおりです. majordom:*:54:54:Majordomo Pseudo User:/usr/local/majordomo:/nonexistent cyrus:*:60:60:the cyrus mail server:/nonexistent:/nonexistent gnats:*:61:1:GNATS database owner:/usr/local/share/gnats/gnats-db:/bin/sh uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67:X-10 daemon:/usr/local/xten:/nonexistent pop:*:68:6:Post Office Owner (popper):/nonexistent:/nonexistent wnn:*:69:7:Wnn:/nonexistent:/nonexistent ifmail:*:70:66:Ifmail user:/nonexistent:/nonexistent pgsql:*:70:70:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh ircd:*:72:72:IRCd hybrid:/nonexistent:/nonexistent alias:*:81:81:QMail user:/var/qmail/alias:/nonexistent qmaill:*:83:81:QMail user:/var/qmail:/nonexistent qmaild:*:82:81:QMail user:/var/qmail:/nonexistent qmailq:*:85:82:QMail user:/var/qmail:/nonexistent qmails:*:87:82:QMail user:/var/qmail:/nonexistent qmailp:*:84:81:QMail user:/var/qmail:/nonexistent qmailr:*:86:82:QMail user:/var/qmail:/nonexistent msql:*:87:87:mSQL-2 pseudo-user:/var/db/msqldb:/bin/sh このリストを最新の状態に保つためにも, この範囲の UID や GID を予約するような port を作ったり, 既存の port にそのような改変を行って我々に送るときには, UID の予約に関する注意書きをつけてください. 合理的な port Makefile は単純かつ適切であるべきです. もし, Makefile を数行短かくできたり, もっと読みやすくできるのであれば, そうしてください. 例えば, shell の if 構文を使う代りに, make の .if 構文を使う, EXTRACT* の再定義で代用できるのであれば, do-extract を再定義しない, CONFIGURE_ARGS += --prefix=${PREFIX} とするかわりに, GNU_CONFIGURE とする, などです. <makevar>CFLAGS</makevar> の尊重 CFLAGS 変数は尊重すべきです. その port がこれを無視するのであれば, NO_PACKAGE=ignores cflags を Makefile に加えてください. コンフィグレーション(設定)ファイル もしあなたの port が設定ファイルを PREFIX/etc に置く必要がある場合には, それを単純にインストールしたり, pkg/PLIST に加えてはいけません. こうしてしまうと, pkg_delete が ユーザが苦労して作ったファイルを消してしまったり, 新しく インストールすると上書きされてしまったりします. 代りに, 見本となるファイルを suffix ( filename.sample が良いでしょう) を付けて インストールして, message を表示して, ソフトウエアを動かす前に, ユーザがそのファイル をコピーして編集をしなければならないことを知らせましょう. Portlint 送付や commit をする前に portlint を使ってチェックしましょう. フィードバック Portを作るためにソフトウェアに変更を加えたら, なるべく原作者にその旨を伝えてパッチ等を送ってください. これらが次のリリースに取り入れられれば, アップグレードが楽になります. その他諸々 pkg/DESCR, pkg/COMMENT, pkg/PLIST などのファイルは, それぞれ2重にチェックしてください. 再検討してもっと良い記述があれば, それに置きかえてください. GNU General Public License (GNU一般公有使用許諾)のコピーは (すでにあるので)コピーしないでください, おねがいします. 法律に関することには, 十分注意をはらってください. 私達に法律に反するような形でソフトフェアの配布をさせない でください! 困ったら.... 私たちに質問を送る前に, 既存のportの例とbsd.port.mkを ちゃんと読んでください! ;) それでもわからないことがあったら, 一人で悩まないでどんどん 質問してください! :) <filename>Makefile</filename> のお手本 これはportの Makefile を作る際のお手本です. かぎかっこ ([])内のコメントは忘れずに取ってください. 変数の順番, 段落の間の空行など, Makefile を作るときはなるべくこ の形式にしたがってください. この形式は重要な情報が簡単に見つけられるように 設計されています. portlint を使って Makefile をチェックすることが 推奨されています. [ヘッダ -- どのようなportのMakefileかすぐにわかるようになっています] # New ports collection makefile for: xdvi # Version required: pl18 ["1.5alpha" みたいなのでも結構です] [この Makefile の最初の版が作成された日付です. この port をアップグ レードするときには変えないでください.] # Date created: 26 May 1995 [このソフトウェアを最初に FreeBSD に port した人の名前, つまり, この Makefile の最初の版を書いた人です. この port をアップグレー ドするとき, この行も変えないでください.] # Whom: Satoshi Asami <asami@FreeBSD.ORG> # # $Id$ [ ^^^^ この部分は, CVS ツリーに入れる時に自動的に RCS の ID 文字列に 置き換えられます.] # [Port自体, およびオリジナルのソースを取ってくるところを記述する部分. 最初は必ずDISTNAME, そして必要ならPKGNAME, CATEGORIES, 続いて MASTER_SITESがおかれ, さらに MASTER_SITE_SUBDIR がおかれることもあり ます. そのあと, EXTRACT_SUFX か DISTFILES を指定することも可能です] DISTNAME= xdvi PKGNAME= xdvi-pl18 CATEGORIES= print [MASTER_SITE_* マクロを使用しない場合は, 最後のスラッシュを忘れないように ("/")!] MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications [ソースファイルが標準の ".tar.gz" 形式でない時にこれを使いましょう] EXTRACT_SUFX= .tar.Z [配布パッチのセクション -- ない場合もあります] PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/ PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz [保守責任者 -- これは *必ず* 必要です. 担当者 (あなた) 自身, あるいは 担当者に素早く連絡をとれる人のアドレスを書いてください. どうしてもこ こに自分のアドレスを書くのがいやな人は "ports@FreeBSD.ORG" と書いて もいいです] MAINTAINER= asami@FreeBSD.ORG [依存するport -- ない場合もあります] RUN_DEPENDS= gs:${PORTSDIR}/print/ghostscript LIB_DEPENDS= Xpm.5:${PORTSDIR}/graphics/xpm [ここには標準のbsd.port.mkの変数で, 上のどれにもあてはまらないものを 書きます] [コンフィグレーション, コンパイル, インストールなどの時に質問をする なら...] IS_INTERACTIVE=yes [${DISTNAME}以外のディレクトリにソースが展開されるなら...] WRKSRC= ${WRKDIR}/xdvi-new [配布されているパッチが ${WRKSRC} に対する相対パスで作られてい い場合にこの変数の指定が必要かも...] PATCH_DIST_STRIP= -p1 [GNU autoconfによって生成された "configure" スクリプトを走らせたいなら...] GNU_CONFIGURE= yes [/usr/bin/makeでなく, GNU makeを使わないといけないなら...] USE_GMAKE= yes [これがXのアプリケーションで "xmkmf -a" を走らせたいなら...] USE_IMAKE= yes [などなど] [下の方のルールで使う非標準の変数] MY_FAVORITE_RESPONSE= "yeah, right" [そして, 特別なターゲット, 使用順に] pre-fetch: i go fetch something, yeah post-patch: i need to do something after patch, great pre-install: and then some more stuff before installing, wow [最後には必ず] .include <bsd.port.mk> Packageの名前 Package の名前は以下のルールにしたがってつけてください. こ れは package のディレクトリを見やすくするためで, 無秩序な名前 がたくさん並んでいるとユーザが使いづらくなるのでは という心配か らです. (FTPサイトなどにはたくさんpackageがありますからね.) Packageの名前は以下のようにしてください. 言語-名前-オプション バージョン.番号 DISTNAME が上記の形式になっていない場合に は, PKGNAME をそのようにしてください. FreeBSD はユーザの慣れ親しんだ言語のサポートに力を入れて います. 特定の言語のためのportのpackage名には 言語- に ISO-639 で定義されている言語名の略称を入れ てください. 例えば, 日本語なら ja, ロシア語なら ru, ベト ナム語なら vi, 中国語なら zh, 韓国語ならば ko, ドイツ 語なら de, といった具合です. 名前 の部分は原則的にはすべて英小文字 を使います. 例外はたくさんのプログラムが入っている巨大なport の場合で, XFree86 (ほんとにあるんですよ) やImageMagickな どがこれにあたります. そうでない場合には, 名前の大文字を小文 字に (少なくとも最初の一字だけは) 変えてください. もし, 大文字であることが重要な場合(例えば, 1文字の名前, R とか V)には, あなたの裁量で大文字を使うのも良いでしょう. Perl 5 のモジュールでは, 頭に p5- を付け, 2重コロン (::) のセパレータをハイフン( - ) に置きかえるしきたりになっています. 例えば, Data::Dumper は p5-Data-Dumper になります. また, その ソフトウェアの名前として通常使われるものに番号, ハイフン, あ るいは下線が入っている場合には, それらを使うことも構いません (kinput2 など). コンパイル時に環境変数や make の引数などで ハードコードされたデフォルト を変えてコンパイルできる場合, -compiled.specifics にそのコンパイル時のデフォルトを入れてください (ハイフンはあってもなくてもかまいません). 用紙のサイズ, あるいはフォントの解像度などがこれにあたります. バージョン番号は数字とアルファベットからなり, ピリオド (.) で区切ります. アルファベットは二文字以上続けてはいけませ ん. ただ一つの例外は「パッチレベル」を意味する pl で, それ 以外にバージョン番号が まったくついていない場合にのみ使うことがで きます. では, DISTNAMEを正しい PKGNAMEに直す例を見てみましょう: DISTNAME PKGNAME 理由 mule-2.2.2. mule-2.2.2 まったく問題なし XFree86-3.1.2 XFree86-3.1.2 同上 EmiClock-1.0.2 emiclock-1.0.2 プログラム一つだけの時は小文字のみ gmod1.4 gmod-1.4 `<名前>' のあとにハイフンが必要 xmris.4.0.2 xmris-4.0.2 同上 rdist-1.3alpha rdist-1.3a alphaのような文字列は使えない es-0.9-beta1 es-0.9b1 同上 v3.3beta021.src tiff-3.3 なんなんでしょう ;) tvtwm tvtwm-pl11 バージョン番号は必ず必要 piewm piewm-1.0 同上 xvgr-2.10pl1 xvgr-2.10.1 pl が使えるのは他にバージョン番号がない場合のみ gawk-2.15.6 ja-gawk-2.15.6 日本語バージョン psutils-1.13 psutils-letter-1.13 コンパイル時に用紙のサイズを指定 pkfonts pkfonts300-1.0 300dpiフォント用のpackage オリジナルのソースにまったくバージョン情報が見当たらず, また原作 者が新しいバージョンをリリースする可能性が低いときには, バージョ ン番号として 1.0 を使えばいいでしょう (上記のpiewmの例がこ れにあたります). そうでない場合には, 原作者に聞くか, 日付 ( 年.月 .日) を使うなどしてください. カテゴリ すでに御存知のように, ports はいくつかのカテゴリに 分類されています. これを有効に利用するためには, port を 行う人々とユーザが, そろぞれのカテゴリが何であるか, どのようにしてカテゴリに分類するかを理解する必要が あります. 現在のカテゴリのリスト まず, これが現在の port のカテゴリーのリストです. アスタリスク(*) が付いているものは, バーチャル(virtual) カテゴリです -- これらには対応するサブディレクトリが port ツリーにはありません. バーチャルカテゴリでないものは, そのサブディレクトリ内の pkg/COMMENT に1行の記述があります (例, archivers/pkg/COMMENT). Category Description afterstep* Ports to support AfterStep window manager archivers Archiving tools. astro Astronomical ports. audio Sound support. benchmarks Benchmarking utilities. biology Biology-related software. cad Computer aided design tools. chinese Chinese language support. comms Communication software. Mostly software to talk to your serial port. converters Character code converters. databases Databases. deskutils Things that used to be on the desktop before computers were invented. devel Development utilities. Do not put libraries here just because they are libraries—unless they truly don't belong to anywhere else, they shouldn't be in this category. editors General editors. Specialized editors go in the section for those tools (e.g., a mathematical-formula editor will go in math). elisp Emacs-lisp ports. emulators Emulators for other operating systems. Terminal emulators do not belong here—X-based ones should go to x11 and text-based ones to either comms or misc, depending on the exact functionality. games Games. german German language support. graphics Graphics utilities. japanese Japanese language support. kde* Ports that form the K Desktop Environment (kde). korean Korean language support. lang Programming languages. mail Mail software. math Numerical computation software and other utilities for mathematics. mbone MBone applications. misc Miscellaneous utilities—basically things that doesn't belong to anywhere else. This is the only category that should not appear with any other non-virtual category. If you have misc with something else in your CATEGORIES line, that means you can safely delete misc and just put the port in that other subdirectory! net Miscellaneous networking software. news USENET news software. offix* Ports from the OffiX suite. palm Software support for the 3Com Palm(tm) series. perl5* Ports that require perl version 5 to run. plan9* Various programs from Plan9. print Printing software. Desktop publishing tools (previewers, etc.) belong here too. python* Software written in python. russian Russian language support. security Security utilities. shells Command line shells. sysutils System utilities. tcl75* Ports that use tcl version 7.5 to run. tcl76* Ports that use tcl version 7.6 to run. tcl80* Ports that use tcl version 8.0 to run. tcl81* Ports that use tcl version 8.1 to run. textproc Text processing utilities. It does not include desktop publishing tools, which go to print/. tk41* Ports that use tk version 4.1 to run. tk42* Ports that use tk version 4.2 to run. tk80* Ports that use tk version 8.0 to run. tk81* Ports that use tk version 8.1 to run. vietnamese Vietnamese language support. windowmaker* Ports to support the WindowMaker window manager www Software related to the World Wide Web. HTML language support belong here too. x11 The X window system and friends. This category is only for software that directly support the window system. Do not put regular X applications here. If your port is an X application, define USE_XLIB (implied by USE_IMAKE) and put it in appropriate categories. Also, many of them go into other x11-* categories (see below). x11-clocks X11 clocks. x11-fm X11 file managers. x11-fonts X11 fonts and font utilities. x11-toolkits X11 toolkits. x11-wm X11 window managers. 適切なカテゴリの選択 多くのカテゴリに重なるので, どれを '第一' カテゴリにするかを決めなければならないことが たびたびあるでしょう. これを うまく決めるルールがいくつかあります. 以下はその優先順のリストで, 優先度の高いものから 低いものの順に書いてあります. 言語特有のカテゴリがまず最初です. 例えば日本語の X11 のフォントをインストールする port の場合, CATEGORIES 行は japanese x11-fonts となるでしょう. より特徴的なカテゴリが, 一般的なカテゴリより 優先されます. 例えば, HTML エディタの場合は www editors となり, 逆順にはしないでください. また, port が mail, mbone, news, security, www のいづれかに属するとには, net は必要ありません. x11 を第2カテゴリにするのは, 第1カテゴリが自然言語の場合のみにしてください. 特に X のアプリケーションには x11 を指定しないでください. もし, あなたの port が他のどのカテゴリにも 属しないばあいには, misc にしてください. もし, あなたがカテゴリについて自信が持てない場合には, そのことを send-pr するときに 書き加えてください. そうすれば import するまえに それについて議論できます. (もしあなたが commiter であれば, そのことを &a.ports に送って, 先に議論 するようにしてください — 新しい port が間違ったカテゴリに import されて, すぐ移動されることが多いので.) このドキュメントと ports システムの変更 もしあなたが, たくさんの ports の保守を しているのであれば, &a.ports メーリングリストの内容を フォロウすることを考えてください. Ports のしくみについての重要な変更点はここに アナウンスされます. 最新の変更点については, いつでも, the bsd.port.mk CVS log で詳細な情報を得ることができます. + url="http://www.FreeBSD.ORG/cgi/cvsweb.cgi/ports/Mk/bsd.port.mk"> the bsd.port.mk CVS log で詳細な情報を得ることができます. やっとおしまい! いやはや, 長い文章ですみません. ここまで読んでくださった方に は感謝, 感謝でございます. (_ _) さあ, portの作り方がわかったところで, 世界中のソフトウェア をport化しましょう. FreeBSDプロジェクトに貢献するには, それ がもっとも簡単な方法です! :)