diff --git a/ja_JP.eucJP/articles/contributing/article.sgml b/ja_JP.eucJP/articles/contributing/article.sgml index 602d4c5fa3..db385d00d5 100644 --- a/ja_JP.eucJP/articles/contributing/article.sgml +++ b/ja_JP.eucJP/articles/contributing/article.sgml @@ -1,6065 +1,6069 @@ FreeBSD への貢献 原作: &a.jkh;. 訳: &a.jp.iwasaki;. 27 April 1997. あなたも何か FreeBSD のために貢献したくなりましたか? 素晴らしい! 私たちは常に支援を受ける用意がありますし, FreeBSD は生き残るためにユー ザベースの貢献に頼るようなシステムの一つです. あなたの貢献は 感謝されるだけではなく, FreeBSD が成長し続けるために極めて重要なものな のです! 一部の人達が言っているのとは逆に, 貢献を受け付けてもらうために腕利 きのプログラマーになるとか FreeBSD コアチームの人と親友になる必要はあ りません. FreeBSD プロジェクトの開発は, 多くのそして益々増加する世界中 の貢献者達によってなされており, 彼らの年齢, 専門技術分野は多岐に渡りま す. そして手の空いている人よりも 成されるべき仕事の方が常に多いのです. FreeBSD プロジェクトがカーネルや散在しているユーティリティよりも, オペレーティングシステム環境 (と, そのインストール) に対して責任を持つ ようになったため, 私たちのTODOリストはドキュメンテーション, ベータテ スト, 高度に専門化されたタイプのカーネル開発の好例を紹介するなど非常に 広い範囲のタスクに渡ります. あなたの技能レベルに関わらず, プロジェクト を支援できることが必ず何かあります! FreeBSD 関連の事業に従事している商業団体が私たちにコンタクトすること も歓迎します. あなたの製品を (FreeBSD 上で) 動作させるには, 特別な拡張 が必要ではありませんか? あまりにも風変わりな要求でなければ, それを受け 入れる用意が私たちにあるとわかるはずです. 付加価値のある製品ですか? 私たちに知らせてください! 多分私たちは, ある 面において共同して作業をすることができるでしょう. フリーソフトウェア界 は, ソフトウェアがそのライフサイクルを通してどのように開発され, 売られ, 保守されていくかについて, 既存の仮説に挑戦しています. 少なくとももう一 度考慮してみることを私たちは強くお奨めします. 何が必要? 次のタスクとサブプロジェクトのリストは, コアチームの色々な TODO リ ストと最近2ヶ月で集めたユーザリクエストを合わせたものです. 可能なとこ ろでは, 緊急度によってタスクがランクづけされています. もしここにあるタ スクの実行に興味があるのでしたら, コーディネータの名前をクリックしてメー ルを送ってください. もしコーディネータが決まっていなければ, あなたがボ ランティアしてみませんか? 優先度の高いタスク 次のタスクは通常, ひどく壊れているとか, とても必要とされている何かを 表しているため, 急務と考えられています: 第3ステージ・ブート問題. 全体コーディネーション: &a.hackers; 第3ステージがディスクの BIOS ジオメトリの正確なマッピングを提供 できるように WinNT コンパチブルなドライブの追跡をおこなう. ファイルシステム問題. 全体コーディネーション: &a.fs; nullfs ファイルシステムコードのクリーンアップと ドキュメンテーション. コーディネータ: &a.gibbs; union ファイルシステムの修正. コーディネータ: &a.dg; カーネル vm86 及びユーザ vm86 サポート実装. コーディネータ: &a.jlemon; Int13 vm86 ディスクドライバの実装. コーディネータ: &a.hackers; カーネル問題. 全体コーディネーション: &a.hackers; すべての現存ドライバの eisaconf 変換の達成. すべての割り込みルーチンを ユニット番号を使う代わりに (void *) を 取るように変更. EISA/PCI/ISAの割り込み登録コードの統合. PCI/EISA/ISA デバイス検出を bt742a.c(WIP) のようなドライバから分割. syscons の ALT-Fn/vt 切替えによるハングの修正. コーディネータ: &a.sos; 3c509と3c590 ドライバの統合 (本質的には PCI デバイス検出の ep.c への提供). 優先度がさほど高くないタスク 次のタスクはやっておくべきではありますが, 特にさし迫っているわけで はありません: MCA サポート? これは続けるにしても止めてしまうにしても結論を出 すべき. 完全な KLD ベースのドライバのサポート / コンフィグレーションマネー ジャ. ld なしですべての LKM の登録をおこなう方法を考案する. これは カーネル中にある種のシンボルテーブルを 持たせることを意味します. 穏やかな方法でハードウェアを検知する コンフィグレーションマネージャ の作成 (第3ステージ・ブートの中に?). ハードウェアが必要とする KLD だけを 残す等. PCMCIA/PCCARD. コーディネータ: &a.msmith; と &a.phk; ドキュメンテーション! pcic ドライバの信頼性のある操作 (テスト要). sio.c のリコグナイザとハンドラ (ほぼ完了). ed.c のリコグナイザとハンドラ (ほぼ完了). ep.c のリコグナイザとハンドラ (ほぼ完了). User-mode のリコグナイザとハンドラ (部分的に完了). 先進的なパワーマネージメント. コーディネータ: &a.nate; と &a.phk; APM サブドライバ (ほぼ完了). IDE/ATA ディスクサブドライバ (部分的に完了). syscons/pcvt サブドライバ. PCMCIA/PCCARD ドライバ群との統合 (サスペンド / レジューム). 優先度の低いタスク 次のタスクは全くのあら隠し, または誰もすぐにおこないそうもない投資 のような仕事を表します: 最初の20項目は Terry Lambert terry@lambert.org からのもので す. プロセッサ上で V86 モードを使用して, プロテクトモードからの BIOS コールができるようにし, マップされた割り込み IPC 機構を経由してプロテ クトモードの呼出し元に結果を返すようにする. DOS と同じように, 実際の下位ハードウェアから独立になるよう, BIOS コール機構を使用したカーネルの中に組み込まれたドライバ. これは DOS ベー スのローダプログラムで BSD がロードされる前に DOS にロードされていたネッ トワークドライバや ASPI ドライバも含みます. このことは潜在的なポーリン グ, つまりプロテクトモードカーネルによる V86 マシンのための DOS-not-busy 割り込みの生成を意味します. ハードウェア固有のプロテクトモードの ドライバがロードされて活性化 された後で, デフォルトのカーネル実行形式の中の, そのようなドライバデー タとテキストエリアを追跡して, カーネルアドレス空間のその部分が回復され るようにするためのイメージ形式. これは個々の BIOS ベースのドライバを互いに分離することを含みます. なぜ なら全く実行しないよりも, すべてのケースにおいて BIOS ベースのドライバ と共に実行した方が良いためです. バスインタフェース機構の抽象化. 現在のところ, PCMCIA, EISA そし て PCI バスはブリッジで ISA バスに接続されていると仮定しています. こう いった仮定はおこなうべきではありません. パワーマネージメントイベント, カードの挿入, 取り出し, そしてバス (PNPISA と PCMCIA とのブリッジチップ) 対カードのレベルのイベント管理を 含む PNP イベントを解釈するコンフィグレーションマネージャ. 固定デバイスによる他の再割当可・不可の デバイス空間リソースの使用 と衝突しない, 再割当可能なアドレスの割り当てのためのトポロジカルソート 機構. ハードウェアサービス登録のための登録ベースの機構. 特にタイマ, サウンドおよび他の システムクリティカルなサービス供給源のためのデバイス 中心の登録機構. 単一の独立していないサービス供給源の一つの例として Timer2, Timer0 そしてスピーカサービスを考慮する必要があります. ネットワークカードと一緒に提供される ODI カードドライバを使用で きるようにする, NetWare サーバ (プロテクトモードの ODI ドライバ) ロー ダとサブサービス. NDIS ドライバと NetWare の SCSI ドライバについても同 様. 前のリビジョンの FreeBSD マシンではなく, Linux マシンで動作する 「アップグレード システム」オプション. 移植を簡単にするためと, X, ThinkPad, PS/2マウス, LED, コンソール スイッチング, しつこい NumLock などの問題を全部一度に片付けるためのコ ンソールドライバの抽象レイヤへの分割. 機会が許したら, 他の外部ドライバのための他のカーネルのエミュレー ション環境. SCO と Solaris は UnixWare などに続く良い候補です. 異なるアーキテクチャのバイナリの実行のための プロセッサエミュレーション環境. これはシステムコールインタフェースがあまり変わらなければ, 思ったより簡単です. 商用のストリームドライバを使用可能にするための ストリーム機構. カーネルのマルチスレッド化 (カーネルのプリエンプションが必要). カーネルのプリエンプション付き対称マルチプロセッシング (カーネル のプリエンプションが必要). ポータブルコンピュータのサポートにおける協調の試み. これは PCMCIA ブリッジング規則と電源管理イベント処理の変更により, いく らかは処理できます. しかし, 内蔵ディスプレイと外部ディスプレイの検出, この 2 種類のディスプレイがあるという事実に基づく 異なる解像度の選択, マシンがドックにある場合には ディスクのモータ停止を防止すること, マシンの ブート能力に影響を与えずにドックベースのカードの消滅を 可能にすること (PCMCIA と同じ問題) などの問題があります. マルチプラットフォームへの移植のための ソースツリーの再組織化. make worldできちんと「世界を創造する」 ができるようにする. (もしmake regress(訳注: 後退する)と呼び方が適当であれば, そのように 名前を変える) 最小必要メモリ 4MB 化 (もっと小さければなお良し!). もっと簡単なタスク 上のセクションで挙げたタスクは膨大な時間の投資または FreeBSD のカーネルに関する深い知識を必要とします (もしくはそのどちらも). しかしながら, "週末ハッカー"やプログラミングのスキルを持 たない人々に適した立派なタスクも数多くあります. FreeBSD-current を運用しており, 状態の良いインターネット接続があ るならば, current.FreeBSD.org という一日に一回フルリリースを行っている マシンがあります — 時おり最新のリリースをそこからインストールし, その 過程で何か問題があるなら報告して下さい. freebsd-bugs メーリングリストを読んでください. そこではあなたが建 設的なコメントを付けたりテストできるパッチが 提供されているような問題がある かもしれません. もしくはそれらの問題の一つをあなた自身で修正することさえ できるかもしれません. 定期的に FAQ とハンドブックを通して読んでみてください. もしまずい説明や古い事柄や完全に間違っていることなどが あれば我々に しらせて下さい. さらに良いのは我々に修正案を送ることです (SGML は学ぶのにそれほど難しくありませんが, プレインテキストでも問題は ありません). (もしまだないならば) FreeBSD のドキュメントを自分の母国語に翻訳 するのを手伝ってください — 作業している人がいるかどうか &a.doc; にメールを 送って聞くだけです. とはいっても, そうすることによってあなたが全ての FreeBSD ドキュメントの翻訳に携わるように なるというわけではないですから ね — 実際, もっとも翻訳が必要とされているドキュメントはインストール方 法です. たまに(もしくは定期的に) freebsd-questions メーリングリストや comp.unix.bsd.freebsd.misc を読んでください. これは, あなたの持ってい る専門知識を共有したり誰かが抱えている問題を 解決するのに非常に有効な ものになり得ることです. 時にはあなた自身で新しいことを学ぶことさえ できるかもしれません. これらのフォーラムはやるべきことのアイディア の源にもなり得るのです. -current に正しく当てられるがしばらく経っても(通常は 2, 3 週間) -stable に取り込まれてないようなバグフィックスがあるならば コミッターに 丁寧に思い出させてください. 寄贈ソフトウェアをソースツリーの src/contrib に移動させてください. src/contrib 以下のコードが最新のものであるか確認してください. 2000 年問題に関するバグを探してください(そして, 見つけたら修正してください!). ソースツリー全体(もしくはその一部)を, 警告を詳細に報告するようにして構築してみてください. そして警告が出ないようにしてください. ports で, gets() を使っているとか malloc.h をインクルードしている などといった警告が出ないようにしてください. もしなんらかの ports に関わっているなら, あなたのパッチを作者に フィードバックしてください (次のバージョンが出た時にあなたが楽になります). このリストに追加するタスクを提案して下さい! 障害報告(PR; Problem Report)データベースにおける作業 FreeBSD 障害報告リストでは, 現在問題となっている報告と, FreeBSD の利用者によって提出された改良の要望に関する 全てのリストを公開しています. open 状態の障害情報を見て, 興味を引く内容かどうか確かめて下さい. 本当に複雑なものも含まれているでしょうし, 例えば, 障害報告に対する修正がちゃんとしたものであるかどうか 単にチェックするだけのとても簡単な作業もあるでしょう. まず, まだ誰にも割り当てられていない障害報告から作業を 始めて下さい. もし, 誰か他の人に割り当てが決まっているけれども 自分が作業可能だ, というものがあれば, 作業ができるかどうか— 既にテスト用パッチが用意されているのかどうか, あるいは その問題についてあなたが考えている, より進んだ考えに関して議論ができるかどうか, 割り当てられている人に電子メールで問い合わせて下さい. 貢献の仕方 一般的に, システムへの貢献は次の 6 つのカテゴリの1つ以上に分類されます: バグ報告と一般的な論評 報告するべきバグがあったり, 提案したいことがあれば: 一般的な 技術的関心事に関するアイデアや提案は &a.hackers; へメールしてください. 同様に, このような事柄に興味のある (そして膨大なメール! に耐えられる) 人は, &a.majordomo; へメールを送って hackers メーリングリストに参加すると良いでしょう. 情報については メーリングリスト を参照してください. バグを発見したり変更を送付しようとしている場合は &man.send-pr.1; プログラムか WEB ベースの send-pr を使用して報告してください. バグレポートの各項目を埋めるようにしてください. 65KB を超えるのでなければ, レポート中に直接 パッチを入れてくださって結構です. その場合, カット＆ペーストはしないで ください. カット＆ペーストではタブがスペースに展開されて パッチが使い物にならなくなってしまいます. 20KB を超える場合は, それらを compress して &man.uuencode.1; することも検討してください. とても大きくなる場合は ftp.FreeBSD.org:/pub/FreeBSD/incoming/ を利用してください. レポートがファイリングされれば, バグ報告の確認と トラッキング番号をメールで受け取るはずです. このトラッキング番号を覚えておき, 問題に関する詳細情報を bug-followup@FreeBSD.org に メールで送って更新できるようにしてください. 例えば "Re: kern/3377" のように, この番号をサブジェクト行に使用してください. すべてのバグレポートの追加情報は, この方法で送付されなければいけません. もしタイムリに (あなたの電子メール接続形態にもよりますが, 3日から 1週間) 確認を受けとれないとか, 何らかの理由で &man.send-pr.1; コマンドが 使用できない場合には, &a.bugs; へメールを送り, 誰か代りにバグ報告を 送付してもらうようたずねてください. 文書の変更 文書の変更は &a.doc; が監督しています. バグ報告と一般的な論評 に記述されているように send-pr コマンドを使用して, 提案や変更 (どんな些細なものでも歓迎します!) を送ってください. 現存のソースコードの変更 現存のソースコードへの追加または変更は, いくらかトリッキーな仕事で あり, core の FreeBSD 開発の現状にあなたがどれだけ通じているかに大 きく依存します. “FreeBSD-current”として知られる FreeBSD の特別な 継続的リリースがあります. FreeBSD-current は開発者の積極的な活動の 便宜のために, 色々な方法で利用可能になっています. FreeBSD-current の入手と使用方法についての詳しい情報については 最新の FreeBSD を追いかける を参照してください. 不幸にして古いソースをもとに仕事をすることは, 時々あなたの変更が時 代遅れ, または FreeBSD への簡単な再統合に合わなくなっていることを意 味します. システムの現状に関する議論がおこなわれている &a.announce; と &a.current; へ参加することで, この可能性を最小限にすることができます. 完全な最新のソースを変更のベースにできることが 確実になったと仮定し て, 次のステップは FreeBSD の保守担当者へ送る差分ファイルの生成です. これは &man.diff.1; コマンドを使用しておこないますが, “context diff”形式が好まれるようです. 例えば: &prompt.user; diff -c oldfile newfile または &prompt.user; diff -c -r olddir newdir これで指定されたソースファイルまたはディレクトリ階層に 対するコンテ キスト形式の差分が生成されます. 詳しい説明は &man.diff.1; のマ ニュアルページを参照してください. 差分ファイル (&man.patch.1; コマンドでテストできます) を作ったら, それらを FreeBSD に含めてもらうようメールで送ってください. バグ報告と一般的な論評 に記述されているように &man.send-pr.1; コマンドを使用してください. 差分ファイルだけを &a.hackers; へ送ってはいけません. 途方にくれてしまいます! 私たちは多忙なので, あなたの提案に大変感謝します (これはボランティアのプロジェクトです!). すぐに取りかかることはできませんが, 処理されるまでは ちゃんと pr データベースに残っています. あなたがそうした方がいいと思う場合 (例えば, ファイルの追加, 削除または名称変更など), 変更を tar ファイルにまとめ, &man.uuencode.1; プログラムにかけてください. Shar アーカイブも歓迎します. 例えばあなたがそれ自身のさらなる配布を管理する コピーライト問題を良 く分かっていないとか, 単に厳しいレビューをおこなっておらず, リリース する準備ができていないなど, あなたの変更が潜在的に不安定な性質をも つものである場合, &man.send-pr.1; で送付するよりむしろ &a.core; へ直接送ってください. コアチームメーリングリスト宛のメールは, 日々の仕 事のほとんどを FreeBSD でおこなっている人たちの, より小さなグルー プに届きます. このグループもまたとても忙しい ことに注意し て, 本当に必要な場合にコアチームの彼らにメールを 送るだけにしてください. コーディングスタイルに関する情報は man 9 intro および man 9 style を参照してください. コードを提出する前には, 少なくともこの情報を意識しておいてくださるようお願いします. 新たなコードやメジャーな付加価値の高いパッケージ 重要な大きい仕事の寄贈や, 重要な新しいフィーチャーを FreeBSD に追加 する稀な場合には, 変更点を tar/uuencode したファイルにして送るか, それらを私たちの ftp サイト ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/ へアップロードす ることのどちらかが通常必要になります. 大量のコードを伴った仕事の場合, コピーライトの神経過敏な問題が常に 出てきます. FreeBSD に含めるコードのコピーライトとして受け入れるこ とができるのは, 以下の二つです: BSD コピーライト. このコピーライトは“権利に縛られない”性格 と商用企業にとって一般的な魅力をもつために最も好まれま す. FreeBSD プロジェクトは商用利用を阻んだりせず, 何かを FreeBSD へ投資する気になった商業関係者による参加を積極的に奨励 します. GNU一般公有使用許諾, または“GPL”. このライセンスはコード を商用目的に使用する場合に余分な努力が求められるため, 私たち にあまり評判が良いというわけではありません. しかし, 私たちは 既に GPL 下の高品質なコード (コンパイラ, アセンブラ, テキスト フォーマッタ等) の提供を受けており, 私たちは現在それを必要と しています. そのため, このライセンスによる新たな貢献を拒絶す るというのは愚かなことでしょう. GPL 下のコードはソースツリー の別の部分, 現在のところ /sys/gnu か /usr/src/gnu に入っています. そのため, GPL が問題と なるような人は, 誰でも簡単にそれとわかるようになっています. これ以外のタイプのコピーライトによる寄贈は, FreeBSD へ含めることを 考慮する前に, 注意深いレビューを受けなければなりません. 作者が独自 のチャネルを通して配布しており, そのような変更をおこなうことを常に 奨励している場合でも, 特に限定的な商用のコピーライトが適用される寄 贈は一般に拒否されます. あなたの作品に “BSD-スタイル” のコピーライトを付けるには, 保護した いソースコードファイルすべての一番最初に 以下のテキストを入れて, %% の間を適切な情報に置き換えください. Copyright (c) %%適切な年%% %%あなたの名前%%, %%あなたの州%% %%郵便番号%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%あなたの名前%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%あなたの名前%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ 便宜をはかるため, このテキストのコピーは次の場所に置いてあります. /usr/share/examples/etc/bsd-style-copyright. (訳注: 以下は神田敏広氏より寄贈された bsd-style-copyright の日本語訳です. ソースファイルに含めるものは原文の方であることに注意して ご利用ください. また, 原文との間に趣旨の差異が生じた場合, 原文の内容が FreeBSD プロジェクトの 意思であるものとします.) Copyright (C) [年] [あなたの名前] All rights reserved. ソースとバイナリ形式の再配布および使用は, 変更の有無にかかわらず以下の 条件を満たす場合に限り許可される: 1. ソースコードの再配布は, 上記の著作権表示・この条件のリスト・下記の 否認声明文を保持しなければならない. 2. バイナリ形式の再配布は, 上記の著作権表示・この条件のリスト・下記の 否認声明文を, 配布物と共に提供される文書および/または他の資料の中に 含めなければならない. (訳注:ここから「否認声明文」です) このソフトウェアは[あなたの名前]および貢献者によって ``あるがままの状態'' で提供され, 商品性と特定の目的に対する適合性についての暗黙の保証に留ま らず, いかなる明示および暗黙の保証を認めない. [あなたの名前]および貢献 者は, あらゆる直接的・間接的・偶発的・特殊的・典型的・必然的な損害 (代 替製品または代替サービスの獲得費; 効用・データ・利益の喪失; または業務 中断を含み, またそれだけに留まらない損害) に対して, たとえどのようにし て生じたとしても, そしてこのソフトウェアの使用によってどのようにであれ 生じる, 契約上であろうと, 厳密な責任内であろうと, あるいは不正行為 (過 失やそうでない場合を含む) における場合であろうとも, いかなる責任論上も, たとえそのような損害の可能性が予見されていたとしても, 一切の責任を持た ない. 翻訳: 神田敏広 御協力 (五十音順・敬称略): 池田研二, 内川 喜章, 藤村 英治, むらたしゅういちろう 杢野 雅一, 横田＠宇都宮 金銭, ハードウェアまたはインターネットアクセス FreeBSD プロジェクトの目的を進めるための寄付や, 私たちと同じような ボランティアの細く長い ! 努力を, 私たちは常に喜んで受け入れています. また一般的に私たちは自分達で 周辺機器を買う資金が不足しているため, 周辺機器のサポートを充実させるのに ハードウェアの寄付はとても重要です. 資金の寄付 FreeBSD プロジェクトは501(C3) (非営利) 企業ではないため, いかなる寄 付に対しても特別な税金の優遇措置を提供することができません. このような 寄付はプロジェクトを代表して FreeBSD, Inc により感謝をもって受け入れら れるでしょう. FreeBSD, Inc.は FreeBSD プロジェクトの推進とプロジェクトに企業とし ての最小限の体裁を持たせることを目的として, 1995年の初めに &a.jkh; と &a.dg; により設立されました. 寄付されたすべての資金は (最終的に FreeBSD, Inc.によりもたらされるであろうすべての利益も同様に) プロジェク トの目標を推進するためだけに使われるでしょう. 支払い先を FreeBSD, Inc. とした小切手を, 次の住所気付けで送ってください:
FreeBSD, Inc. c/o Jordan Hubbard 4041 Pike Lane, Suite F Concord CA, 94520
[現在 私書箱が開設されるまで一時的に Walnut Creek CDROM の住所を使用] 電信振替は次の所まで直接送れるでしょう:
Bank Of America Concord Main Office P.O. Box 37176 San Francisco CA, 94137-5176 Routing #: 121-000-358 Account #: 01411-07441 (FreeBSD, Inc.)
寄付に関することは全て電子メールもしくは上記 FreeBSD, Inc. の住所宛の郵政省メールにて &a.jkh までお送りくださるようお願いします. もし 寄贈者ギャラリー の節で匿名を希望される 方は, 寄付の際にその旨お伝えください. Thanks! ハードウェアの寄贈 FreeBSD プロジェクトは, 次の3つのカテゴリのどんなハードウェアの寄贈 も, 喜んで受け付けます: ディスクドライブ, メモリまたは完全なシステムといった一般用途のハー ドウェアは, 資金の寄付の節にある FreeBSD, Inc. の住所まで送っ てください. 進行中の受け入れテストのための ハードウェアが必要とされていま す. 新たなリリース毎に適切な逆行テストができるように, 私たちは現在, FreeBSD がサポートするすべてのコンポーネントの テストラボを設置しよう としています. 私たちにはまだ, たくさんの重要な部品 (ネットワークカード, マザーボードなど) が不足していますので, このような寄贈をしたいと思って いるならば, &a.dg; へコンタクトしてどの部品がまだ必要とされているか の情報を得てください. 現在 FreeBSD にサポートされていないハードウェアで, サポートに追 加して欲しいもの. 私たちが新しいハードウェアを受けとる前にそのタスクを 引き受けてくれる開発者を探す必要があるため, その部品を送る前に &a.core; にコンタクトを取ってください. インターネットアクセスの寄付 私たちは常に FTP, WWW や cvsup の新しいミラーサイトを募集しています. ミラーサイトになりたい場合には the FreeBSD project administrators admin@FreeBSD.org にコンタクトを取って, 詳し い情報を手に入れてください. 寄贈者ギャラリー FreeBSD プロジェクトは次の寄贈者に恩義を受けており, ここに公表して 感謝の意を表したいと思います. セントラルサーバプロジェクトへの寄贈者: 次に挙げる個人および企業からは, セントラルサーバマシンのための 部品の寄贈を頂いており, それによって freefall.FreeBSD.org をリプレースして新たに FreeBSD プロジェクトのセントラルサーバマシンを 構築することができました: &a.mbarkah と彼の所属する Hemisphere Online は, Pentium Pro (P6) 200Mhz CPU を寄贈してくださいました. ASA Computers は, Tyan 1662 マザーボード を寄贈してくださいました. ViaNet Communications の Joe McGuckin joe@via.net は, Kingston イーサネットコントローラ を寄贈してくださいました. Jack O'Neill jack@diamond.xtalwind.net は, NCR 53C875 SCSI コントローラカード を寄贈してくださいました. Alameda Networks の Ulf Zimmermann ulf@Alameda.net は, 128MB のメモリ, そして 4 GB のディスクドライブと匡体 を寄贈してくださいました. 直接的な資金提供: 次に挙げる個人および企業からは FreeBSD プロジェクトに対する直接的な 資金提供を頂いております: Annelise Anderson ANDRSN@HOOVER.STANFORD.EDU &a.dillon Epilogue Technology Corporation &a.sef Don Scott Wilde Gianmarco Giovannelli gmarco@masternet.it Josef C. Grosch joeg@truenorth.org Robert T. Morris &a.chuckr Imaginary Landscape, LLC. の Kenneth P. Stox ken@stox.sa.enteract.com Dmitry S. Kohmanyuk dk@dog.farm.org 日本の Laser5 はいくつかの FreeBSD CD の販売利益の一部を 寄付してくれました. 蕗出版 は, はじめての FreeBSD の売り上げの一部を FreeBSD プロジェクト及び XFree86 プロジェクトへ寄付してくれました. アスキー は FreeBSD 関連の書籍の売り上げの一部を FreeBSD プロジェクト及び FreeBSD 友の会へ寄付してくれました. 横河電機株式会社 からは FreeBSD プロジェクトへ多大な寄付をいただきました. BuffNET Pacific Solutions Siemens AG via Andre Albsmeier Chris Silva ハードウェアの寄贈者: 次に挙げる個人および企業からは, テストやデバイスドライバの開発 / サポート のためのハードウェアの寄贈を頂いております: Walnut Creek CDROM は, ネットワークへのアクセスおよび 他のハードウェアリソースの寄贈はいうまでもなく, 開発に使うための Pentium P5-90 と 486/DX2-66 EISA/VL のシステム数台を 提供してくださいました. TRW Financial Sysytems社は, PC 130台, 68 GB のファイルサーバ 3台, 12のイーサネット, ディスクレスコードのデバッグをおこなうための ルータ 2台及び ATM スイッチを提供してくださいました. また, 彼らは 2, 3人の FreeBSD ハッカーを雇って, FreeBSD に専念させて くださっております. ありがとうございます! Dermot McDonnell は, 東芝 XM3401B CD-ROM ドライブを 寄贈してくださいました. その CD-ROM ドライブは現在 freefall で使用されています. &a.chuck; は, 実験用のフロッピーテープストリーマを 寄付してくださいました. Larry Altneu larry@ALR.COM と &a.wilko;は, wt ドライバを改良するために Wangtek と Archive の QIC-02 テープドライブを提供してくださいました. Ernst Winter ewinter@lobo.muc.de は, このプロジェクトへ 2.88 MB のフロッピードライブを提供してくださいました. うまくいけば, これでフロッピーディスクドライバを書き直すための プレッシャーが増えるでしょう. ;-) Tekram Technologies は NCR ドライバや AMD ドライバと自社のカードの逆行テストのため FAST/ULTRA SCSI ホストアダプタ DC-390, DC-390U, DC-390F を 各１枚提供してくださいました. また, フリーな OS のためのドライバの ソースを自社の FTP サーバ ftp://ftp.tekram.com/scsi/FreeBSD/ で公開されていることも 称賛に値するでしょう. Larry M. Augustin lma@varesearch.com は Symbios Sym8751S SCSI カードを寄贈してくださっただけでなく, Ultra-2 や LVD をサポートする次期チップ Sym53c895 のものを含む データブックのセットと, 最新の Symbios SCSI チップが持つ先進的機能を 安全に使う方法について書かれた 最新のプログラミングマニュアルも 寄贈してくださいました. 本当にありがとうございます ! Christoph Kukulies kuku@FreeBSD.org は, IDE CD-ROM ドライバ開発用の FX120 12 倍速 Mitsumi CD-ROM ドライブ を提供してくださいました. 特筆すべき寄贈者: Walnut Creek CDROM は, 言い表せないほど多くの寄付をしてくださいました (詳細は FreeBSD 小史を参照). 特に, 私たちのもともとのプライマリ開発マシンである freefall.FreeBSD.org, テストおよびビルドマシンである thud.FreeBSD.org で使用しているハードウェアに対し 感謝したいと思います. また彼らには, 数年にわたる色々な貢献者への資金提供や, インターネット への T1 コネクションの無制限使用を提供して 頂いた恩義があります. interface business GmbH, Dresden は, &a.joerg; を根気よく サポートしてくださいました. 彼は本職より FreeBSD の仕事を好みがちであり, 彼個人の接続があまりに 遅くなったり途切れたりして仕事にならない時は必ず interface business の (非常に高価な) EUnet インターネット接続に頼ったものです... Berkeley Software Design, Inc. は, 同社の DOS エミュレータのコードを BSD コミュ ニティ全体に対して提供してくれました. このコードは, doscmd コマンドに利用されています. コアチームの卒業生 次に挙げる人々は()で記した期間, FreeBSD コアチームのメンバーでした. FreeBSD プロジェクトにおける彼らの努力に感謝の意を表します. だいたいの年代順: &a.guido (1995 - 1999) &a.dyson (1993 - 1998) &a.nate (1992 - 1996) &a.rgrimes (1992 - 1995) Andreas Schulz (1992 - 1995) &a.csgr (1993 - 1995) &a.paul (1992 - 1995) &a.smace (1993 - 1994) Andrew Moore (1993 - 1994) Christoph Robitschko (1993 - 1994) J. T. Conklin (1992 - 1993) BSD派生ソフトウェアへのコントリビュータ このソフトウェアは最初は William F. Jolitz の 386BSD release 0.1 から派生しましたが, オリジナルの 386BSD に固有のコードはほとんど 残っていません. このソフトウェアは基本的にはカリフォルニア大学 バークレイ校の Computer Science Research Group (CSRG) とその共同研究者 たちによる 4.4BSD-Lite リリースから再実装されました. また, NetBSD や OpenBSD の一部も FreeBSD に取り込まれています. したがって私たちは NetBSD と OpenBSD へ貢献した人々すべてに感謝します. その他の FreeBSD へのコントリビュータ (名前でアルファベット順に): ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp AMAGAI Yoshiji amagai@nue.org Aaron Bornstein aaronb@j51.com Aaron Smith aaron@mutex.org Achim Patzner ap@noses.com Ada T Lim ada@bsd.org Adam Baran badam@mw.mil.pl Adam Glass glass@postgres.berkeley.edu Adam McDougall mcdouga9@egr.msu.edu Adrian Colley aecolley@ois.ie Adrian Hall adrian@ibmpcug.co.uk Adrian Mariano adrian@cam.cornell.edu Adrian Steinmann ast@marabu.ch Adam Strohl troll@digitalspark.net Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu Ajit Thyagarajan unknown Akio Morita amorita@meadow.scphys.kyoto-u.ac.jp Akira SAWADA unknown Akira Watanabe akira@myaw.ei.meisei-u.ac.jp Akito Fujita fujita@zoo.ncl.omron.co.jp Alain Kalker A.C.P.M.Kalker@student.utwente.nl Alan Bawden alan@curry.epilogue.com Alec Wolman wolman@cs.washington.edu Aled Morris aledm@routers.co.uk Alex garbanzo@hooked.net Alex D. Chen dhchen@Canvas.dorm7.nccu.edu.tw Alex G. Bulushev bag@demos.su Alex Le Heux alexlh@funk.org Alex Perel veers@disturbed.net Alexander B. Povolotsky tarkhil@mgt.msk.ru Alexander Leidinger netchild@wurzelausix.CS.Uni-SB.DE Alexander Langer alex@cichlids.com Alexandre Snarskii snar@paranoia.ru Alistair G. Crooks agc@uts.amdahl.com Allan Saddi asaddi@philosophysw.com Allen Campbell allenc@verinet.com Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp Amancio Hasty hasty@star-gate.com Amir Farah amir@comtrol.com Amy Baron amee@beer.org Anatoly A. Orehovsky tolik@mpeks.tomsk.su Anatoly Vorobey mellon@pobox.com Anders Nordby nickerne@nome.no Anders Thulin Anders.X.Thulin@telia.se Andras Olah olah@cs.utwente.nl Andre Albsmeier Andre.Albsmeier@mchp.siemens.de Andre Oppermann andre@pipeline.ch Andreas Haakh ah@alman.robin.de Andreas Kohout shanee@rabbit.augusta.de Andreas Lohr andreas@marvin.RoBIN.de Andreas Schulz unknown Andreas Wetzel mickey@deadline.snafu.de Andreas Wrede andreas@planix.com Andres Vega Garcia unknown Andrew Atrens atreand@statcan.ca Andrew Boothman andrew@cream.org Andrew Gillham gillham@andrews.edu Andrew Gordon andrew.gordon@net-tel.co.uk Andrew Herbert andrew@werple.apana.org.au Andrew J. Korty ajk@purdue.edu Andrew L. Moore alm@mclink.com Andrew McRae amcrae@cisco.com Andrew Stevenson andrew@ugh.net.au Andrew Timonin tim@pool1.convey.ru Andrew V. Stesin stesin@elvisti.kiev.ua Andrew Webster awebster@dataradio.com Andy Farkas andyf@speednet.com.au Andy Valencia ajv@csd.mot.com Andy Whitcroft andy@sarc.city.ac.uk Angelo Turetta ATuretta@stylo.it Anthony C. Chavez magus@xmission.com Anthony Yee-Hang Chan yeehang@netcom.com Anton Berezin tobez@plab.ku.dk Antti Kaipila anttik@iki.fi Are Bryne are.bryne@communique.no Ari Suutari ari@suutari.iki.fi Arjan de Vet devet@IAEhv.nl Arne Henrik Juul arnej@Lise.Unit.NO Assar Westerlund assar@sics.se Atsushi Furuta furuta@sra.co.jp Atsushi Murai amurai@spec.co.jp Bakul Shah bvs@bitblocks.com Barry Bierbauch pivrnec@vszbr.cz Barry Lustig barry@ictv.com Ben Hutchinson benhutch@xfiles.org.uk Ben Jackson unknown Ben Smithurst ben@scientia.demon.co.uk Ben Walter bwalter@itachi.swcp.com Benjamin Lewis bhlewis@gte.net Bernd Rosauer br@schiele-ct.de Bill Kish kish@osf.org Bill Trost trost@cloud.rain.com Blaz Zupan blaz@amis.net Bob Van Valzah Bob@whitebarn.com Bob Willcox bob@luke.pmr.com Boris Staeblow balu@dva.in-berlin.de Boyd R. Faulkner faulkner@asgard.bga.com Brad Karp karp@eecs.harvard.edu Bradley Dunn bradley@dunn.org Brandon Fosdick bfoz@glue.umd.edu Brandon Gillespie brandon@roguetrader.com &a.wlloyd Bob Wilcox bob@obiwan.uucp Boyd Faulkner faulkner@mpd.tandem.com Brent J. Nordquist bjn@visi.com Brett Lymn blymn@mulga.awadi.com.AU Brett Taylor brett@peloton.runet.edu Brian Campbell brianc@pobox.com Brian Clapper bmc@willscreek.com Brian Cully shmit@kublai.com Brian Handy handy@lambic.space.lockheed.com Brian Litzinger brian@MediaCity.com Brian McGovern bmcgover@cisco.com Brian Moore ziff@houdini.eecs.umich.edu Brian R. Haug haug@conterra.com Brian Tao taob@risc.org Brion Moss brion@queeg.com Bruce A. Mah bmah@ca.sandia.gov Bruce Albrecht bruce@zuhause.mn.org Bruce Gingery bgingery@gtcs.com Bruce J. Keeler loodvrij@gridpoint.com Bruce Murphy packrat@iinet.net.au Bruce Walter walter@fortean.com Carey Jones mcj@acquiesce.org Carl Fongheiser cmf@netins.net Carl Mascott cmascott@world.std.com Casper casper@acc.am Castor Fu castor@geocast.com Cejka Rudolf cejkar@dcse.fee.vutbr.cz Chain Lee chain@110.net Charles Hannum mycroft@ai.mit.edu Charles Henrich henrich@msu.edu Charles Mott cmott@srv.net Charles Owens owensc@enc.edu Chet Ramey chet@odin.INS.CWRU.Edu Chia-liang Kao clkao@CirX.ORG Chiharu Shibata chi@bd.mbn.or.jp Chip Norkus unknown Choi Jun Ho junker@jazz.snu.ac.kr Chris Csanady cc@tarsier.ca.sandia.gov Chris Dabrowski chris@vader.org Chris Dillon cdillon@wolves.k12.mo.us Chris Shenton cshenton@angst.it.hq.nasa.gov Chris D. Faulhaber jedgar@fxp.org Chris Stenton jacs@gnome.co.uk Chris Timmons skynyrd@opus.cts.cwu.edu Chris Torek torek@ee.lbl.gov Christian Gusenbauer cg@fimp01.fim.uni-linz.ac.at Christian Haury Christian.Haury@sagem.fr Christian Weisgerber naddy@bigeye.rhein-neckar.de Christoph P. Kukulies kuku@FreeBSD.org Christoph Robitschko chmr@edvz.tu-graz.ac.at Christoph Weber-Fahr wefa@callcenter.systemhaus.net Christopher G. Demetriou cgd@postgres.berkeley.edu Christopher T. Johnson cjohnson@neunacht.netgsi.com Chrisy Luke chrisy@flix.net Chuck Hein chein@cisco.com Clive Lin clive@CiRX.ORG Colman Reilly careilly@tcd.ie Conrad Sabatier conrads@neosoft.com Coranth Gryphon gryphon@healer.com Cornelis van der Laan nils@guru.ims.uni-stuttgart.de Cove Schneider cove@brazil.nbn.com Craig Leres leres@ee.lbl.gov Craig Loomis unknown Craig Metz cmetz@inner.net Craig Spannring cts@internetcds.com Craig Struble cstruble@vt.edu Cristian Ferretti cfs@riemann.mat.puc.cl Curt Mayer curt@toad.com Cy Schubert cschuber@uumail.gov.bc.ca DI. Christian Gusenbauer cg@scotty.edvz.uni-linz.ac.at Dai Ishijima ishijima@tri.pref.osaka.jp Daisuke Watanabe NU7D-WTNB@asahi-net.or.jp Damian Hamill damian@cablenet.net Dan Cross tenser@spitfire.ecsel.psu.edu Dan Lukes dan@obluda.cz Dan Nelson dnelson@emsphone.com Dan Walters hannibal@cyberstation.net Daniel M. Eischen deischen@iworks.InterWorks.org Daniel O'Connor doconnor@gsoft.com.au Daniel Poirot poirot@aio.jsc.nasa.gov Daniel Rock rock@cs.uni-sb.de Danny Egen unknown Danny J. Zerkel dzerkel@phofarm.com Darren Reed avalon@coombs.anu.edu.au Dave Adkins adkin003@tc.umn.edu Dave Andersen angio@aros.net Dave Blizzard dblizzar@sprynet.com Dave Bodenstab imdave@synet.net Dave Burgess burgess@hrd769.brooks.af.mil Dave Chapeskie dchapes@ddm.on.ca Dave Cornejo dave@dogwood.com Dave Edmondson davided@sco.com Dave Glowacki dglo@ssec.wisc.edu Dave Marquardt marquard@austin.ibm.com Dave Tweten tweten@FreeBSD.org David A. Adkins adkin003@tc.umn.edu David A. Bader dbader@umiacs.umd.edu David Borman dab@bsdi.com David Dawes dawes@XFree86.org David Filo filo@yahoo.com David Holland dholland@eecs.harvard.edu David Holloway daveh@gwythaint.tamis.com David Horwitt dhorwitt@ucsd.edu David Hovemeyer daveho@infocom.com David Jones dej@qpoint.torfree.net David Kelly dkelly@tomcat1.tbe.com David Kulp dkulp@neomorphic.com David L. Nugent davidn@blaze.net.au David Leonard d@scry.dstc.edu.au David Malone dwmalone@maths.tcd.ie David Muir Sharnoff muir@idiom.com David S. Miller davem@jenolan.rutgers.edu David Wolfskill dhw@whistle.com Dean Gaudet dgaudet@arctic.org Dean Huxley dean@fsa.ca Denis Fortin unknown Dennis Glatting dennis.glatting@software-munitions.com Denton Gentry denny1@home.com Derek Inksetter derek@saidev.com Dima Sivachenko dima@Chg.RU Dirk Keunecke dk@panda.rhein-main.de Dirk Nehrling nerle@pdv.de Dmitry Khrustalev dima@xyzzy.machaon.ru Dmitry Kohmanyuk dk@farm.org Dom Mitchell dom@myrddin.demon.co.uk Dominik Brettnacher domi@saargate.de Dominik Rother dr@domix.de Don Croyle croyle@gelemna.ft-wayne.in.us &a.whiteside; Don Morrison dmorrisn@u.washington.edu Don Yuniskis dgy@rtd.com Donald Maddox dmaddox@conterra.com - Doug Barton studded@dal.net + Doug Barton Doug@gorean.org Douglas Ambrisko ambrisko@whistle.com Douglas Carmichael dcarmich@mcs.com Douglas Crosher dtc@scrooge.ee.swin.oz.au Drew Derbyshire ahd@kew.com Duncan Barclay dmlb@ragnet.demon.co.uk Dustin Sallings dustin@spy.net Eckart "Isegrim" Hofmann Isegrim@Wunder-Nett.org Ed Gold vegold01@starbase.spd.louisville.edu Ed Hudson elh@p5.spnet.com Edward Wang edward@edcom.com Edwin Groothus edwin@nwm.wan.philips.com Eiji-usagi-MATSUmoto usagi@clave.gr.jp ELISA Font Project Elmar Bartel bartel@informatik.tu-muenchen.de Eric A. Griff eagriff@global2000.net Eric Blood eblood@cs.unr.edu Eric J. Haug ejh@slustl.slu.edu Eric J. Schwertfeger eric@cybernut.com Eric L. Hernes erich@lodgenet.com Eric P. Scott eps@sirius.com Eric Sprinkle eric@ennovatenetworks.com Erich Stefan Boleyn erich@uruk.org Erik E. Rantapaa rantapaa@math.umn.edu Erik H. Moe ehm@cris.com Ernst Winter ewinter@lobo.muc.de Espen Skoglund esk@ira.uka.de Eugene M. Kim astralblue@usa.net Eugene Radchenko genie@qsar.chem.msu.su Eugeny Kuzakov CoreDumped@lab321.ru Evan Champion evanc@synapse.net Faried Nawaz fn@Hungry.COM Flemming Jacobsen fj@tfs.com Fong-Ching Liaw fong@juniper.net Francis M J Hsieh mjshieh@life.nthu.edu.tw Frank Bartels knarf@camelot.de Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw Frank Durda IV uhclem@nemesis.lonestar.org Frank MacLachlan fpm@n2.net Frank Nobis fn@Radio-do.de Frank Volf volf@oasis.IAEhv.nl Frank ten Wolde franky@pinewood.nl Frank van der Linden frank@fwi.uva.nl Fred Cawthorne fcawth@jjarray.umn.edu Fred Gilham gilham@csl.sri.com Fred Templin templin@erg.sri.com Frederick Earl Gray fgray@rice.edu FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp FUJISHIMA Satsuki k5@respo.or.jp FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp Gabor Kincses gabor@acm.org Gabor Zahemszky zgabor@CoDe.hu G. Adam Stanislavadam@whizkidtech.net Garance A Drosehn gad@eclipse.its.rpi.edu Gareth McCaughan gjm11@dpmms.cam.ac.uk Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Gary J. garyj@rks32.pcs.dec.com Gary Kline kline@thought.org Gaspar Chilingarov nightmar@lemming.acc.am Gea-Suan Lin gsl@tpts4.seed.net.tw Geoff Rehmet csgr@alpha.ru.ac.za Georg Wagner georg.wagner@ubs.com Gerard Roudier groudier@club-internet.fr Gianmarco Giovannelli gmarco@giovannelli.it Gil Kloepfer Jr. gil@limbic.ssdl.com Gilad Rom rom_glsa@ein-hashofet.co.il Ginga Kawaguti ginga@amalthea.phys.s.u-tokyo.ac.jp Giles Lean giles@nemeton.com.au Glen Foster gfoster@gfoster.com Glenn Johnson gljohns@bellsouth.net Godmar Back gback@facility.cs.utah.edu Goran Hammarback goran@astro.uu.se Gord Matzigkeit gord@enci.ucalgary.ca Gordon Greeff gvg@uunet.co.za Graham Wheeler gram@cdsec.com Greg A. Woods woods@zeus.leitch.com Greg Ansley gja@ansley.com Greg Troxel gdt@ir.bbn.com Greg Ungerer gerg@stallion.oz.au Gregory Bond gnb@itga.com.au Gregory D. Moncreaff moncrg@bt340707.res.ray.com Guy Harris guy@netapp.com Guy Helmer ghelmer@cs.iastate.edu HAMADA Naoki hamada@astec.co.jp HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp Hannu Savolainen hannu@voxware.pp.fi Hans Huebner hans@artcom.de Hans Petter Bieker zerium@webindex.no Hans Zuidam hans@brandinnovators.com Harlan Stenn Harlan.Stenn@pfcs.com Harold Barker hbarker@dsms.com Havard Eidnes Havard.Eidnes@runit.sintef.no Heikki Suonsivu hsu@cs.hut.fi Heiko W. Rupp unknown Helmut F. Wirth hfwirth@ping.at Henrik Vestergaard Draboel hvd@terry.ping.dk Herb Peyerl hpeyerl@NetBSD.org Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp Hidekazu Kuroki hidekazu@cs.titech.ac.jp Hideki Yamamoto hyama@acm.org Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp Hirayama Issei iss@mail.wbs.ne.jp Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp Hironori Ikura hikura@kaisei.org Hiroshi Nishikawa nis@pluto.dti.ne.jp Hiroya Tsubakimoto unknown Holger Veit Holger.Veit@gmd.de Holm Tiffe holm@geophysik.tu-freiberg.de Horance Chou horance@freedom.ie.cycu.edu.tw Horihiro Kumagai kuma@jp.FreeBSD.org HOTARU-YA hotaru@tail.net Hr.Ladavac lada@ws2301.gud.siemens.co.at Hubert Feyrer hubertf@NetBSD.ORG Hugh F. Mahon hugh@nsmdserv.cnd.hp.com Hugh Mahon h_mahon@fc.hp.com Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw IMAI Takeshi take-i@ceres.dti.ne.jp IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp Ian Dowse iedowse@maths.tcd.ie Ian Holland ianh@tortuga.com.au Ian Struble ian@broken.net Ian Vaudrey i.vaudrey@bigfoot.com Igor Khasilev igor@jabber.paco.odessa.ua Igor Roshchin str@giganda.komkon.org Igor Sviridov siac@ua.net Igor Vinokurov igor@zynaps.ru Ikuo Nakagawa ikuo@isl.intec.co.jp Ilya V. Komarov mur@lynx.ru Issei Suzuki issei@jp.FreeBSD.org Itsuro Saito saito@miv.t.u-tokyo.ac.jp IWASHITA Yoji shuna@pop16.odn.ne.jp IWASHITA Yoji shuna@pop16.odn.ne.jp J. Bryant jbryant@argus.flash.net J. David Lowe lowe@saturn5.com J. Han hjh@best.com J. Hawk jhawk@MIT.EDU J.T. Conklin jtc@cygnus.com J.T. Jang keith@email.gcn.net.tw Jack jack@zeus.xtalwind.net Jacob Bohn Lorensen jacob@jblhome.ping.mk Jagane D Sundar jagane@netcom.com Jake Burkholder jake@checker.org Jake Hamby jehamby@lightside.com James Clark jjc@jclark.com James D. Stewart jds@c4systm.com James Jegers jimj@miller.cs.uwm.edu James Raynard fhackers@jraynard.demon.co.uk James T. Liu jtliu@phlebas.rockefeller.edu James da Silva jds@cs.umd.edu Jan Conard charly@fachschaften.tu-muenchen.de Jan Koum jkb@FreeBSD.org Janick Taillandier Janick.Taillandier@ratp.fr Janusz Kokot janek@gaja.ipan.lublin.pl Jarle Greipsland jarle@idt.unit.no Jason Garman init@risen.org Jason Thorpe thorpej@NetBSD.org Jason Wright jason@OpenBSD.org Jason Young doogie@forbidden-donut.anet-stl.com Javier Martin Rueda jmrueda@diatel.upm.es Jay Fenlason hack@datacube.com Jaye Mathisen mrcpu@cdsnet.net Jeff Bartig jeffb@doit.wisc.edu Jeff Forys jeff@forys.cranbury.nj.us Jeff Kletsky Jeff@Wagsky.com Jeffrey Evans evans@scnc.k12.mi.us Jeffrey Wheat jeff@cetlink.net Jens Schweikhardt schweikh@noc.dfn.d Jeremy Allison jallison@whistle.com Jeremy Chatfield jdc@xinside.com Jeremy Lea reg@shale.csir.co.za Jeremy Prior unknown Jeroen Ruigrok/Asmodai asmodai@wxs.nl Jesse Rosenstock jmr@ugcs.caltech.edu Jian-Da Li jdli@csie.nctu.edu.tw Jim Babb babb@FreeBSD.org Jim Binkley jrb@cs.pdx.edu Jim Carroll jim@carroll.com Jim Flowers jflowers@ezo.net Jim Leppek jleppek@harris.com Jim Lowe james@cs.uwm.edu Jim Mattson jmattson@sonic.net Jim Mercer jim@komodo.reptiles.org Jim Wilson wilson@moria.cygnus.com Jimbo Bahooli griffin@blackhole.iceworld.org Jin Guojun jin@george.lbl.gov Joachim Kuebart unknown Joao Carlos Mendes Luis jonny@jonny.eng.br Jochen Pohl jpo.drs@sni.de Joe "Marcus" Clarke marcus@miami.edu Joe Abley jabley@clear.co.nz Joe Jih-Shian Lu jslu@dns.ntu.edu.tw Joe Orthoefer j_orthoefer@tia.net Joe Traister traister@mojozone.org Joel Faedi Joel.Faedi@esial.u-nancy.fr Joel Ray Holveck joelh@gnu.org Joel Sutton sutton@aardvark.apana.org.au Johan Granlund johan@granlund.nu Johan Karlsson k@numeri.campus.luth.se Johan Larsson johan@moon.campus.luth.se Johann Tonsing jtonsing@mikom.csir.co.za Johannes Helander unknown Johannes Stille unknown John Beckett jbeckett@southern.edu John Beukema jbeukema@hk.super.net John Brezak unknown John Capo jc@irbs.com John F. Woods jfw@jfwhome.funhouse.com John Goerzen jgoerzen@alexanderwohl.complete.org John Hay jhay@mikom.csir.co.za John Heidemann johnh@isi.edu John Hood cgull@owl.org John Kohl unknown John Lind john@starfire.mn.org John Mackin john@physiol.su.oz.au John P johnp@lodgenet.com John Perry perry@vishnu.alias.net John Preisler john@vapornet.com John Rochester jr@cs.mun.ca John Sadler john_sadler@alum.mit.edu John Saunders john@pacer.nlc.net.au John W. DeBoskey jwd@unx.sas.com John Wehle john@feith.com John Woods jfw@eddie.mit.edu Jon Morgan morgan@terminus.trailblazer.com Jonathan H N Chin jc254@newton.cam.ac.uk Jonathan Hanna jh@pc-21490.bc.rogers.wave.ca Jorge Goncalves j@bug.fe.up.pt Jorge M. Goncalves ee96199@tom.fe.up.pt Jos Backus jbackus@plex.nl Jose M. Alcaide jose@we.lc.ehu.es Jose Marques jose@nobody.org Josef Grosch jgrosch@superior.mooseriver.com Josef Karthauser joe@uk.FreeBSD.org Joseph Stein joes@wstein.com Josh Gilliam josh@quick.net Josh Tiefenbach josh@ican.net Juergen Lock nox@jelal.hb.north.de Juha Inkari inkari@cc.hut.fi Jukka A. Ukkonen jua@iki.fi Julian Assange proff@suburbia.net Julian Coleman j.d.coleman@ncl.ac.uk &a.jhs Julian Jenkins kaveman@magna.com.au Junichi Satoh junichi@jp.FreeBSD.org Junji SAKAI sakai@jp.FreeBSD.org Junya WATANABE junya-w@remus.dti.ne.jp K.Higashino a00303@cc.hc.keio.ac.jp KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp Kai Vorma vode@snakemail.hut.fi Kaleb S. Keithley kaleb@ics.com Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp Kapil Chowksey kchowksey@hss.hns.com Karl Denninger karl@mcs.com Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com Kato Takenori kato@eclogite.eps.nagoya-u.ac.jp KATO Tsuguru tkato@prontomail.ne.jp Kawanobe Koh kawanobe@st.rim.or.jp Kazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jp Kazuo Horikawa horikawa@jp.FreeBSD.org Kees Jan Koster kjk1@ukc.ac.uk Keith Bostic bostic@bostic.com Keith E. Walker unknown Keith Moore unknown Keith Sklower unknown Kelly Yancey kbyanc@posi.net Ken Hornstein unknown Ken Key key@cs.utk.edu Ken Mayer kmayer@freegate.com Kenji Saito marukun@mx2.nisiq.net Kenji Tomita tommyk@da2.so-net.or.jp Kenneth Furge kenneth.furge@us.endress.com Kenneth Monville desmo@bandwidth.org Kenneth R. Westerback krw@tcn.net Kenneth Stailey kstailey@gnu.ai.mit.edu Kent Talarico kent@shipwreck.tsoft.net Kent Vander Velden graphix@iastate.edu Kentaro Inagaki JBD01226@niftyserve.ne.jp Kevin Bracey kbracey@art.acorn.co.uk Kevin Day toasty@dragondata.com Kevin Lahey kml@nas.nasa.gov Kevin Lokevlo@hello.com.tw Kevin Street street@iname.com Kevin Van Maren vanmaren@fast.cs.utah.edu Kiril Mitev kiril@ideaglobal.com Kiroh HARADA kiroh@kh.rim.or.jp Klaus Klein kleink@layla.inka.de Klaus-J. Wolf Yanestra@t-online.de Koichi Sato copan@ppp.fastnet.or.jp Kostya Lukin lukin@okbmei.msk.su Kouichi Hirabayashi kh@mogami-wire.co.jp Kurt D. Zeilenga Kurt@Boolean.NET Kurt Olsen kurto@tiny.mcs.usu.edu L. Jonas Olsson ljo@ljo-slip.DIALIN.CWRU.Edu Lars Köller Lars.Koeller@Uni-Bielefeld.DE Larry Altneu larry@ALR.COM Laurence Lopez lopez@mv.mv.com Lee Cremeans lcremean@tidalwave.net Liang Tai-hwa avatar@www.mmlab.cse.yzu.edu.tw Lon Willett lon%softt.uucp@math.utah.edu Louis A. Mamakos louie@TransSys.COM Louis Mamakos loiue@TransSys.com Lucas James Lucas.James@ldjpc.apana.org.au Lyndon Nerenberg lyndon@orthanc.com M.C. Wong unknown MANTANI Nobutaka nobutaka@nobutaka.com MIHIRA Sanpei Yoshiro sanpei@sanpei.org MITA Yoshio mita@jp.FreeBSD.org MITSUNAGA Noriaki mitchy@er.ams.eng.osaka-u.ac.jp MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp Magnus Enbom dot@tinto.campus.luth.se Mahesh Neelakanta mahesh@gcomm.com Makoto MATSUSHITA matusita@jp.FreeBSD.org Makoto WATANABE watanabe@zlab.phys.nagoya-u.ac.jp Malte Lance malte.lance@gmx.net Manu Iyengar iyengar@grunthos.pscwa.psca.com Marc Frajola marc@dev.com Marc Ramirez mrami@mramirez.sy.yale.edu Marc Slemko marcs@znep.com Marc van Kempen wmbfmk@urc.tue.nl Marc van Woerkom van.woerkom@netcologne.de Marcel Moolenaar marcel@scc.nl Marcin Cieslak saper@system.pl Mario Sergio Fujikawa Ferreira lioux@gns.com.br Mark Andrews unknown Mark Cammidge mark@gmtunx.ee.uct.ac.za Mark Diekhans markd@grizzly.com Mark Huizer xaa@stack.nl Mark J. Taylor mtaylor@cybernet.com Mark Krentel krentel@rice.edu Mark Mayo markm@vmunix.com Mark Thompson thompson@tgsoft.com Mark Tinguely tinguely@plains.nodak.edu Mark Treacy unknown Mark Valentine mark@linus.demon.co.uk + + Markus Holmberg saska@acc.umu.se + + Martin Birgmeier Martin Ibert mib@ppe.bb-data.de Martin Kammerhofer dada@sbox.tu-graz.ac.at Martin Renters martin@tdc.on.ca Martti Kuparinen martti.kuparinen@ericsson.com Masachika ISHIZUKA ishizuka@isis.min.ntt.jp Mas.TAKEMURA unknown Masafumi NAKANE max@wide.ad.jp Masahiro Sekiguchi seki@sysrap.cs.fujitsu.co.jp Masanobu Saitoh msaitoh@spa.is.uec.ac.jp Masanori Kanaoka kana@saijo.mke.mei.co.jp Masanori Kiriake seiken@ARGV.AC Masatoshi TAMURA tamrin@shinzan.kuee.kyoto-u.ac.jp Mats Lofkvist mal@algonet.se Matt Bartley mbartley@lear35.cytex.com Matt Thomas matt@3am-software.com Matt White mwhite+@CMU.EDU Matthew C. Mead mmead@Glock.COM Matthew Cashdollar mattc@rfcnet.com Matthew Flatt mflatt@cs.rice.edu Matthew Fuller fullermd@futuresouth.com Matthew Stein matt@bdd.net Matthias Pfaller leo@dachau.marco.de Matthias Scheler tron@netbsd.org Mattias Gronlund Mattias.Gronlund@sa.erisoft.se Mattias Pantzare pantzer@ludd.luth.se Maurice Castro maurice@planet.serc.rmit.edu.au Max Euston meuston@jmrodgers.com Max Khon fjoe@husky.iclub.nsu.ru Maxim Bolotin max@rsu.ru Maxim V. Sobolev sobomax@altavista.net Micha Class michael_class@hpbbse.bbn.hp.com Michael Butler imb@scgt.oz.au Michael Butschky butsch@computi.erols.com Michael Clay mclay@weareb.org Michael Elbel me@FreeBSD.org Michael Galassi nerd@percival.rain.com Michael Hancock michaelh@cet.co.jp Michael Hohmuth hohmuth@inf.tu-dresden.de Michael Perlman canuck@caam.rice.edu Michael Petry petry@netwolf.NetMasters.com Michael Reifenberger root@totum.plaut.de Michael Sardo jaeger16@yahoo.com Michael Searle searle@longacre.demon.co.uk Michal Listos mcl@Amnesiac.123.org Michio Karl Jinbo karl@marcer.nagaokaut.ac.jp Miguel Angel Sagreras msagre@cactus.fi.uba.ar Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp Mika Nystrom mika@cs.caltech.edu Mikael Hybsch micke@dynas.se Mikael Karpberg karpen@ocean.campus.luth.se Mike Del repenting@hotmail.com Mike Durian durian@plutotech.com Mike Durkin mdurkin@tsoft.sf-bay.org Mike E. Matsnev mike@azog.cs.msu.su Mike Evans mevans@candle.com Mike Grupenhoff kashmir@umiacs.umd.edu Mike Hibler mike@marker.cs.utah.edu Mike Karels unknown Mike McGaughey mmcg@cs.monash.edu.au Mike Meyer mwm@shiva.the-park.com Mike Mitchell mitchell@ref.tfs.com Mike Murphy mrm@alpharel.com Mike Peck mike@binghamton.edu Mike Spengler mks@msc.edu Mikhail A. Sokolov mishania@demos.su Mikhail Teterin mi@aldan.ziplink.net Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW Mitsuru Yoshida mitsuru@riken.go.jp Monte Mitzelfelt monte@gonefishing.org Morgan Davis root@io.cts.com Mostyn Lewis mostyn@mrl.com Motomichi Matsuzaki mzaki@e-mail.ne.jp Motoyuki Kasahara m-kasahr@sra.co.jp Motoyuki Konno motoyuki@snipe.rim.or.jp Murray Stokely murray@cdrom.com N.G.Smith ngs@sesame.hensa.ac.uk NAGAO Tadaaki nagao@cs.titech.ac.jp NAKAJI Hiroyuki nakaji@tutrp.tut.ac.jp NAKAMURA Kazushi nkazushi@highway.or.jp NAKAMURA Motonori motonori@econ.kyoto-u.ac.jp NIIMI Satoshi sa2c@and.or.jp NOKUBI Hirotaka h-nokubi@yyy.or.jp Nadav Eiron nadav@barcode.co.il Nanbor Wang nw1@cs.wustl.edu Naofumi Honda honda@Kururu.math.sci.hokudai.ac.jp Naoki Hamada nao@tom-yam.or.jp Narvi narvi@haldjas.folklore.ee Nathan Ahlstrom nrahlstr@winternet.com Nathan Dorfman nathan@rtfm.net Neal Fachan kneel@ishiboo.com Neil Blakey-Milner nbm@rucus.ru.ac.za Niall Smart rotel@indigo.ie Nick Barnes Nick.Barnes@pobox.com Nick Handel nhandel@NeoSoft.com Nick Hilliard nick@foobar.org &a.nsayer; Nick Williams njw@cs.city.ac.uk Nickolay N. Dudorov nnd@itfs.nsk.su Niklas Hallqvist niklas@filippa.appli.se Nisha Talagala nisha@cs.berkeley.edu No Name ZW6T-KND@j.asahi-net.or.jp No Name adrian@virginia.edu No Name alex@elvisti.kiev.ua No Name anto@netscape.net No Name bobson@egg.ics.nitch.ac.jp No Name bovynf@awe.be No Name burg@is.ge.com No Name chris@gnome.co.uk No Name colsen@usa.net No Name coredump@nervosa.com No Name dannyman@arh0300.urh.uiuc.edu No Name davids@SECNET.COM No Name derek@free.org No Name devet@adv.IAEhv.nl No Name djv@bedford.net No Name dvv@sprint.net No Name enami@ba2.so-net.or.jp No Name flash@eru.tubank.msk.su No Name flash@hway.ru No Name fn@pain.csrv.uidaho.edu No Name gclarkii@netport.neosoft.com No Name gordon@sheaky.lonestar.org No Name graaf@iae.nl No Name greg@greg.rim.or.jp No Name grossman@cygnus.com No Name gusw@fub46.zedat.fu-berlin.de No Name hfir@math.rochester.edu No Name hnokubi@yyy.or.jp No Name iaint@css.tuu.utas.edu.au No Name invis@visi.com No Name ishisone@sra.co.jp No Name iverson@lionheart.com No Name jpt@magic.net No Name junker@jazz.snu.ac.kr No Name k-sugyou@ccs.mt.nec.co.jp No Name kenji@reseau.toyonaka.osaka.jp No Name kfurge@worldnet.att.net No Name lh@aus.org No Name lhecking@nmrc.ucc.ie No Name mrgreen@mame.mu.oz.au No Name nakagawa@jp.FreeBSD.org No Name ohki@gssm.otsuka.tsukuba.ac.jp No Name owaki@st.rim.or.jp No Name pechter@shell.monmouth.com No Name pete@pelican.pelican.com No Name pritc003@maroon.tc.umn.edu No Name risner@stdio.com No Name roman@rpd.univ.kiev.ua No Name root@ns2.redline.ru No Name root@uglabgw.ug.cs.sunysb.edu No Name stephen.ma@jtec.com.au No Name sumii@is.s.u-tokyo.ac.jp No Name takas-su@is.aist-nara.ac.jp No Name tamone@eig.unige.ch No Name tjevans@raleigh.ibm.com No Name tony-o@iij.ad.jp amurai@spec.co.jp No Name torii@tcd.hitachi.co.jp No Name uenami@imasy.or.jp No Name uhlar@netlab.sk No Name vode@hut.fi No Name wlloyd@mpd.ca No Name wlr@furball.wellsfargo.com No Name wmbfmk@urc.tue.nl No Name yamagata@nwgpc.kek.jp No Name ziggy@ryan.org Nobuhiro Yasutomi nobu@psrc.isac.co.jp Nobuyuki Koganemaru kogane@koganemaru.co.jp Norio Suzuki nosuzuki@e-mail.ne.jp Noritaka Ishizumi graphite@jp.FreeBSD.org Noriyuki Soda soda@sra.co.jp Oh Junseon hollywar@mail.holywar.net Olaf Wagner wagner@luthien.in-berlin.de Oleg Sharoiko os@rsu.ru Oleg V. Volkov rover@lglobus.ru Oliver Breuninger ob@seicom.NET Oliver Friedrichs oliver@secnet.com Oliver Fromme oliver.fromme@heim3.tu-clausthal.de Oliver Laumann net@informatik.uni-bremen.de Oliver Oberdorf oly@world.std.com Olof Johansson offe@ludd.luth.se Osokin Sergey aka oZZ ozz@FreeBSD.org.ru Pace Willisson pace@blitz.com Paco Rosich rosich@modico.eleinf.uv.es Palle Girgensohn girgen@partitur.se Parag Patel parag@cgt.com Pascal Pederiva pascal@zuo.dec.com Pasvorn Boonmark boonmark@juniper.net Patrick Gardella patrick@cre8tivegroup.com Patrick Hausen unknown Paul Antonov apg@demos.su Paul F. Werkowski unknown Paul Fox pgf@foxharp.boston.ma.us Paul Koch koch@thehub.com.au Paul Kranenburg pk@NetBSD.org Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Paul S. LaFollette, Jr. unknown Paul Saab paul@mu.org Paul Sandys myj@nyct.net Paul T. Root proot@horton.iaces.com Paul Vixie paul@vix.com Paulo Menezes paulo@isr.uc.pt Paulo Menezes pm@dee.uc.pt Pedro A M Vazquez vazquez@IQM.Unicamp.BR Pedro Giffuni giffunip@asme.org Pete Bentley pete@demon.net Peter Childs pjchilds@imforei.apana.org.au Peter Cornelius pc@inr.fzk.de Peter Haight peterh@prognet.com Peter Jeremy perer.jeremy@alcatel.com.au Peter M. Chen pmchen@eecs.umich.edu Peter Much peter@citylink.dinoex.sub.org Peter Olsson unknown Peter Philipp pjp@bsd-daemon.net Peter Stubbs PETERS@staidan.qld.edu.au Phil Maker pjm@cs.ntu.edu.au Phil Sutherland philsuth@mycroft.dialix.oz.au Phil Taylor phil@zipmail.co.uk Philip Musumeci philip@rmit.edu.au Pierre Y. Dampure pierre.dampure@k2c.co.uk Pius Fischer pius@ienet.com Pomegranate daver@flag.blackened.net Powerdog Industries kevin.ruddy@powerdog.com R. Kym Horsell Rajesh Vaidheeswarran rv@fore.com Ralf Friedl friedl@informatik.uni-kl.de Randal S. Masutani randal@comtest.com Randall Hopper rhh@ct.picker.com Randall W. Dean rwd@osf.org Randy Bush rbush@bainbridge.verio.net Reinier Bezuidenhout rbezuide@mikom.csir.co.za Remy Card Remy.Card@masi.ibp.fr Ricardas Cepas rch@richard.eu.org Riccardo Veraldi veraldi@cs.unibo.it Rich Wood rich@FreeBSD.org.uk Richard Henderson richard@atheist.tamu.edu Richard Hwang rhwang@bigpanda.com Richard Kiss richard@homemail.com Richard J Kuhns rjk@watson.grauel.com Richard M. Neswold rneswold@drmemory.fnal.gov Richard Seaman, Jr. dick@tar.com Richard Stallman rms@gnu.ai.mit.edu Richard Straka straka@user1.inficad.com Richard Tobin richard@cogsci.ed.ac.uk Richard Wackerbarth rkw@Dataplex.NET Richard Winkel rich@math.missouri.edu Richard Wiwatowski rjwiwat@adelaide.on.net Rick Macklem rick@snowhite.cis.uoguelph.ca Rick Macklin unknown Rob Austein sra@epilogue.com Rob Mallory rmallory@qualcomm.com Rob Snow rsnow@txdirect.net Robert Crowe bob@speakez.com Robert D. Thrush rd@phoenix.aii.com Robert Eckardt roberte@MEP.Ruhr-Uni-Bochum.de Robert Sanders rsanders@mindspring.com Robert Sexton robert@kudra.com Robert Shady rls@id.net Robert Swindells swindellsr@genrad.co.uk Robert Watson robert@cyrus.watson.org Robert Withrow witr@rwwa.com Robert Yoder unknown Robin Carey robin@mailgate.dtc.rankxerox.co.uk Roger Hardiman roger@cs.strath.ac.uk Roland Jesse jesse@cs.uni-magdeburg.de Ron Bickers rbickers@intercenter.net Ron Lenk rlenk@widget.xmission.com Ronald Kuehn kuehn@rz.tu-clausthal.de Rudolf Cejka unknown Ruslan Belkin rus@home2.UA.net Ruslan Ermilov ru@ucb.crimea.ua Ruslan Shevchenko rssh@cam.grad.kiev.ua Russell L. Carter rcarter@pinyon.org Russell Vincent rv@groa.uct.ac.za Ryan Younce ryany@pobox.com SANETO Takanori sanewo@strg.sony.co.jp SAWADA Mizuki miz@qb3.so-net.ne.jp SUGIMURA Takashi sugimura@jp.FreeBSD.org SURANYI Peter suranyip@jks.is.tsukuba.ac.jp Sakai Hiroaki sakai@miya.ee.kagu.sut.ac.jp Sakari Jalovaara sja@tekla.fi Sam Hartman hartmans@mit.edu Samuel Lam skl@ScalableNetwork.com Samuele Zannoli zannoli@cs.unibo.it Sander Vesik sander@haldjas.folklore.ee Sandro Sigala ssigala@globalnet.it Sascha Blank blank@fox.uni-trier.de Sascha Wildner swildner@channelz.GUN.de Satoh Junichi junichi@astec.co.jp Scot Elliott scot@poptart.org Scot W. Hetzel hetzels@westbend.net Scott A. Kenney saken@rmta.ml.org Scott Blachowicz scott.blachowicz@seaslug.org Scott Burris scott@pita.cns.ucla.edu Scott Hazen Mueller scott@zorch.sf-bay.org Scott Michel scottm@cs.ucla.edu Scott Mitchel scott@uk.FreeBSD.org Scott Reynolds scott@clmqt.marquette.mi.us Sebastian Strollo seb@erix.ericsson.se Serge A. Babkin babkin@hq.icb.chel.su Serge V. Vakulenko vak@zebub.msk.su Sergei Chechetkin csl@whale.sunbay.crimea.ua Sergei S. Laskavy laskavy@pc759.cs.msu.su Sergey Gershtein sg@mplik.ru Sergey Kosyakov ks@itp.ac.ru Sergey Potapov sp@alkor.ru Sergey Shkonda serg@bcs.zp.ua Sergey V.Dorokhov svd@kbtelecom.nalnet.ru Sergio Lenzi lenzi@bsi.com.br Shaun Courtney shaun@emma.eng.uct.ac.za Shawn M. Carey smcarey@mailbox.syr.edu Shigio Yamaguchi shigio@wtamacom.com Shinya Esu esu@yk.rim.or.jp Shuichi Tanaka stanaka@bb.mbn.or.jp Shunsuke Akiyama akiyama@jp.FreeBSD.org Simon simon@masi.ibp.fr Simon Burge simonb@telstra.com.au Simon J Gerraty sjg@melb.bull.oz.au Simon Marlow simonm@dcs.gla.ac.uk Simon Shapiro shimon@simon-shapiro.org Sin'ichiro MIYATANI siu@phaseone.co.jp Slaven Rezic eserte@cs.tu-berlin.de Soochon Radee slr@mitre.org Soren Dayton csdayton@midway.uchicago.edu Soren Dossing sauber@netcom.com Soren S. Jorvang soren@dt.dk Stefan Bethke stb@hanse.de Stefan Eggers seggers@semyam.dinoco.de Stefan Moeding s.moeding@ndh.net Stefan Petri unknown Stefan `Sec` Zehl sec@42.org Steinar Haug sthaug@nethelp.no Stephane E. Potvin sepotvin@videotron.ca Stephane Legrand stephane@lituus.fr Stephen Clawson sclawson@marker.cs.utah.edu Stephen F. Combs combssf@salem.ge.com Stephen Farrell stephen@farrell.org Stephen Hocking sysseh@devetir.qld.gov.au Stephen J. Roznowski sjr@home.net Stephen McKay syssgm@devetir.qld.gov.au Stephen Melvin melvin@zytek.com Steve Bauer sbauer@rock.sdsmt.edu Steve Coltrin spcoltri@io.com Steve Deering unknown Steve Gerakines steve2@genesis.tiac.net Steve Gericke steveg@comtrol.com Steve Piette steve@simon.chi.il.US Steve Schwarz schwarz@alpharel.com Steven G. Kargl kargl@troutmask.apl.washington.edu Steven H. Samorodin samorodi@NUXI.com Steven McCanne mccanne@cs.berkeley.edu Steven Plite splite@purdue.edu Steven Wallace unknown Stuart Henderson stuart@internationalschool.co.uk Sue Blake sue@welearn.com.au Sugimoto Sadahiro ixtl@komaba.utmc.or.jp Sugiura Shiro ssugiura@duo.co.jp Sujal Patel smpatel@wam.umd.edu Sune Stjerneby stjerneby@usa.net Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp Tadashi Kumano kumano@strl.nhk.or.jp Taguchi Takeshi taguchi@tohoku.iij.ad.jp Takahiro Yugawa yugawa@orleans.rim.or.jp Takanori Watanabe takawata@shidahara1.planet.sci.kobe-u.ac.jp Takashi Mega mega@minz.org Takashi Uozu j1594016@ed.kagu.sut.ac.jp Takayuki Ariga a00821@cc.hc.keio.ac.jp Takeru NAIKI naiki@bfd.es.hokudai.ac.jp Takeshi Amaike amaike@iri.co.jp Takeshi MUTOH mutoh@info.nara-k.ac.jp Takeshi Ohashi ohashi@mickey.ai.kyutech.ac.jp Takeshi WATANABE watanabe@crayon.earth.s.kobe-u.ac.jp Takuya SHIOZAKI tshiozak@makino.ise.chuo-u.ac.jp Tatoku Ogaito tacha@tera.fukui-med.ac.jp Tatsumi HOSOKAWA hosokawa@jp.FreeBSD.org Ted Buswell tbuswell@mediaone.net Ted Faber faber@isi.edu Ted Lemon mellon@isc.org Terry Lambert terry@lambert.org Terry Lee terry@uivlsi.csl.uiuc.edu Tetsuya Furukawa tetsuya@secom-sis.co.jp Theo de Raadt deraadt@OpenBSD.org Thomas thomas@mathematik.uni-Bremen.de Thomas D. Dean tomdean@ix.netcom.com Thomas David Rivers rivers@dignus.com Thomas G. McWilliams tgm@netcom.com Thomas Gellekum thomas@ghpc8.ihf.rwth-aachen.de Thomas Graichen graichen@omega.physik.fu-berlin.de Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de Thomas Ptacek unknown Thomas A. Stevens tas@stevens.org Thomas Stromberg tstrombe@rtci.com Thomas Valentino Crimi tcrimi+@andrew.cmu.edu Thomas Wintergerst thomas@lemur.nord.de Þórður Ívarsson totii@est.is Tim Kientzle kientzle@netcom.com Tim Singletary tsingle@sunland.gsfc.nasa.gov Tim Wilkinson tim@sarc.city.ac.uk Timo J. Rinne tri@iki.fi Todd Miller millert@openbsd.org Tom root@majestix.cmr.no Tom tom@sdf.com Tom Gray - DCA dcasba@rain.org Tom Jobbins tom@tom.tj Tom Pusateri pusateri@juniper.net Tom Rush tarush@mindspring.com Tom Samplonius tom@misery.sdf.com Tomohiko Kurahashi kura@melchior.q.t.u-tokyo.ac.jp Tony Kimball alk@Think.COM Tony Li tli@jnx.com Tony Lynn wing@cc.nsysu.edu.tw Tony Maher tonym@angis.org.au Torbjorn Granlund tege@matematik.su.se Toshihiko ARAI toshi@tenchi.ne.jp Toshihiko SHIMOKAWA toshi@tea.forus.or.jp Toshihiro Kanda candy@kgc.co.jp Toshiomi Moriki Toshiomi.Moriki@ma1.seikyou.ne.jp Trefor S. trefor@flevel.co.uk Trevor Blackwell tlb@viaweb.com URATA Shuichiro s-urata@nmit.tmg.nec.co.jp Udo Schweigert ust@cert.siemens.de Ugo Paternostro paterno@dsi.unifi.it Ulf Kieber kieber@sax.de Ulli Linzen ulli@perceval.camelot.de Ustimenko Semen semen@iclub.nsu.ru Uwe Arndt arndt@mailhost.uni-koblenz.de Vadim Chekan vadim@gc.lviv.ua Vadim Kolontsov vadim@tversu.ac.ru Vadim Mikhailov mvp@braz.ru Valentin Nechayev netch@lucky.net Van Jacobson van@ee.lbl.gov Vasily V. Grechishnikov bazilio@ns1.ied-vorstu.ac.ru Vasim Valejev vasim@uddias.diaspro.com Vernon J. Schryver vjs@mica.denver.sgi.com Vic Abell abe@cc.purdue.edu Ville Eerola ve@sci.fi Vincent Poy vince@venus.gaianet.net Vincenzo Capuano VCAPUANO@vmprofs.esoc.esa.de Virgil Champlin champlin@pa.dec.com Vladimir A. Jakovenko vovik@ntu-kpi.kiev.ua Vladimir Kushnir kushn@mail.kar.net Vsevolod Lobko seva@alex-ua.com W. Gerald Hicks wghicks@bellsouth.net W. Richard Stevens rstevens@noao.edu Walt Howard howard@ee.utah.edu Warren Toomey wkt@csadfa.cs.adfa.oz.au Wayne Scott wscott@ichips.intel.com Werner Griessl werner@btp1da.phy.uni-bayreuth.de Wes Santee wsantee@wsantee.oz.net Wietse Venema wietse@wzv.win.tue.nl Wilfredo Sanchez wsanchez@apple.com Wiljo Heinen wiljo@freeside.ki.open.de Wilko Bulte wilko@yedi.iaf.nl Will Andrews andrews@technologist.com Willem Jan Withagen wjw@surf.IAE.nl William Jolitz withheld William Liao william@tale.net Wojtek Pilorz wpilorz@celebris.bdk.lublin.pl Wolfgang Helbig helbig@ba-stuttgart.de Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@FreeBSD.org Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW Yarema yds@ingress.com Yaroslav Terletsky ts@polynet.lviv.ua Yasuhito FUTATSUKI futatuki@fureai.or.jp Yasuhiro Fukama yasuf@big.or.jp Yen-Shuo Su yssu@CCCA.NCTU.edu.tw Yin-Jieh Chen yinjieh@Crazyman.Dorm13.NCTU.edu.tw Ying-Chieh Liao ijliao@csie.NCTU.edu.tw Yixin Jin yjin@rain.cs.ucla.edu Yoichi Asai yatt@msc.biglobe.ne.jp Yoichi Asai yatt@msc.biglobe.ne.jp Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp Yoshihiko OHTA yohta@bres.tsukuba.ac.jp Yoshihisa NAKAGAWA y-nakaga@ccs.mt.nec.co.jp Yoshikazu Goto gotoh@ae.anritsu.co.jp Yoshimasa Ohnishi ohnishi@isc.kyutech.ac.jp Yoshishige Arai ryo2@on.rim.or.jp Yuichi MATSUTAKA matutaka@osa.att.ne.jp Yujiro MIYATA miyata@bioele.nuee.nagoya-u.ac.jp Yukihiro Nakai nacai@iname.com Yusuke Nawano azuki@azkey.org Yuu Yashiki s974123@cc.matsuyama-u.ac.jp Yuval Yarom yval@cs.huji.ac.il Yves Fonk yves@cpcoup5.tn.tudelft.nl Yves Fonk yves@dutncp8.tn.tudelft.nl Zach Heilig zach@gaffaneys.com Zahemszhky Gabor zgabor@code.hu Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw arci vega@sophia.inria.fr der Mouse mouse@Collatz.McRCIM.McGill.EDU frf frf@xocolatl.com Ege Rekk aagero@aage.priv.no 386BSD パッチキットへのパッチ提供者 (名前でアルファベット順): Adam Glass glass@postgres.berkeley.edu Adrian Hall adrian@ibmpcug.co.uk Andrey A. Chernov ache@astral.msk.su Andrew Herbert andrew@werple.apana.org.au Andrew Moore alm@netcom.com Andy Valencia ajv@csd.mot.com jtk@netcom.com Arne Henrik Juul arnej@Lise.Unit.NO Bakul Shah bvs@bitblocks.com Barry Lustig barry@ictv.com Bob Wilcox bob@obiwan.uucp Branko Lankester Brett Lymn blymn@mulga.awadi.com.AU Charles Hannum mycroft@ai.mit.edu Chris G. Demetriou cgd@postgres.berkeley.edu Chris Torek torek@ee.lbl.gov Christoph Robitschko chmr@edvz.tu-graz.ac.at Daniel Poirot poirot@aio.jsc.nasa.gov Dave Burgess burgess@hrd769.brooks.af.mil Dave Rivers rivers@ponds.uucp David Dawes dawes@physics.su.OZ.AU David Greenman dg@Root.COM Eric J. Haug ejh@slustl.slu.edu Felix Gaehtgens felix@escape.vsse.in-berlin.de Frank Maclachlan fpm@crash.cts.com Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Geoff Rehmet csgr@alpha.ru.ac.za Goran Hammarback goran@astro.uu.se Guido van Rooij guido@gvr.org Guy Harris guy@auspex.com Havard Eidnes Havard.Eidnes@runit.sintef.no Herb Peyerl hpeyerl@novatel.cuc.ab.ca Holger Veit Holger.Veit@gmd.de Ishii Masahiro, R. Kym Horsell J.T. Conklin jtc@cygnus.com Jagane D Sundar jagane@netcom.com James Clark jjc@jclark.com James Jegers jimj@miller.cs.uwm.edu James W. Dolter James da Silva jds@cs.umd.edu et al Jay Fenlason hack@datacube.com Jim Wilson wilson@moria.cygnus.com Jörg Lohse lohse@tech7.informatik.uni-hamburg.de Jörg Wunsch joerg_wunsch@uriah.heep.sax.de John Dyson John Woods jfw@eddie.mit.edu Jordan K. Hubbard jkh@whisker.hubbard.ie Julian Elischer julian@dialix.oz.au Julian Stacey jhs@FreeBSD.org Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com karl@one.neosoft.com Keith Bostic bostic@toe.CS.Berkeley.EDU Ken Hughes Kent Talarico kent@shipwreck.tsoft.net Kevin Lahey kml%rokkaku.UUCP@mathcs.emory.edu kml@mosquito.cis.ufl.edu Marc Frajola marc@dev.com Mark Tinguely tinguely@plains.nodak.edu tinguely@hookie.cs.ndsu.NoDak.edu Martin Renters martin@tdc.on.ca Michael Clay mclay@weareb.org Michael Galassi nerd@percival.rain.com Mike Durkin mdurkin@tsoft.sf-bay.org Naoki Hamada nao@tom-yam.or.jp Nate Williams nate@bsd.coe.montana.edu Nick Handel nhandel@NeoSoft.com nick@madhouse.neosoft.com Pace Willisson pace@blitz.com Paul Kranenburg pk@cs.few.eur.nl Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Peter da Silva peter@NeoSoft.com Phil Sutherland philsuth@mycroft.dialix.oz.au Poul-Henning Kampphk@FreeBSD.org Ralf Friedl friedl@informatik.uni-kl.de Rick Macklem root@snowhite.cis.uoguelph.ca Robert D. Thrush rd@phoenix.aii.com Rod Taylor rod@idiotswitch.org Rodney W. Grimes rgrimes@cdrom.com Sascha Wildner swildner@channelz.GUN.de Scott Burris scott@pita.cns.ucla.edu Scott Reynolds scott@clmqt.marquette.mi.us Sean Eric Fagan sef@kithrup.com Simon J Gerraty sjg@melb.bull.oz.au sjg@zen.void.oz.au Stephen McKay syssgm@devetir.qld.gov.au Terry Lambert terry@icarus.weber.edu Terry Lee terry@uivlsi.csl.uiuc.edu Tor Egge Tor.Egge@idi.ntnu.no Warren Toomey wkt@csadfa.cs.adfa.oz.au Wiljo Heinen wiljo@freeside.ki.open.de William Jolitz withheld Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@dentaro.GUN.de Yuval Yarom yval@cs.huji.ac.il diff --git a/ja_JP.eucJP/books/handbook/contrib/chapter.sgml b/ja_JP.eucJP/books/handbook/contrib/chapter.sgml index 602d4c5fa3..db385d00d5 100644 --- a/ja_JP.eucJP/books/handbook/contrib/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/contrib/chapter.sgml @@ -1,6065 +1,6069 @@ FreeBSD への貢献 原作: &a.jkh;. 訳: &a.jp.iwasaki;. 27 April 1997. あなたも何か FreeBSD のために貢献したくなりましたか? 素晴らしい! 私たちは常に支援を受ける用意がありますし, FreeBSD は生き残るためにユー ザベースの貢献に頼るようなシステムの一つです. あなたの貢献は 感謝されるだけではなく, FreeBSD が成長し続けるために極めて重要なものな のです! 一部の人達が言っているのとは逆に, 貢献を受け付けてもらうために腕利 きのプログラマーになるとか FreeBSD コアチームの人と親友になる必要はあ りません. FreeBSD プロジェクトの開発は, 多くのそして益々増加する世界中 の貢献者達によってなされており, 彼らの年齢, 専門技術分野は多岐に渡りま す. そして手の空いている人よりも 成されるべき仕事の方が常に多いのです. FreeBSD プロジェクトがカーネルや散在しているユーティリティよりも, オペレーティングシステム環境 (と, そのインストール) に対して責任を持つ ようになったため, 私たちのTODOリストはドキュメンテーション, ベータテ スト, 高度に専門化されたタイプのカーネル開発の好例を紹介するなど非常に 広い範囲のタスクに渡ります. あなたの技能レベルに関わらず, プロジェクト を支援できることが必ず何かあります! FreeBSD 関連の事業に従事している商業団体が私たちにコンタクトすること も歓迎します. あなたの製品を (FreeBSD 上で) 動作させるには, 特別な拡張 が必要ではありませんか? あまりにも風変わりな要求でなければ, それを受け 入れる用意が私たちにあるとわかるはずです. 付加価値のある製品ですか? 私たちに知らせてください! 多分私たちは, ある 面において共同して作業をすることができるでしょう. フリーソフトウェア界 は, ソフトウェアがそのライフサイクルを通してどのように開発され, 売られ, 保守されていくかについて, 既存の仮説に挑戦しています. 少なくとももう一 度考慮してみることを私たちは強くお奨めします. 何が必要? 次のタスクとサブプロジェクトのリストは, コアチームの色々な TODO リ ストと最近2ヶ月で集めたユーザリクエストを合わせたものです. 可能なとこ ろでは, 緊急度によってタスクがランクづけされています. もしここにあるタ スクの実行に興味があるのでしたら, コーディネータの名前をクリックしてメー ルを送ってください. もしコーディネータが決まっていなければ, あなたがボ ランティアしてみませんか? 優先度の高いタスク 次のタスクは通常, ひどく壊れているとか, とても必要とされている何かを 表しているため, 急務と考えられています: 第3ステージ・ブート問題. 全体コーディネーション: &a.hackers; 第3ステージがディスクの BIOS ジオメトリの正確なマッピングを提供 できるように WinNT コンパチブルなドライブの追跡をおこなう. ファイルシステム問題. 全体コーディネーション: &a.fs; nullfs ファイルシステムコードのクリーンアップと ドキュメンテーション. コーディネータ: &a.gibbs; union ファイルシステムの修正. コーディネータ: &a.dg; カーネル vm86 及びユーザ vm86 サポート実装. コーディネータ: &a.jlemon; Int13 vm86 ディスクドライバの実装. コーディネータ: &a.hackers; カーネル問題. 全体コーディネーション: &a.hackers; すべての現存ドライバの eisaconf 変換の達成. すべての割り込みルーチンを ユニット番号を使う代わりに (void *) を 取るように変更. EISA/PCI/ISAの割り込み登録コードの統合. PCI/EISA/ISA デバイス検出を bt742a.c(WIP) のようなドライバから分割. syscons の ALT-Fn/vt 切替えによるハングの修正. コーディネータ: &a.sos; 3c509と3c590 ドライバの統合 (本質的には PCI デバイス検出の ep.c への提供). 優先度がさほど高くないタスク 次のタスクはやっておくべきではありますが, 特にさし迫っているわけで はありません: MCA サポート? これは続けるにしても止めてしまうにしても結論を出 すべき. 完全な KLD ベースのドライバのサポート / コンフィグレーションマネー ジャ. ld なしですべての LKM の登録をおこなう方法を考案する. これは カーネル中にある種のシンボルテーブルを 持たせることを意味します. 穏やかな方法でハードウェアを検知する コンフィグレーションマネージャ の作成 (第3ステージ・ブートの中に?). ハードウェアが必要とする KLD だけを 残す等. PCMCIA/PCCARD. コーディネータ: &a.msmith; と &a.phk; ドキュメンテーション! pcic ドライバの信頼性のある操作 (テスト要). sio.c のリコグナイザとハンドラ (ほぼ完了). ed.c のリコグナイザとハンドラ (ほぼ完了). ep.c のリコグナイザとハンドラ (ほぼ完了). User-mode のリコグナイザとハンドラ (部分的に完了). 先進的なパワーマネージメント. コーディネータ: &a.nate; と &a.phk; APM サブドライバ (ほぼ完了). IDE/ATA ディスクサブドライバ (部分的に完了). syscons/pcvt サブドライバ. PCMCIA/PCCARD ドライバ群との統合 (サスペンド / レジューム). 優先度の低いタスク 次のタスクは全くのあら隠し, または誰もすぐにおこないそうもない投資 のような仕事を表します: 最初の20項目は Terry Lambert terry@lambert.org からのもので す. プロセッサ上で V86 モードを使用して, プロテクトモードからの BIOS コールができるようにし, マップされた割り込み IPC 機構を経由してプロテ クトモードの呼出し元に結果を返すようにする. DOS と同じように, 実際の下位ハードウェアから独立になるよう, BIOS コール機構を使用したカーネルの中に組み込まれたドライバ. これは DOS ベー スのローダプログラムで BSD がロードされる前に DOS にロードされていたネッ トワークドライバや ASPI ドライバも含みます. このことは潜在的なポーリン グ, つまりプロテクトモードカーネルによる V86 マシンのための DOS-not-busy 割り込みの生成を意味します. ハードウェア固有のプロテクトモードの ドライバがロードされて活性化 された後で, デフォルトのカーネル実行形式の中の, そのようなドライバデー タとテキストエリアを追跡して, カーネルアドレス空間のその部分が回復され るようにするためのイメージ形式. これは個々の BIOS ベースのドライバを互いに分離することを含みます. なぜ なら全く実行しないよりも, すべてのケースにおいて BIOS ベースのドライバ と共に実行した方が良いためです. バスインタフェース機構の抽象化. 現在のところ, PCMCIA, EISA そし て PCI バスはブリッジで ISA バスに接続されていると仮定しています. こう いった仮定はおこなうべきではありません. パワーマネージメントイベント, カードの挿入, 取り出し, そしてバス (PNPISA と PCMCIA とのブリッジチップ) 対カードのレベルのイベント管理を 含む PNP イベントを解釈するコンフィグレーションマネージャ. 固定デバイスによる他の再割当可・不可の デバイス空間リソースの使用 と衝突しない, 再割当可能なアドレスの割り当てのためのトポロジカルソート 機構. ハードウェアサービス登録のための登録ベースの機構. 特にタイマ, サウンドおよび他の システムクリティカルなサービス供給源のためのデバイス 中心の登録機構. 単一の独立していないサービス供給源の一つの例として Timer2, Timer0 そしてスピーカサービスを考慮する必要があります. ネットワークカードと一緒に提供される ODI カードドライバを使用で きるようにする, NetWare サーバ (プロテクトモードの ODI ドライバ) ロー ダとサブサービス. NDIS ドライバと NetWare の SCSI ドライバについても同 様. 前のリビジョンの FreeBSD マシンではなく, Linux マシンで動作する 「アップグレード システム」オプション. 移植を簡単にするためと, X, ThinkPad, PS/2マウス, LED, コンソール スイッチング, しつこい NumLock などの問題を全部一度に片付けるためのコ ンソールドライバの抽象レイヤへの分割. 機会が許したら, 他の外部ドライバのための他のカーネルのエミュレー ション環境. SCO と Solaris は UnixWare などに続く良い候補です. 異なるアーキテクチャのバイナリの実行のための プロセッサエミュレーション環境. これはシステムコールインタフェースがあまり変わらなければ, 思ったより簡単です. 商用のストリームドライバを使用可能にするための ストリーム機構. カーネルのマルチスレッド化 (カーネルのプリエンプションが必要). カーネルのプリエンプション付き対称マルチプロセッシング (カーネル のプリエンプションが必要). ポータブルコンピュータのサポートにおける協調の試み. これは PCMCIA ブリッジング規則と電源管理イベント処理の変更により, いく らかは処理できます. しかし, 内蔵ディスプレイと外部ディスプレイの検出, この 2 種類のディスプレイがあるという事実に基づく 異なる解像度の選択, マシンがドックにある場合には ディスクのモータ停止を防止すること, マシンの ブート能力に影響を与えずにドックベースのカードの消滅を 可能にすること (PCMCIA と同じ問題) などの問題があります. マルチプラットフォームへの移植のための ソースツリーの再組織化. make worldできちんと「世界を創造する」 ができるようにする. (もしmake regress(訳注: 後退する)と呼び方が適当であれば, そのように 名前を変える) 最小必要メモリ 4MB 化 (もっと小さければなお良し!). もっと簡単なタスク 上のセクションで挙げたタスクは膨大な時間の投資または FreeBSD のカーネルに関する深い知識を必要とします (もしくはそのどちらも). しかしながら, "週末ハッカー"やプログラミングのスキルを持 たない人々に適した立派なタスクも数多くあります. FreeBSD-current を運用しており, 状態の良いインターネット接続があ るならば, current.FreeBSD.org という一日に一回フルリリースを行っている マシンがあります — 時おり最新のリリースをそこからインストールし, その 過程で何か問題があるなら報告して下さい. freebsd-bugs メーリングリストを読んでください. そこではあなたが建 設的なコメントを付けたりテストできるパッチが 提供されているような問題がある かもしれません. もしくはそれらの問題の一つをあなた自身で修正することさえ できるかもしれません. 定期的に FAQ とハンドブックを通して読んでみてください. もしまずい説明や古い事柄や完全に間違っていることなどが あれば我々に しらせて下さい. さらに良いのは我々に修正案を送ることです (SGML は学ぶのにそれほど難しくありませんが, プレインテキストでも問題は ありません). (もしまだないならば) FreeBSD のドキュメントを自分の母国語に翻訳 するのを手伝ってください — 作業している人がいるかどうか &a.doc; にメールを 送って聞くだけです. とはいっても, そうすることによってあなたが全ての FreeBSD ドキュメントの翻訳に携わるように なるというわけではないですから ね — 実際, もっとも翻訳が必要とされているドキュメントはインストール方 法です. たまに(もしくは定期的に) freebsd-questions メーリングリストや comp.unix.bsd.freebsd.misc を読んでください. これは, あなたの持ってい る専門知識を共有したり誰かが抱えている問題を 解決するのに非常に有効な ものになり得ることです. 時にはあなた自身で新しいことを学ぶことさえ できるかもしれません. これらのフォーラムはやるべきことのアイディア の源にもなり得るのです. -current に正しく当てられるがしばらく経っても(通常は 2, 3 週間) -stable に取り込まれてないようなバグフィックスがあるならば コミッターに 丁寧に思い出させてください. 寄贈ソフトウェアをソースツリーの src/contrib に移動させてください. src/contrib 以下のコードが最新のものであるか確認してください. 2000 年問題に関するバグを探してください(そして, 見つけたら修正してください!). ソースツリー全体(もしくはその一部)を, 警告を詳細に報告するようにして構築してみてください. そして警告が出ないようにしてください. ports で, gets() を使っているとか malloc.h をインクルードしている などといった警告が出ないようにしてください. もしなんらかの ports に関わっているなら, あなたのパッチを作者に フィードバックしてください (次のバージョンが出た時にあなたが楽になります). このリストに追加するタスクを提案して下さい! 障害報告(PR; Problem Report)データベースにおける作業 FreeBSD 障害報告リストでは, 現在問題となっている報告と, FreeBSD の利用者によって提出された改良の要望に関する 全てのリストを公開しています. open 状態の障害情報を見て, 興味を引く内容かどうか確かめて下さい. 本当に複雑なものも含まれているでしょうし, 例えば, 障害報告に対する修正がちゃんとしたものであるかどうか 単にチェックするだけのとても簡単な作業もあるでしょう. まず, まだ誰にも割り当てられていない障害報告から作業を 始めて下さい. もし, 誰か他の人に割り当てが決まっているけれども 自分が作業可能だ, というものがあれば, 作業ができるかどうか— 既にテスト用パッチが用意されているのかどうか, あるいは その問題についてあなたが考えている, より進んだ考えに関して議論ができるかどうか, 割り当てられている人に電子メールで問い合わせて下さい. 貢献の仕方 一般的に, システムへの貢献は次の 6 つのカテゴリの1つ以上に分類されます: バグ報告と一般的な論評 報告するべきバグがあったり, 提案したいことがあれば: 一般的な 技術的関心事に関するアイデアや提案は &a.hackers; へメールしてください. 同様に, このような事柄に興味のある (そして膨大なメール! に耐えられる) 人は, &a.majordomo; へメールを送って hackers メーリングリストに参加すると良いでしょう. 情報については メーリングリスト を参照してください. バグを発見したり変更を送付しようとしている場合は &man.send-pr.1; プログラムか WEB ベースの send-pr を使用して報告してください. バグレポートの各項目を埋めるようにしてください. 65KB を超えるのでなければ, レポート中に直接 パッチを入れてくださって結構です. その場合, カット＆ペーストはしないで ください. カット＆ペーストではタブがスペースに展開されて パッチが使い物にならなくなってしまいます. 20KB を超える場合は, それらを compress して &man.uuencode.1; することも検討してください. とても大きくなる場合は ftp.FreeBSD.org:/pub/FreeBSD/incoming/ を利用してください. レポートがファイリングされれば, バグ報告の確認と トラッキング番号をメールで受け取るはずです. このトラッキング番号を覚えておき, 問題に関する詳細情報を bug-followup@FreeBSD.org に メールで送って更新できるようにしてください. 例えば "Re: kern/3377" のように, この番号をサブジェクト行に使用してください. すべてのバグレポートの追加情報は, この方法で送付されなければいけません. もしタイムリに (あなたの電子メール接続形態にもよりますが, 3日から 1週間) 確認を受けとれないとか, 何らかの理由で &man.send-pr.1; コマンドが 使用できない場合には, &a.bugs; へメールを送り, 誰か代りにバグ報告を 送付してもらうようたずねてください. 文書の変更 文書の変更は &a.doc; が監督しています. バグ報告と一般的な論評 に記述されているように send-pr コマンドを使用して, 提案や変更 (どんな些細なものでも歓迎します!) を送ってください. 現存のソースコードの変更 現存のソースコードへの追加または変更は, いくらかトリッキーな仕事で あり, core の FreeBSD 開発の現状にあなたがどれだけ通じているかに大 きく依存します. “FreeBSD-current”として知られる FreeBSD の特別な 継続的リリースがあります. FreeBSD-current は開発者の積極的な活動の 便宜のために, 色々な方法で利用可能になっています. FreeBSD-current の入手と使用方法についての詳しい情報については 最新の FreeBSD を追いかける を参照してください. 不幸にして古いソースをもとに仕事をすることは, 時々あなたの変更が時 代遅れ, または FreeBSD への簡単な再統合に合わなくなっていることを意 味します. システムの現状に関する議論がおこなわれている &a.announce; と &a.current; へ参加することで, この可能性を最小限にすることができます. 完全な最新のソースを変更のベースにできることが 確実になったと仮定し て, 次のステップは FreeBSD の保守担当者へ送る差分ファイルの生成です. これは &man.diff.1; コマンドを使用しておこないますが, “context diff”形式が好まれるようです. 例えば: &prompt.user; diff -c oldfile newfile または &prompt.user; diff -c -r olddir newdir これで指定されたソースファイルまたはディレクトリ階層に 対するコンテ キスト形式の差分が生成されます. 詳しい説明は &man.diff.1; のマ ニュアルページを参照してください. 差分ファイル (&man.patch.1; コマンドでテストできます) を作ったら, それらを FreeBSD に含めてもらうようメールで送ってください. バグ報告と一般的な論評 に記述されているように &man.send-pr.1; コマンドを使用してください. 差分ファイルだけを &a.hackers; へ送ってはいけません. 途方にくれてしまいます! 私たちは多忙なので, あなたの提案に大変感謝します (これはボランティアのプロジェクトです!). すぐに取りかかることはできませんが, 処理されるまでは ちゃんと pr データベースに残っています. あなたがそうした方がいいと思う場合 (例えば, ファイルの追加, 削除または名称変更など), 変更を tar ファイルにまとめ, &man.uuencode.1; プログラムにかけてください. Shar アーカイブも歓迎します. 例えばあなたがそれ自身のさらなる配布を管理する コピーライト問題を良 く分かっていないとか, 単に厳しいレビューをおこなっておらず, リリース する準備ができていないなど, あなたの変更が潜在的に不安定な性質をも つものである場合, &man.send-pr.1; で送付するよりむしろ &a.core; へ直接送ってください. コアチームメーリングリスト宛のメールは, 日々の仕 事のほとんどを FreeBSD でおこなっている人たちの, より小さなグルー プに届きます. このグループもまたとても忙しい ことに注意し て, 本当に必要な場合にコアチームの彼らにメールを 送るだけにしてください. コーディングスタイルに関する情報は man 9 intro および man 9 style を参照してください. コードを提出する前には, 少なくともこの情報を意識しておいてくださるようお願いします. 新たなコードやメジャーな付加価値の高いパッケージ 重要な大きい仕事の寄贈や, 重要な新しいフィーチャーを FreeBSD に追加 する稀な場合には, 変更点を tar/uuencode したファイルにして送るか, それらを私たちの ftp サイト ftp://ftp.FreeBSD.org/pub/FreeBSD/incoming/ へアップロードす ることのどちらかが通常必要になります. 大量のコードを伴った仕事の場合, コピーライトの神経過敏な問題が常に 出てきます. FreeBSD に含めるコードのコピーライトとして受け入れるこ とができるのは, 以下の二つです: BSD コピーライト. このコピーライトは“権利に縛られない”性格 と商用企業にとって一般的な魅力をもつために最も好まれま す. FreeBSD プロジェクトは商用利用を阻んだりせず, 何かを FreeBSD へ投資する気になった商業関係者による参加を積極的に奨励 します. GNU一般公有使用許諾, または“GPL”. このライセンスはコード を商用目的に使用する場合に余分な努力が求められるため, 私たち にあまり評判が良いというわけではありません. しかし, 私たちは 既に GPL 下の高品質なコード (コンパイラ, アセンブラ, テキスト フォーマッタ等) の提供を受けており, 私たちは現在それを必要と しています. そのため, このライセンスによる新たな貢献を拒絶す るというのは愚かなことでしょう. GPL 下のコードはソースツリー の別の部分, 現在のところ /sys/gnu か /usr/src/gnu に入っています. そのため, GPL が問題と なるような人は, 誰でも簡単にそれとわかるようになっています. これ以外のタイプのコピーライトによる寄贈は, FreeBSD へ含めることを 考慮する前に, 注意深いレビューを受けなければなりません. 作者が独自 のチャネルを通して配布しており, そのような変更をおこなうことを常に 奨励している場合でも, 特に限定的な商用のコピーライトが適用される寄 贈は一般に拒否されます. あなたの作品に “BSD-スタイル” のコピーライトを付けるには, 保護した いソースコードファイルすべての一番最初に 以下のテキストを入れて, %% の間を適切な情報に置き換えください. Copyright (c) %%適切な年%% %%あなたの名前%%, %%あなたの州%% %%郵便番号%%. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY %%あなたの名前%% ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL %%あなたの名前%% BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. $Id$ 便宜をはかるため, このテキストのコピーは次の場所に置いてあります. /usr/share/examples/etc/bsd-style-copyright. (訳注: 以下は神田敏広氏より寄贈された bsd-style-copyright の日本語訳です. ソースファイルに含めるものは原文の方であることに注意して ご利用ください. また, 原文との間に趣旨の差異が生じた場合, 原文の内容が FreeBSD プロジェクトの 意思であるものとします.) Copyright (C) [年] [あなたの名前] All rights reserved. ソースとバイナリ形式の再配布および使用は, 変更の有無にかかわらず以下の 条件を満たす場合に限り許可される: 1. ソースコードの再配布は, 上記の著作権表示・この条件のリスト・下記の 否認声明文を保持しなければならない. 2. バイナリ形式の再配布は, 上記の著作権表示・この条件のリスト・下記の 否認声明文を, 配布物と共に提供される文書および/または他の資料の中に 含めなければならない. (訳注:ここから「否認声明文」です) このソフトウェアは[あなたの名前]および貢献者によって ``あるがままの状態'' で提供され, 商品性と特定の目的に対する適合性についての暗黙の保証に留ま らず, いかなる明示および暗黙の保証を認めない. [あなたの名前]および貢献 者は, あらゆる直接的・間接的・偶発的・特殊的・典型的・必然的な損害 (代 替製品または代替サービスの獲得費; 効用・データ・利益の喪失; または業務 中断を含み, またそれだけに留まらない損害) に対して, たとえどのようにし て生じたとしても, そしてこのソフトウェアの使用によってどのようにであれ 生じる, 契約上であろうと, 厳密な責任内であろうと, あるいは不正行為 (過 失やそうでない場合を含む) における場合であろうとも, いかなる責任論上も, たとえそのような損害の可能性が予見されていたとしても, 一切の責任を持た ない. 翻訳: 神田敏広 御協力 (五十音順・敬称略): 池田研二, 内川 喜章, 藤村 英治, むらたしゅういちろう 杢野 雅一, 横田＠宇都宮 金銭, ハードウェアまたはインターネットアクセス FreeBSD プロジェクトの目的を進めるための寄付や, 私たちと同じような ボランティアの細く長い ! 努力を, 私たちは常に喜んで受け入れています. また一般的に私たちは自分達で 周辺機器を買う資金が不足しているため, 周辺機器のサポートを充実させるのに ハードウェアの寄付はとても重要です. 資金の寄付 FreeBSD プロジェクトは501(C3) (非営利) 企業ではないため, いかなる寄 付に対しても特別な税金の優遇措置を提供することができません. このような 寄付はプロジェクトを代表して FreeBSD, Inc により感謝をもって受け入れら れるでしょう. FreeBSD, Inc.は FreeBSD プロジェクトの推進とプロジェクトに企業とし ての最小限の体裁を持たせることを目的として, 1995年の初めに &a.jkh; と &a.dg; により設立されました. 寄付されたすべての資金は (最終的に FreeBSD, Inc.によりもたらされるであろうすべての利益も同様に) プロジェク トの目標を推進するためだけに使われるでしょう. 支払い先を FreeBSD, Inc. とした小切手を, 次の住所気付けで送ってください:
FreeBSD, Inc. c/o Jordan Hubbard 4041 Pike Lane, Suite F Concord CA, 94520
[現在 私書箱が開設されるまで一時的に Walnut Creek CDROM の住所を使用] 電信振替は次の所まで直接送れるでしょう:
Bank Of America Concord Main Office P.O. Box 37176 San Francisco CA, 94137-5176 Routing #: 121-000-358 Account #: 01411-07441 (FreeBSD, Inc.)
寄付に関することは全て電子メールもしくは上記 FreeBSD, Inc. の住所宛の郵政省メールにて &a.jkh までお送りくださるようお願いします. もし 寄贈者ギャラリー の節で匿名を希望される 方は, 寄付の際にその旨お伝えください. Thanks! ハードウェアの寄贈 FreeBSD プロジェクトは, 次の3つのカテゴリのどんなハードウェアの寄贈 も, 喜んで受け付けます: ディスクドライブ, メモリまたは完全なシステムといった一般用途のハー ドウェアは, 資金の寄付の節にある FreeBSD, Inc. の住所まで送っ てください. 進行中の受け入れテストのための ハードウェアが必要とされていま す. 新たなリリース毎に適切な逆行テストができるように, 私たちは現在, FreeBSD がサポートするすべてのコンポーネントの テストラボを設置しよう としています. 私たちにはまだ, たくさんの重要な部品 (ネットワークカード, マザーボードなど) が不足していますので, このような寄贈をしたいと思って いるならば, &a.dg; へコンタクトしてどの部品がまだ必要とされているか の情報を得てください. 現在 FreeBSD にサポートされていないハードウェアで, サポートに追 加して欲しいもの. 私たちが新しいハードウェアを受けとる前にそのタスクを 引き受けてくれる開発者を探す必要があるため, その部品を送る前に &a.core; にコンタクトを取ってください. インターネットアクセスの寄付 私たちは常に FTP, WWW や cvsup の新しいミラーサイトを募集しています. ミラーサイトになりたい場合には the FreeBSD project administrators admin@FreeBSD.org にコンタクトを取って, 詳し い情報を手に入れてください. 寄贈者ギャラリー FreeBSD プロジェクトは次の寄贈者に恩義を受けており, ここに公表して 感謝の意を表したいと思います. セントラルサーバプロジェクトへの寄贈者: 次に挙げる個人および企業からは, セントラルサーバマシンのための 部品の寄贈を頂いており, それによって freefall.FreeBSD.org をリプレースして新たに FreeBSD プロジェクトのセントラルサーバマシンを 構築することができました: &a.mbarkah と彼の所属する Hemisphere Online は, Pentium Pro (P6) 200Mhz CPU を寄贈してくださいました. ASA Computers は, Tyan 1662 マザーボード を寄贈してくださいました. ViaNet Communications の Joe McGuckin joe@via.net は, Kingston イーサネットコントローラ を寄贈してくださいました. Jack O'Neill jack@diamond.xtalwind.net は, NCR 53C875 SCSI コントローラカード を寄贈してくださいました. Alameda Networks の Ulf Zimmermann ulf@Alameda.net は, 128MB のメモリ, そして 4 GB のディスクドライブと匡体 を寄贈してくださいました. 直接的な資金提供: 次に挙げる個人および企業からは FreeBSD プロジェクトに対する直接的な 資金提供を頂いております: Annelise Anderson ANDRSN@HOOVER.STANFORD.EDU &a.dillon Epilogue Technology Corporation &a.sef Don Scott Wilde Gianmarco Giovannelli gmarco@masternet.it Josef C. Grosch joeg@truenorth.org Robert T. Morris &a.chuckr Imaginary Landscape, LLC. の Kenneth P. Stox ken@stox.sa.enteract.com Dmitry S. Kohmanyuk dk@dog.farm.org 日本の Laser5 はいくつかの FreeBSD CD の販売利益の一部を 寄付してくれました. 蕗出版 は, はじめての FreeBSD の売り上げの一部を FreeBSD プロジェクト及び XFree86 プロジェクトへ寄付してくれました. アスキー は FreeBSD 関連の書籍の売り上げの一部を FreeBSD プロジェクト及び FreeBSD 友の会へ寄付してくれました. 横河電機株式会社 からは FreeBSD プロジェクトへ多大な寄付をいただきました. BuffNET Pacific Solutions Siemens AG via Andre Albsmeier Chris Silva ハードウェアの寄贈者: 次に挙げる個人および企業からは, テストやデバイスドライバの開発 / サポート のためのハードウェアの寄贈を頂いております: Walnut Creek CDROM は, ネットワークへのアクセスおよび 他のハードウェアリソースの寄贈はいうまでもなく, 開発に使うための Pentium P5-90 と 486/DX2-66 EISA/VL のシステム数台を 提供してくださいました. TRW Financial Sysytems社は, PC 130台, 68 GB のファイルサーバ 3台, 12のイーサネット, ディスクレスコードのデバッグをおこなうための ルータ 2台及び ATM スイッチを提供してくださいました. また, 彼らは 2, 3人の FreeBSD ハッカーを雇って, FreeBSD に専念させて くださっております. ありがとうございます! Dermot McDonnell は, 東芝 XM3401B CD-ROM ドライブを 寄贈してくださいました. その CD-ROM ドライブは現在 freefall で使用されています. &a.chuck; は, 実験用のフロッピーテープストリーマを 寄付してくださいました. Larry Altneu larry@ALR.COM と &a.wilko;は, wt ドライバを改良するために Wangtek と Archive の QIC-02 テープドライブを提供してくださいました. Ernst Winter ewinter@lobo.muc.de は, このプロジェクトへ 2.88 MB のフロッピードライブを提供してくださいました. うまくいけば, これでフロッピーディスクドライバを書き直すための プレッシャーが増えるでしょう. ;-) Tekram Technologies は NCR ドライバや AMD ドライバと自社のカードの逆行テストのため FAST/ULTRA SCSI ホストアダプタ DC-390, DC-390U, DC-390F を 各１枚提供してくださいました. また, フリーな OS のためのドライバの ソースを自社の FTP サーバ ftp://ftp.tekram.com/scsi/FreeBSD/ で公開されていることも 称賛に値するでしょう. Larry M. Augustin lma@varesearch.com は Symbios Sym8751S SCSI カードを寄贈してくださっただけでなく, Ultra-2 や LVD をサポートする次期チップ Sym53c895 のものを含む データブックのセットと, 最新の Symbios SCSI チップが持つ先進的機能を 安全に使う方法について書かれた 最新のプログラミングマニュアルも 寄贈してくださいました. 本当にありがとうございます ! Christoph Kukulies kuku@FreeBSD.org は, IDE CD-ROM ドライバ開発用の FX120 12 倍速 Mitsumi CD-ROM ドライブ を提供してくださいました. 特筆すべき寄贈者: Walnut Creek CDROM は, 言い表せないほど多くの寄付をしてくださいました (詳細は FreeBSD 小史を参照). 特に, 私たちのもともとのプライマリ開発マシンである freefall.FreeBSD.org, テストおよびビルドマシンである thud.FreeBSD.org で使用しているハードウェアに対し 感謝したいと思います. また彼らには, 数年にわたる色々な貢献者への資金提供や, インターネット への T1 コネクションの無制限使用を提供して 頂いた恩義があります. interface business GmbH, Dresden は, &a.joerg; を根気よく サポートしてくださいました. 彼は本職より FreeBSD の仕事を好みがちであり, 彼個人の接続があまりに 遅くなったり途切れたりして仕事にならない時は必ず interface business の (非常に高価な) EUnet インターネット接続に頼ったものです... Berkeley Software Design, Inc. は, 同社の DOS エミュレータのコードを BSD コミュ ニティ全体に対して提供してくれました. このコードは, doscmd コマンドに利用されています. コアチームの卒業生 次に挙げる人々は()で記した期間, FreeBSD コアチームのメンバーでした. FreeBSD プロジェクトにおける彼らの努力に感謝の意を表します. だいたいの年代順: &a.guido (1995 - 1999) &a.dyson (1993 - 1998) &a.nate (1992 - 1996) &a.rgrimes (1992 - 1995) Andreas Schulz (1992 - 1995) &a.csgr (1993 - 1995) &a.paul (1992 - 1995) &a.smace (1993 - 1994) Andrew Moore (1993 - 1994) Christoph Robitschko (1993 - 1994) J. T. Conklin (1992 - 1993) BSD派生ソフトウェアへのコントリビュータ このソフトウェアは最初は William F. Jolitz の 386BSD release 0.1 から派生しましたが, オリジナルの 386BSD に固有のコードはほとんど 残っていません. このソフトウェアは基本的にはカリフォルニア大学 バークレイ校の Computer Science Research Group (CSRG) とその共同研究者 たちによる 4.4BSD-Lite リリースから再実装されました. また, NetBSD や OpenBSD の一部も FreeBSD に取り込まれています. したがって私たちは NetBSD と OpenBSD へ貢献した人々すべてに感謝します. その他の FreeBSD へのコントリビュータ (名前でアルファベット順に): ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp AMAGAI Yoshiji amagai@nue.org Aaron Bornstein aaronb@j51.com Aaron Smith aaron@mutex.org Achim Patzner ap@noses.com Ada T Lim ada@bsd.org Adam Baran badam@mw.mil.pl Adam Glass glass@postgres.berkeley.edu Adam McDougall mcdouga9@egr.msu.edu Adrian Colley aecolley@ois.ie Adrian Hall adrian@ibmpcug.co.uk Adrian Mariano adrian@cam.cornell.edu Adrian Steinmann ast@marabu.ch Adam Strohl troll@digitalspark.net Adrian T. Filipi-Martin atf3r@agate.cs.virginia.edu Ajit Thyagarajan unknown Akio Morita amorita@meadow.scphys.kyoto-u.ac.jp Akira SAWADA unknown Akira Watanabe akira@myaw.ei.meisei-u.ac.jp Akito Fujita fujita@zoo.ncl.omron.co.jp Alain Kalker A.C.P.M.Kalker@student.utwente.nl Alan Bawden alan@curry.epilogue.com Alec Wolman wolman@cs.washington.edu Aled Morris aledm@routers.co.uk Alex garbanzo@hooked.net Alex D. Chen dhchen@Canvas.dorm7.nccu.edu.tw Alex G. Bulushev bag@demos.su Alex Le Heux alexlh@funk.org Alex Perel veers@disturbed.net Alexander B. Povolotsky tarkhil@mgt.msk.ru Alexander Leidinger netchild@wurzelausix.CS.Uni-SB.DE Alexander Langer alex@cichlids.com Alexandre Snarskii snar@paranoia.ru Alistair G. Crooks agc@uts.amdahl.com Allan Saddi asaddi@philosophysw.com Allen Campbell allenc@verinet.com Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp Amancio Hasty hasty@star-gate.com Amir Farah amir@comtrol.com Amy Baron amee@beer.org Anatoly A. Orehovsky tolik@mpeks.tomsk.su Anatoly Vorobey mellon@pobox.com Anders Nordby nickerne@nome.no Anders Thulin Anders.X.Thulin@telia.se Andras Olah olah@cs.utwente.nl Andre Albsmeier Andre.Albsmeier@mchp.siemens.de Andre Oppermann andre@pipeline.ch Andreas Haakh ah@alman.robin.de Andreas Kohout shanee@rabbit.augusta.de Andreas Lohr andreas@marvin.RoBIN.de Andreas Schulz unknown Andreas Wetzel mickey@deadline.snafu.de Andreas Wrede andreas@planix.com Andres Vega Garcia unknown Andrew Atrens atreand@statcan.ca Andrew Boothman andrew@cream.org Andrew Gillham gillham@andrews.edu Andrew Gordon andrew.gordon@net-tel.co.uk Andrew Herbert andrew@werple.apana.org.au Andrew J. Korty ajk@purdue.edu Andrew L. Moore alm@mclink.com Andrew McRae amcrae@cisco.com Andrew Stevenson andrew@ugh.net.au Andrew Timonin tim@pool1.convey.ru Andrew V. Stesin stesin@elvisti.kiev.ua Andrew Webster awebster@dataradio.com Andy Farkas andyf@speednet.com.au Andy Valencia ajv@csd.mot.com Andy Whitcroft andy@sarc.city.ac.uk Angelo Turetta ATuretta@stylo.it Anthony C. Chavez magus@xmission.com Anthony Yee-Hang Chan yeehang@netcom.com Anton Berezin tobez@plab.ku.dk Antti Kaipila anttik@iki.fi Are Bryne are.bryne@communique.no Ari Suutari ari@suutari.iki.fi Arjan de Vet devet@IAEhv.nl Arne Henrik Juul arnej@Lise.Unit.NO Assar Westerlund assar@sics.se Atsushi Furuta furuta@sra.co.jp Atsushi Murai amurai@spec.co.jp Bakul Shah bvs@bitblocks.com Barry Bierbauch pivrnec@vszbr.cz Barry Lustig barry@ictv.com Ben Hutchinson benhutch@xfiles.org.uk Ben Jackson unknown Ben Smithurst ben@scientia.demon.co.uk Ben Walter bwalter@itachi.swcp.com Benjamin Lewis bhlewis@gte.net Bernd Rosauer br@schiele-ct.de Bill Kish kish@osf.org Bill Trost trost@cloud.rain.com Blaz Zupan blaz@amis.net Bob Van Valzah Bob@whitebarn.com Bob Willcox bob@luke.pmr.com Boris Staeblow balu@dva.in-berlin.de Boyd R. Faulkner faulkner@asgard.bga.com Brad Karp karp@eecs.harvard.edu Bradley Dunn bradley@dunn.org Brandon Fosdick bfoz@glue.umd.edu Brandon Gillespie brandon@roguetrader.com &a.wlloyd Bob Wilcox bob@obiwan.uucp Boyd Faulkner faulkner@mpd.tandem.com Brent J. Nordquist bjn@visi.com Brett Lymn blymn@mulga.awadi.com.AU Brett Taylor brett@peloton.runet.edu Brian Campbell brianc@pobox.com Brian Clapper bmc@willscreek.com Brian Cully shmit@kublai.com Brian Handy handy@lambic.space.lockheed.com Brian Litzinger brian@MediaCity.com Brian McGovern bmcgover@cisco.com Brian Moore ziff@houdini.eecs.umich.edu Brian R. Haug haug@conterra.com Brian Tao taob@risc.org Brion Moss brion@queeg.com Bruce A. Mah bmah@ca.sandia.gov Bruce Albrecht bruce@zuhause.mn.org Bruce Gingery bgingery@gtcs.com Bruce J. Keeler loodvrij@gridpoint.com Bruce Murphy packrat@iinet.net.au Bruce Walter walter@fortean.com Carey Jones mcj@acquiesce.org Carl Fongheiser cmf@netins.net Carl Mascott cmascott@world.std.com Casper casper@acc.am Castor Fu castor@geocast.com Cejka Rudolf cejkar@dcse.fee.vutbr.cz Chain Lee chain@110.net Charles Hannum mycroft@ai.mit.edu Charles Henrich henrich@msu.edu Charles Mott cmott@srv.net Charles Owens owensc@enc.edu Chet Ramey chet@odin.INS.CWRU.Edu Chia-liang Kao clkao@CirX.ORG Chiharu Shibata chi@bd.mbn.or.jp Chip Norkus unknown Choi Jun Ho junker@jazz.snu.ac.kr Chris Csanady cc@tarsier.ca.sandia.gov Chris Dabrowski chris@vader.org Chris Dillon cdillon@wolves.k12.mo.us Chris Shenton cshenton@angst.it.hq.nasa.gov Chris D. Faulhaber jedgar@fxp.org Chris Stenton jacs@gnome.co.uk Chris Timmons skynyrd@opus.cts.cwu.edu Chris Torek torek@ee.lbl.gov Christian Gusenbauer cg@fimp01.fim.uni-linz.ac.at Christian Haury Christian.Haury@sagem.fr Christian Weisgerber naddy@bigeye.rhein-neckar.de Christoph P. Kukulies kuku@FreeBSD.org Christoph Robitschko chmr@edvz.tu-graz.ac.at Christoph Weber-Fahr wefa@callcenter.systemhaus.net Christopher G. Demetriou cgd@postgres.berkeley.edu Christopher T. Johnson cjohnson@neunacht.netgsi.com Chrisy Luke chrisy@flix.net Chuck Hein chein@cisco.com Clive Lin clive@CiRX.ORG Colman Reilly careilly@tcd.ie Conrad Sabatier conrads@neosoft.com Coranth Gryphon gryphon@healer.com Cornelis van der Laan nils@guru.ims.uni-stuttgart.de Cove Schneider cove@brazil.nbn.com Craig Leres leres@ee.lbl.gov Craig Loomis unknown Craig Metz cmetz@inner.net Craig Spannring cts@internetcds.com Craig Struble cstruble@vt.edu Cristian Ferretti cfs@riemann.mat.puc.cl Curt Mayer curt@toad.com Cy Schubert cschuber@uumail.gov.bc.ca DI. Christian Gusenbauer cg@scotty.edvz.uni-linz.ac.at Dai Ishijima ishijima@tri.pref.osaka.jp Daisuke Watanabe NU7D-WTNB@asahi-net.or.jp Damian Hamill damian@cablenet.net Dan Cross tenser@spitfire.ecsel.psu.edu Dan Lukes dan@obluda.cz Dan Nelson dnelson@emsphone.com Dan Walters hannibal@cyberstation.net Daniel M. Eischen deischen@iworks.InterWorks.org Daniel O'Connor doconnor@gsoft.com.au Daniel Poirot poirot@aio.jsc.nasa.gov Daniel Rock rock@cs.uni-sb.de Danny Egen unknown Danny J. Zerkel dzerkel@phofarm.com Darren Reed avalon@coombs.anu.edu.au Dave Adkins adkin003@tc.umn.edu Dave Andersen angio@aros.net Dave Blizzard dblizzar@sprynet.com Dave Bodenstab imdave@synet.net Dave Burgess burgess@hrd769.brooks.af.mil Dave Chapeskie dchapes@ddm.on.ca Dave Cornejo dave@dogwood.com Dave Edmondson davided@sco.com Dave Glowacki dglo@ssec.wisc.edu Dave Marquardt marquard@austin.ibm.com Dave Tweten tweten@FreeBSD.org David A. Adkins adkin003@tc.umn.edu David A. Bader dbader@umiacs.umd.edu David Borman dab@bsdi.com David Dawes dawes@XFree86.org David Filo filo@yahoo.com David Holland dholland@eecs.harvard.edu David Holloway daveh@gwythaint.tamis.com David Horwitt dhorwitt@ucsd.edu David Hovemeyer daveho@infocom.com David Jones dej@qpoint.torfree.net David Kelly dkelly@tomcat1.tbe.com David Kulp dkulp@neomorphic.com David L. Nugent davidn@blaze.net.au David Leonard d@scry.dstc.edu.au David Malone dwmalone@maths.tcd.ie David Muir Sharnoff muir@idiom.com David S. Miller davem@jenolan.rutgers.edu David Wolfskill dhw@whistle.com Dean Gaudet dgaudet@arctic.org Dean Huxley dean@fsa.ca Denis Fortin unknown Dennis Glatting dennis.glatting@software-munitions.com Denton Gentry denny1@home.com Derek Inksetter derek@saidev.com Dima Sivachenko dima@Chg.RU Dirk Keunecke dk@panda.rhein-main.de Dirk Nehrling nerle@pdv.de Dmitry Khrustalev dima@xyzzy.machaon.ru Dmitry Kohmanyuk dk@farm.org Dom Mitchell dom@myrddin.demon.co.uk Dominik Brettnacher domi@saargate.de Dominik Rother dr@domix.de Don Croyle croyle@gelemna.ft-wayne.in.us &a.whiteside; Don Morrison dmorrisn@u.washington.edu Don Yuniskis dgy@rtd.com Donald Maddox dmaddox@conterra.com - Doug Barton studded@dal.net + Doug Barton Doug@gorean.org Douglas Ambrisko ambrisko@whistle.com Douglas Carmichael dcarmich@mcs.com Douglas Crosher dtc@scrooge.ee.swin.oz.au Drew Derbyshire ahd@kew.com Duncan Barclay dmlb@ragnet.demon.co.uk Dustin Sallings dustin@spy.net Eckart "Isegrim" Hofmann Isegrim@Wunder-Nett.org Ed Gold vegold01@starbase.spd.louisville.edu Ed Hudson elh@p5.spnet.com Edward Wang edward@edcom.com Edwin Groothus edwin@nwm.wan.philips.com Eiji-usagi-MATSUmoto usagi@clave.gr.jp ELISA Font Project Elmar Bartel bartel@informatik.tu-muenchen.de Eric A. Griff eagriff@global2000.net Eric Blood eblood@cs.unr.edu Eric J. Haug ejh@slustl.slu.edu Eric J. Schwertfeger eric@cybernut.com Eric L. Hernes erich@lodgenet.com Eric P. Scott eps@sirius.com Eric Sprinkle eric@ennovatenetworks.com Erich Stefan Boleyn erich@uruk.org Erik E. Rantapaa rantapaa@math.umn.edu Erik H. Moe ehm@cris.com Ernst Winter ewinter@lobo.muc.de Espen Skoglund esk@ira.uka.de Eugene M. Kim astralblue@usa.net Eugene Radchenko genie@qsar.chem.msu.su Eugeny Kuzakov CoreDumped@lab321.ru Evan Champion evanc@synapse.net Faried Nawaz fn@Hungry.COM Flemming Jacobsen fj@tfs.com Fong-Ching Liaw fong@juniper.net Francis M J Hsieh mjshieh@life.nthu.edu.tw Frank Bartels knarf@camelot.de Frank Chen Hsiung Chan frankch@waru.life.nthu.edu.tw Frank Durda IV uhclem@nemesis.lonestar.org Frank MacLachlan fpm@n2.net Frank Nobis fn@Radio-do.de Frank Volf volf@oasis.IAEhv.nl Frank ten Wolde franky@pinewood.nl Frank van der Linden frank@fwi.uva.nl Fred Cawthorne fcawth@jjarray.umn.edu Fred Gilham gilham@csl.sri.com Fred Templin templin@erg.sri.com Frederick Earl Gray fgray@rice.edu FUJIMOTO Kensaku fujimoto@oscar.elec.waseda.ac.jp FUJISHIMA Satsuki k5@respo.or.jp FURUSAWA Kazuhisa furusawa@com.cs.osakafu-u.ac.jp Gabor Kincses gabor@acm.org Gabor Zahemszky zgabor@CoDe.hu G. Adam Stanislavadam@whizkidtech.net Garance A Drosehn gad@eclipse.its.rpi.edu Gareth McCaughan gjm11@dpmms.cam.ac.uk Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Gary J. garyj@rks32.pcs.dec.com Gary Kline kline@thought.org Gaspar Chilingarov nightmar@lemming.acc.am Gea-Suan Lin gsl@tpts4.seed.net.tw Geoff Rehmet csgr@alpha.ru.ac.za Georg Wagner georg.wagner@ubs.com Gerard Roudier groudier@club-internet.fr Gianmarco Giovannelli gmarco@giovannelli.it Gil Kloepfer Jr. gil@limbic.ssdl.com Gilad Rom rom_glsa@ein-hashofet.co.il Ginga Kawaguti ginga@amalthea.phys.s.u-tokyo.ac.jp Giles Lean giles@nemeton.com.au Glen Foster gfoster@gfoster.com Glenn Johnson gljohns@bellsouth.net Godmar Back gback@facility.cs.utah.edu Goran Hammarback goran@astro.uu.se Gord Matzigkeit gord@enci.ucalgary.ca Gordon Greeff gvg@uunet.co.za Graham Wheeler gram@cdsec.com Greg A. Woods woods@zeus.leitch.com Greg Ansley gja@ansley.com Greg Troxel gdt@ir.bbn.com Greg Ungerer gerg@stallion.oz.au Gregory Bond gnb@itga.com.au Gregory D. Moncreaff moncrg@bt340707.res.ray.com Guy Harris guy@netapp.com Guy Helmer ghelmer@cs.iastate.edu HAMADA Naoki hamada@astec.co.jp HONDA Yasuhiro honda@kashio.info.mie-u.ac.jp HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp Hannu Savolainen hannu@voxware.pp.fi Hans Huebner hans@artcom.de Hans Petter Bieker zerium@webindex.no Hans Zuidam hans@brandinnovators.com Harlan Stenn Harlan.Stenn@pfcs.com Harold Barker hbarker@dsms.com Havard Eidnes Havard.Eidnes@runit.sintef.no Heikki Suonsivu hsu@cs.hut.fi Heiko W. Rupp unknown Helmut F. Wirth hfwirth@ping.at Henrik Vestergaard Draboel hvd@terry.ping.dk Herb Peyerl hpeyerl@NetBSD.org Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp Hidekazu Kuroki hidekazu@cs.titech.ac.jp Hideki Yamamoto hyama@acm.org Hideyuki Suzuki hideyuki@sat.t.u-tokyo.ac.jp Hirayama Issei iss@mail.wbs.ne.jp Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp Hironori Ikura hikura@kaisei.org Hiroshi Nishikawa nis@pluto.dti.ne.jp Hiroya Tsubakimoto unknown Holger Veit Holger.Veit@gmd.de Holm Tiffe holm@geophysik.tu-freiberg.de Horance Chou horance@freedom.ie.cycu.edu.tw Horihiro Kumagai kuma@jp.FreeBSD.org HOTARU-YA hotaru@tail.net Hr.Ladavac lada@ws2301.gud.siemens.co.at Hubert Feyrer hubertf@NetBSD.ORG Hugh F. Mahon hugh@nsmdserv.cnd.hp.com Hugh Mahon h_mahon@fc.hp.com Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw IMAI Takeshi take-i@ceres.dti.ne.jp IMAMURA Tomoaki tomoak-i@is.aist-nara.ac.jp Ian Dowse iedowse@maths.tcd.ie Ian Holland ianh@tortuga.com.au Ian Struble ian@broken.net Ian Vaudrey i.vaudrey@bigfoot.com Igor Khasilev igor@jabber.paco.odessa.ua Igor Roshchin str@giganda.komkon.org Igor Sviridov siac@ua.net Igor Vinokurov igor@zynaps.ru Ikuo Nakagawa ikuo@isl.intec.co.jp Ilya V. Komarov mur@lynx.ru Issei Suzuki issei@jp.FreeBSD.org Itsuro Saito saito@miv.t.u-tokyo.ac.jp IWASHITA Yoji shuna@pop16.odn.ne.jp IWASHITA Yoji shuna@pop16.odn.ne.jp J. Bryant jbryant@argus.flash.net J. David Lowe lowe@saturn5.com J. Han hjh@best.com J. Hawk jhawk@MIT.EDU J.T. Conklin jtc@cygnus.com J.T. Jang keith@email.gcn.net.tw Jack jack@zeus.xtalwind.net Jacob Bohn Lorensen jacob@jblhome.ping.mk Jagane D Sundar jagane@netcom.com Jake Burkholder jake@checker.org Jake Hamby jehamby@lightside.com James Clark jjc@jclark.com James D. Stewart jds@c4systm.com James Jegers jimj@miller.cs.uwm.edu James Raynard fhackers@jraynard.demon.co.uk James T. Liu jtliu@phlebas.rockefeller.edu James da Silva jds@cs.umd.edu Jan Conard charly@fachschaften.tu-muenchen.de Jan Koum jkb@FreeBSD.org Janick Taillandier Janick.Taillandier@ratp.fr Janusz Kokot janek@gaja.ipan.lublin.pl Jarle Greipsland jarle@idt.unit.no Jason Garman init@risen.org Jason Thorpe thorpej@NetBSD.org Jason Wright jason@OpenBSD.org Jason Young doogie@forbidden-donut.anet-stl.com Javier Martin Rueda jmrueda@diatel.upm.es Jay Fenlason hack@datacube.com Jaye Mathisen mrcpu@cdsnet.net Jeff Bartig jeffb@doit.wisc.edu Jeff Forys jeff@forys.cranbury.nj.us Jeff Kletsky Jeff@Wagsky.com Jeffrey Evans evans@scnc.k12.mi.us Jeffrey Wheat jeff@cetlink.net Jens Schweikhardt schweikh@noc.dfn.d Jeremy Allison jallison@whistle.com Jeremy Chatfield jdc@xinside.com Jeremy Lea reg@shale.csir.co.za Jeremy Prior unknown Jeroen Ruigrok/Asmodai asmodai@wxs.nl Jesse Rosenstock jmr@ugcs.caltech.edu Jian-Da Li jdli@csie.nctu.edu.tw Jim Babb babb@FreeBSD.org Jim Binkley jrb@cs.pdx.edu Jim Carroll jim@carroll.com Jim Flowers jflowers@ezo.net Jim Leppek jleppek@harris.com Jim Lowe james@cs.uwm.edu Jim Mattson jmattson@sonic.net Jim Mercer jim@komodo.reptiles.org Jim Wilson wilson@moria.cygnus.com Jimbo Bahooli griffin@blackhole.iceworld.org Jin Guojun jin@george.lbl.gov Joachim Kuebart unknown Joao Carlos Mendes Luis jonny@jonny.eng.br Jochen Pohl jpo.drs@sni.de Joe "Marcus" Clarke marcus@miami.edu Joe Abley jabley@clear.co.nz Joe Jih-Shian Lu jslu@dns.ntu.edu.tw Joe Orthoefer j_orthoefer@tia.net Joe Traister traister@mojozone.org Joel Faedi Joel.Faedi@esial.u-nancy.fr Joel Ray Holveck joelh@gnu.org Joel Sutton sutton@aardvark.apana.org.au Johan Granlund johan@granlund.nu Johan Karlsson k@numeri.campus.luth.se Johan Larsson johan@moon.campus.luth.se Johann Tonsing jtonsing@mikom.csir.co.za Johannes Helander unknown Johannes Stille unknown John Beckett jbeckett@southern.edu John Beukema jbeukema@hk.super.net John Brezak unknown John Capo jc@irbs.com John F. Woods jfw@jfwhome.funhouse.com John Goerzen jgoerzen@alexanderwohl.complete.org John Hay jhay@mikom.csir.co.za John Heidemann johnh@isi.edu John Hood cgull@owl.org John Kohl unknown John Lind john@starfire.mn.org John Mackin john@physiol.su.oz.au John P johnp@lodgenet.com John Perry perry@vishnu.alias.net John Preisler john@vapornet.com John Rochester jr@cs.mun.ca John Sadler john_sadler@alum.mit.edu John Saunders john@pacer.nlc.net.au John W. DeBoskey jwd@unx.sas.com John Wehle john@feith.com John Woods jfw@eddie.mit.edu Jon Morgan morgan@terminus.trailblazer.com Jonathan H N Chin jc254@newton.cam.ac.uk Jonathan Hanna jh@pc-21490.bc.rogers.wave.ca Jorge Goncalves j@bug.fe.up.pt Jorge M. Goncalves ee96199@tom.fe.up.pt Jos Backus jbackus@plex.nl Jose M. Alcaide jose@we.lc.ehu.es Jose Marques jose@nobody.org Josef Grosch jgrosch@superior.mooseriver.com Josef Karthauser joe@uk.FreeBSD.org Joseph Stein joes@wstein.com Josh Gilliam josh@quick.net Josh Tiefenbach josh@ican.net Juergen Lock nox@jelal.hb.north.de Juha Inkari inkari@cc.hut.fi Jukka A. Ukkonen jua@iki.fi Julian Assange proff@suburbia.net Julian Coleman j.d.coleman@ncl.ac.uk &a.jhs Julian Jenkins kaveman@magna.com.au Junichi Satoh junichi@jp.FreeBSD.org Junji SAKAI sakai@jp.FreeBSD.org Junya WATANABE junya-w@remus.dti.ne.jp K.Higashino a00303@cc.hc.keio.ac.jp KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp Kai Vorma vode@snakemail.hut.fi Kaleb S. Keithley kaleb@ics.com Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp Kapil Chowksey kchowksey@hss.hns.com Karl Denninger karl@mcs.com Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com Kato Takenori kato@eclogite.eps.nagoya-u.ac.jp KATO Tsuguru tkato@prontomail.ne.jp Kawanobe Koh kawanobe@st.rim.or.jp Kazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jp Kazuo Horikawa horikawa@jp.FreeBSD.org Kees Jan Koster kjk1@ukc.ac.uk Keith Bostic bostic@bostic.com Keith E. Walker unknown Keith Moore unknown Keith Sklower unknown Kelly Yancey kbyanc@posi.net Ken Hornstein unknown Ken Key key@cs.utk.edu Ken Mayer kmayer@freegate.com Kenji Saito marukun@mx2.nisiq.net Kenji Tomita tommyk@da2.so-net.or.jp Kenneth Furge kenneth.furge@us.endress.com Kenneth Monville desmo@bandwidth.org Kenneth R. Westerback krw@tcn.net Kenneth Stailey kstailey@gnu.ai.mit.edu Kent Talarico kent@shipwreck.tsoft.net Kent Vander Velden graphix@iastate.edu Kentaro Inagaki JBD01226@niftyserve.ne.jp Kevin Bracey kbracey@art.acorn.co.uk Kevin Day toasty@dragondata.com Kevin Lahey kml@nas.nasa.gov Kevin Lokevlo@hello.com.tw Kevin Street street@iname.com Kevin Van Maren vanmaren@fast.cs.utah.edu Kiril Mitev kiril@ideaglobal.com Kiroh HARADA kiroh@kh.rim.or.jp Klaus Klein kleink@layla.inka.de Klaus-J. Wolf Yanestra@t-online.de Koichi Sato copan@ppp.fastnet.or.jp Kostya Lukin lukin@okbmei.msk.su Kouichi Hirabayashi kh@mogami-wire.co.jp Kurt D. Zeilenga Kurt@Boolean.NET Kurt Olsen kurto@tiny.mcs.usu.edu L. Jonas Olsson ljo@ljo-slip.DIALIN.CWRU.Edu Lars Köller Lars.Koeller@Uni-Bielefeld.DE Larry Altneu larry@ALR.COM Laurence Lopez lopez@mv.mv.com Lee Cremeans lcremean@tidalwave.net Liang Tai-hwa avatar@www.mmlab.cse.yzu.edu.tw Lon Willett lon%softt.uucp@math.utah.edu Louis A. Mamakos louie@TransSys.COM Louis Mamakos loiue@TransSys.com Lucas James Lucas.James@ldjpc.apana.org.au Lyndon Nerenberg lyndon@orthanc.com M.C. Wong unknown MANTANI Nobutaka nobutaka@nobutaka.com MIHIRA Sanpei Yoshiro sanpei@sanpei.org MITA Yoshio mita@jp.FreeBSD.org MITSUNAGA Noriaki mitchy@er.ams.eng.osaka-u.ac.jp MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp Magnus Enbom dot@tinto.campus.luth.se Mahesh Neelakanta mahesh@gcomm.com Makoto MATSUSHITA matusita@jp.FreeBSD.org Makoto WATANABE watanabe@zlab.phys.nagoya-u.ac.jp Malte Lance malte.lance@gmx.net Manu Iyengar iyengar@grunthos.pscwa.psca.com Marc Frajola marc@dev.com Marc Ramirez mrami@mramirez.sy.yale.edu Marc Slemko marcs@znep.com Marc van Kempen wmbfmk@urc.tue.nl Marc van Woerkom van.woerkom@netcologne.de Marcel Moolenaar marcel@scc.nl Marcin Cieslak saper@system.pl Mario Sergio Fujikawa Ferreira lioux@gns.com.br Mark Andrews unknown Mark Cammidge mark@gmtunx.ee.uct.ac.za Mark Diekhans markd@grizzly.com Mark Huizer xaa@stack.nl Mark J. Taylor mtaylor@cybernet.com Mark Krentel krentel@rice.edu Mark Mayo markm@vmunix.com Mark Thompson thompson@tgsoft.com Mark Tinguely tinguely@plains.nodak.edu Mark Treacy unknown Mark Valentine mark@linus.demon.co.uk + + Markus Holmberg saska@acc.umu.se + + Martin Birgmeier Martin Ibert mib@ppe.bb-data.de Martin Kammerhofer dada@sbox.tu-graz.ac.at Martin Renters martin@tdc.on.ca Martti Kuparinen martti.kuparinen@ericsson.com Masachika ISHIZUKA ishizuka@isis.min.ntt.jp Mas.TAKEMURA unknown Masafumi NAKANE max@wide.ad.jp Masahiro Sekiguchi seki@sysrap.cs.fujitsu.co.jp Masanobu Saitoh msaitoh@spa.is.uec.ac.jp Masanori Kanaoka kana@saijo.mke.mei.co.jp Masanori Kiriake seiken@ARGV.AC Masatoshi TAMURA tamrin@shinzan.kuee.kyoto-u.ac.jp Mats Lofkvist mal@algonet.se Matt Bartley mbartley@lear35.cytex.com Matt Thomas matt@3am-software.com Matt White mwhite+@CMU.EDU Matthew C. Mead mmead@Glock.COM Matthew Cashdollar mattc@rfcnet.com Matthew Flatt mflatt@cs.rice.edu Matthew Fuller fullermd@futuresouth.com Matthew Stein matt@bdd.net Matthias Pfaller leo@dachau.marco.de Matthias Scheler tron@netbsd.org Mattias Gronlund Mattias.Gronlund@sa.erisoft.se Mattias Pantzare pantzer@ludd.luth.se Maurice Castro maurice@planet.serc.rmit.edu.au Max Euston meuston@jmrodgers.com Max Khon fjoe@husky.iclub.nsu.ru Maxim Bolotin max@rsu.ru Maxim V. Sobolev sobomax@altavista.net Micha Class michael_class@hpbbse.bbn.hp.com Michael Butler imb@scgt.oz.au Michael Butschky butsch@computi.erols.com Michael Clay mclay@weareb.org Michael Elbel me@FreeBSD.org Michael Galassi nerd@percival.rain.com Michael Hancock michaelh@cet.co.jp Michael Hohmuth hohmuth@inf.tu-dresden.de Michael Perlman canuck@caam.rice.edu Michael Petry petry@netwolf.NetMasters.com Michael Reifenberger root@totum.plaut.de Michael Sardo jaeger16@yahoo.com Michael Searle searle@longacre.demon.co.uk Michal Listos mcl@Amnesiac.123.org Michio Karl Jinbo karl@marcer.nagaokaut.ac.jp Miguel Angel Sagreras msagre@cactus.fi.uba.ar Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp Mika Nystrom mika@cs.caltech.edu Mikael Hybsch micke@dynas.se Mikael Karpberg karpen@ocean.campus.luth.se Mike Del repenting@hotmail.com Mike Durian durian@plutotech.com Mike Durkin mdurkin@tsoft.sf-bay.org Mike E. Matsnev mike@azog.cs.msu.su Mike Evans mevans@candle.com Mike Grupenhoff kashmir@umiacs.umd.edu Mike Hibler mike@marker.cs.utah.edu Mike Karels unknown Mike McGaughey mmcg@cs.monash.edu.au Mike Meyer mwm@shiva.the-park.com Mike Mitchell mitchell@ref.tfs.com Mike Murphy mrm@alpharel.com Mike Peck mike@binghamton.edu Mike Spengler mks@msc.edu Mikhail A. Sokolov mishania@demos.su Mikhail Teterin mi@aldan.ziplink.net Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW Mitsuru Yoshida mitsuru@riken.go.jp Monte Mitzelfelt monte@gonefishing.org Morgan Davis root@io.cts.com Mostyn Lewis mostyn@mrl.com Motomichi Matsuzaki mzaki@e-mail.ne.jp Motoyuki Kasahara m-kasahr@sra.co.jp Motoyuki Konno motoyuki@snipe.rim.or.jp Murray Stokely murray@cdrom.com N.G.Smith ngs@sesame.hensa.ac.uk NAGAO Tadaaki nagao@cs.titech.ac.jp NAKAJI Hiroyuki nakaji@tutrp.tut.ac.jp NAKAMURA Kazushi nkazushi@highway.or.jp NAKAMURA Motonori motonori@econ.kyoto-u.ac.jp NIIMI Satoshi sa2c@and.or.jp NOKUBI Hirotaka h-nokubi@yyy.or.jp Nadav Eiron nadav@barcode.co.il Nanbor Wang nw1@cs.wustl.edu Naofumi Honda honda@Kururu.math.sci.hokudai.ac.jp Naoki Hamada nao@tom-yam.or.jp Narvi narvi@haldjas.folklore.ee Nathan Ahlstrom nrahlstr@winternet.com Nathan Dorfman nathan@rtfm.net Neal Fachan kneel@ishiboo.com Neil Blakey-Milner nbm@rucus.ru.ac.za Niall Smart rotel@indigo.ie Nick Barnes Nick.Barnes@pobox.com Nick Handel nhandel@NeoSoft.com Nick Hilliard nick@foobar.org &a.nsayer; Nick Williams njw@cs.city.ac.uk Nickolay N. Dudorov nnd@itfs.nsk.su Niklas Hallqvist niklas@filippa.appli.se Nisha Talagala nisha@cs.berkeley.edu No Name ZW6T-KND@j.asahi-net.or.jp No Name adrian@virginia.edu No Name alex@elvisti.kiev.ua No Name anto@netscape.net No Name bobson@egg.ics.nitch.ac.jp No Name bovynf@awe.be No Name burg@is.ge.com No Name chris@gnome.co.uk No Name colsen@usa.net No Name coredump@nervosa.com No Name dannyman@arh0300.urh.uiuc.edu No Name davids@SECNET.COM No Name derek@free.org No Name devet@adv.IAEhv.nl No Name djv@bedford.net No Name dvv@sprint.net No Name enami@ba2.so-net.or.jp No Name flash@eru.tubank.msk.su No Name flash@hway.ru No Name fn@pain.csrv.uidaho.edu No Name gclarkii@netport.neosoft.com No Name gordon@sheaky.lonestar.org No Name graaf@iae.nl No Name greg@greg.rim.or.jp No Name grossman@cygnus.com No Name gusw@fub46.zedat.fu-berlin.de No Name hfir@math.rochester.edu No Name hnokubi@yyy.or.jp No Name iaint@css.tuu.utas.edu.au No Name invis@visi.com No Name ishisone@sra.co.jp No Name iverson@lionheart.com No Name jpt@magic.net No Name junker@jazz.snu.ac.kr No Name k-sugyou@ccs.mt.nec.co.jp No Name kenji@reseau.toyonaka.osaka.jp No Name kfurge@worldnet.att.net No Name lh@aus.org No Name lhecking@nmrc.ucc.ie No Name mrgreen@mame.mu.oz.au No Name nakagawa@jp.FreeBSD.org No Name ohki@gssm.otsuka.tsukuba.ac.jp No Name owaki@st.rim.or.jp No Name pechter@shell.monmouth.com No Name pete@pelican.pelican.com No Name pritc003@maroon.tc.umn.edu No Name risner@stdio.com No Name roman@rpd.univ.kiev.ua No Name root@ns2.redline.ru No Name root@uglabgw.ug.cs.sunysb.edu No Name stephen.ma@jtec.com.au No Name sumii@is.s.u-tokyo.ac.jp No Name takas-su@is.aist-nara.ac.jp No Name tamone@eig.unige.ch No Name tjevans@raleigh.ibm.com No Name tony-o@iij.ad.jp amurai@spec.co.jp No Name torii@tcd.hitachi.co.jp No Name uenami@imasy.or.jp No Name uhlar@netlab.sk No Name vode@hut.fi No Name wlloyd@mpd.ca No Name wlr@furball.wellsfargo.com No Name wmbfmk@urc.tue.nl No Name yamagata@nwgpc.kek.jp No Name ziggy@ryan.org Nobuhiro Yasutomi nobu@psrc.isac.co.jp Nobuyuki Koganemaru kogane@koganemaru.co.jp Norio Suzuki nosuzuki@e-mail.ne.jp Noritaka Ishizumi graphite@jp.FreeBSD.org Noriyuki Soda soda@sra.co.jp Oh Junseon hollywar@mail.holywar.net Olaf Wagner wagner@luthien.in-berlin.de Oleg Sharoiko os@rsu.ru Oleg V. Volkov rover@lglobus.ru Oliver Breuninger ob@seicom.NET Oliver Friedrichs oliver@secnet.com Oliver Fromme oliver.fromme@heim3.tu-clausthal.de Oliver Laumann net@informatik.uni-bremen.de Oliver Oberdorf oly@world.std.com Olof Johansson offe@ludd.luth.se Osokin Sergey aka oZZ ozz@FreeBSD.org.ru Pace Willisson pace@blitz.com Paco Rosich rosich@modico.eleinf.uv.es Palle Girgensohn girgen@partitur.se Parag Patel parag@cgt.com Pascal Pederiva pascal@zuo.dec.com Pasvorn Boonmark boonmark@juniper.net Patrick Gardella patrick@cre8tivegroup.com Patrick Hausen unknown Paul Antonov apg@demos.su Paul F. Werkowski unknown Paul Fox pgf@foxharp.boston.ma.us Paul Koch koch@thehub.com.au Paul Kranenburg pk@NetBSD.org Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Paul S. LaFollette, Jr. unknown Paul Saab paul@mu.org Paul Sandys myj@nyct.net Paul T. Root proot@horton.iaces.com Paul Vixie paul@vix.com Paulo Menezes paulo@isr.uc.pt Paulo Menezes pm@dee.uc.pt Pedro A M Vazquez vazquez@IQM.Unicamp.BR Pedro Giffuni giffunip@asme.org Pete Bentley pete@demon.net Peter Childs pjchilds@imforei.apana.org.au Peter Cornelius pc@inr.fzk.de Peter Haight peterh@prognet.com Peter Jeremy perer.jeremy@alcatel.com.au Peter M. Chen pmchen@eecs.umich.edu Peter Much peter@citylink.dinoex.sub.org Peter Olsson unknown Peter Philipp pjp@bsd-daemon.net Peter Stubbs PETERS@staidan.qld.edu.au Phil Maker pjm@cs.ntu.edu.au Phil Sutherland philsuth@mycroft.dialix.oz.au Phil Taylor phil@zipmail.co.uk Philip Musumeci philip@rmit.edu.au Pierre Y. Dampure pierre.dampure@k2c.co.uk Pius Fischer pius@ienet.com Pomegranate daver@flag.blackened.net Powerdog Industries kevin.ruddy@powerdog.com R. Kym Horsell Rajesh Vaidheeswarran rv@fore.com Ralf Friedl friedl@informatik.uni-kl.de Randal S. Masutani randal@comtest.com Randall Hopper rhh@ct.picker.com Randall W. Dean rwd@osf.org Randy Bush rbush@bainbridge.verio.net Reinier Bezuidenhout rbezuide@mikom.csir.co.za Remy Card Remy.Card@masi.ibp.fr Ricardas Cepas rch@richard.eu.org Riccardo Veraldi veraldi@cs.unibo.it Rich Wood rich@FreeBSD.org.uk Richard Henderson richard@atheist.tamu.edu Richard Hwang rhwang@bigpanda.com Richard Kiss richard@homemail.com Richard J Kuhns rjk@watson.grauel.com Richard M. Neswold rneswold@drmemory.fnal.gov Richard Seaman, Jr. dick@tar.com Richard Stallman rms@gnu.ai.mit.edu Richard Straka straka@user1.inficad.com Richard Tobin richard@cogsci.ed.ac.uk Richard Wackerbarth rkw@Dataplex.NET Richard Winkel rich@math.missouri.edu Richard Wiwatowski rjwiwat@adelaide.on.net Rick Macklem rick@snowhite.cis.uoguelph.ca Rick Macklin unknown Rob Austein sra@epilogue.com Rob Mallory rmallory@qualcomm.com Rob Snow rsnow@txdirect.net Robert Crowe bob@speakez.com Robert D. Thrush rd@phoenix.aii.com Robert Eckardt roberte@MEP.Ruhr-Uni-Bochum.de Robert Sanders rsanders@mindspring.com Robert Sexton robert@kudra.com Robert Shady rls@id.net Robert Swindells swindellsr@genrad.co.uk Robert Watson robert@cyrus.watson.org Robert Withrow witr@rwwa.com Robert Yoder unknown Robin Carey robin@mailgate.dtc.rankxerox.co.uk Roger Hardiman roger@cs.strath.ac.uk Roland Jesse jesse@cs.uni-magdeburg.de Ron Bickers rbickers@intercenter.net Ron Lenk rlenk@widget.xmission.com Ronald Kuehn kuehn@rz.tu-clausthal.de Rudolf Cejka unknown Ruslan Belkin rus@home2.UA.net Ruslan Ermilov ru@ucb.crimea.ua Ruslan Shevchenko rssh@cam.grad.kiev.ua Russell L. Carter rcarter@pinyon.org Russell Vincent rv@groa.uct.ac.za Ryan Younce ryany@pobox.com SANETO Takanori sanewo@strg.sony.co.jp SAWADA Mizuki miz@qb3.so-net.ne.jp SUGIMURA Takashi sugimura@jp.FreeBSD.org SURANYI Peter suranyip@jks.is.tsukuba.ac.jp Sakai Hiroaki sakai@miya.ee.kagu.sut.ac.jp Sakari Jalovaara sja@tekla.fi Sam Hartman hartmans@mit.edu Samuel Lam skl@ScalableNetwork.com Samuele Zannoli zannoli@cs.unibo.it Sander Vesik sander@haldjas.folklore.ee Sandro Sigala ssigala@globalnet.it Sascha Blank blank@fox.uni-trier.de Sascha Wildner swildner@channelz.GUN.de Satoh Junichi junichi@astec.co.jp Scot Elliott scot@poptart.org Scot W. Hetzel hetzels@westbend.net Scott A. Kenney saken@rmta.ml.org Scott Blachowicz scott.blachowicz@seaslug.org Scott Burris scott@pita.cns.ucla.edu Scott Hazen Mueller scott@zorch.sf-bay.org Scott Michel scottm@cs.ucla.edu Scott Mitchel scott@uk.FreeBSD.org Scott Reynolds scott@clmqt.marquette.mi.us Sebastian Strollo seb@erix.ericsson.se Serge A. Babkin babkin@hq.icb.chel.su Serge V. Vakulenko vak@zebub.msk.su Sergei Chechetkin csl@whale.sunbay.crimea.ua Sergei S. Laskavy laskavy@pc759.cs.msu.su Sergey Gershtein sg@mplik.ru Sergey Kosyakov ks@itp.ac.ru Sergey Potapov sp@alkor.ru Sergey Shkonda serg@bcs.zp.ua Sergey V.Dorokhov svd@kbtelecom.nalnet.ru Sergio Lenzi lenzi@bsi.com.br Shaun Courtney shaun@emma.eng.uct.ac.za Shawn M. Carey smcarey@mailbox.syr.edu Shigio Yamaguchi shigio@wtamacom.com Shinya Esu esu@yk.rim.or.jp Shuichi Tanaka stanaka@bb.mbn.or.jp Shunsuke Akiyama akiyama@jp.FreeBSD.org Simon simon@masi.ibp.fr Simon Burge simonb@telstra.com.au Simon J Gerraty sjg@melb.bull.oz.au Simon Marlow simonm@dcs.gla.ac.uk Simon Shapiro shimon@simon-shapiro.org Sin'ichiro MIYATANI siu@phaseone.co.jp Slaven Rezic eserte@cs.tu-berlin.de Soochon Radee slr@mitre.org Soren Dayton csdayton@midway.uchicago.edu Soren Dossing sauber@netcom.com Soren S. Jorvang soren@dt.dk Stefan Bethke stb@hanse.de Stefan Eggers seggers@semyam.dinoco.de Stefan Moeding s.moeding@ndh.net Stefan Petri unknown Stefan `Sec` Zehl sec@42.org Steinar Haug sthaug@nethelp.no Stephane E. Potvin sepotvin@videotron.ca Stephane Legrand stephane@lituus.fr Stephen Clawson sclawson@marker.cs.utah.edu Stephen F. Combs combssf@salem.ge.com Stephen Farrell stephen@farrell.org Stephen Hocking sysseh@devetir.qld.gov.au Stephen J. Roznowski sjr@home.net Stephen McKay syssgm@devetir.qld.gov.au Stephen Melvin melvin@zytek.com Steve Bauer sbauer@rock.sdsmt.edu Steve Coltrin spcoltri@io.com Steve Deering unknown Steve Gerakines steve2@genesis.tiac.net Steve Gericke steveg@comtrol.com Steve Piette steve@simon.chi.il.US Steve Schwarz schwarz@alpharel.com Steven G. Kargl kargl@troutmask.apl.washington.edu Steven H. Samorodin samorodi@NUXI.com Steven McCanne mccanne@cs.berkeley.edu Steven Plite splite@purdue.edu Steven Wallace unknown Stuart Henderson stuart@internationalschool.co.uk Sue Blake sue@welearn.com.au Sugimoto Sadahiro ixtl@komaba.utmc.or.jp Sugiura Shiro ssugiura@duo.co.jp Sujal Patel smpatel@wam.umd.edu Sune Stjerneby stjerneby@usa.net Suzuki Yoshiaki zensyo@ann.tama.kawasaki.jp Tadashi Kumano kumano@strl.nhk.or.jp Taguchi Takeshi taguchi@tohoku.iij.ad.jp Takahiro Yugawa yugawa@orleans.rim.or.jp Takanori Watanabe takawata@shidahara1.planet.sci.kobe-u.ac.jp Takashi Mega mega@minz.org Takashi Uozu j1594016@ed.kagu.sut.ac.jp Takayuki Ariga a00821@cc.hc.keio.ac.jp Takeru NAIKI naiki@bfd.es.hokudai.ac.jp Takeshi Amaike amaike@iri.co.jp Takeshi MUTOH mutoh@info.nara-k.ac.jp Takeshi Ohashi ohashi@mickey.ai.kyutech.ac.jp Takeshi WATANABE watanabe@crayon.earth.s.kobe-u.ac.jp Takuya SHIOZAKI tshiozak@makino.ise.chuo-u.ac.jp Tatoku Ogaito tacha@tera.fukui-med.ac.jp Tatsumi HOSOKAWA hosokawa@jp.FreeBSD.org Ted Buswell tbuswell@mediaone.net Ted Faber faber@isi.edu Ted Lemon mellon@isc.org Terry Lambert terry@lambert.org Terry Lee terry@uivlsi.csl.uiuc.edu Tetsuya Furukawa tetsuya@secom-sis.co.jp Theo de Raadt deraadt@OpenBSD.org Thomas thomas@mathematik.uni-Bremen.de Thomas D. Dean tomdean@ix.netcom.com Thomas David Rivers rivers@dignus.com Thomas G. McWilliams tgm@netcom.com Thomas Gellekum thomas@ghpc8.ihf.rwth-aachen.de Thomas Graichen graichen@omega.physik.fu-berlin.de Thomas König Thomas.Koenig@ciw.uni-karlsruhe.de Thomas Ptacek unknown Thomas A. Stevens tas@stevens.org Thomas Stromberg tstrombe@rtci.com Thomas Valentino Crimi tcrimi+@andrew.cmu.edu Thomas Wintergerst thomas@lemur.nord.de Þórður Ívarsson totii@est.is Tim Kientzle kientzle@netcom.com Tim Singletary tsingle@sunland.gsfc.nasa.gov Tim Wilkinson tim@sarc.city.ac.uk Timo J. Rinne tri@iki.fi Todd Miller millert@openbsd.org Tom root@majestix.cmr.no Tom tom@sdf.com Tom Gray - DCA dcasba@rain.org Tom Jobbins tom@tom.tj Tom Pusateri pusateri@juniper.net Tom Rush tarush@mindspring.com Tom Samplonius tom@misery.sdf.com Tomohiko Kurahashi kura@melchior.q.t.u-tokyo.ac.jp Tony Kimball alk@Think.COM Tony Li tli@jnx.com Tony Lynn wing@cc.nsysu.edu.tw Tony Maher tonym@angis.org.au Torbjorn Granlund tege@matematik.su.se Toshihiko ARAI toshi@tenchi.ne.jp Toshihiko SHIMOKAWA toshi@tea.forus.or.jp Toshihiro Kanda candy@kgc.co.jp Toshiomi Moriki Toshiomi.Moriki@ma1.seikyou.ne.jp Trefor S. trefor@flevel.co.uk Trevor Blackwell tlb@viaweb.com URATA Shuichiro s-urata@nmit.tmg.nec.co.jp Udo Schweigert ust@cert.siemens.de Ugo Paternostro paterno@dsi.unifi.it Ulf Kieber kieber@sax.de Ulli Linzen ulli@perceval.camelot.de Ustimenko Semen semen@iclub.nsu.ru Uwe Arndt arndt@mailhost.uni-koblenz.de Vadim Chekan vadim@gc.lviv.ua Vadim Kolontsov vadim@tversu.ac.ru Vadim Mikhailov mvp@braz.ru Valentin Nechayev netch@lucky.net Van Jacobson van@ee.lbl.gov Vasily V. Grechishnikov bazilio@ns1.ied-vorstu.ac.ru Vasim Valejev vasim@uddias.diaspro.com Vernon J. Schryver vjs@mica.denver.sgi.com Vic Abell abe@cc.purdue.edu Ville Eerola ve@sci.fi Vincent Poy vince@venus.gaianet.net Vincenzo Capuano VCAPUANO@vmprofs.esoc.esa.de Virgil Champlin champlin@pa.dec.com Vladimir A. Jakovenko vovik@ntu-kpi.kiev.ua Vladimir Kushnir kushn@mail.kar.net Vsevolod Lobko seva@alex-ua.com W. Gerald Hicks wghicks@bellsouth.net W. Richard Stevens rstevens@noao.edu Walt Howard howard@ee.utah.edu Warren Toomey wkt@csadfa.cs.adfa.oz.au Wayne Scott wscott@ichips.intel.com Werner Griessl werner@btp1da.phy.uni-bayreuth.de Wes Santee wsantee@wsantee.oz.net Wietse Venema wietse@wzv.win.tue.nl Wilfredo Sanchez wsanchez@apple.com Wiljo Heinen wiljo@freeside.ki.open.de Wilko Bulte wilko@yedi.iaf.nl Will Andrews andrews@technologist.com Willem Jan Withagen wjw@surf.IAE.nl William Jolitz withheld William Liao william@tale.net Wojtek Pilorz wpilorz@celebris.bdk.lublin.pl Wolfgang Helbig helbig@ba-stuttgart.de Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@FreeBSD.org Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW Yarema yds@ingress.com Yaroslav Terletsky ts@polynet.lviv.ua Yasuhito FUTATSUKI futatuki@fureai.or.jp Yasuhiro Fukama yasuf@big.or.jp Yen-Shuo Su yssu@CCCA.NCTU.edu.tw Yin-Jieh Chen yinjieh@Crazyman.Dorm13.NCTU.edu.tw Ying-Chieh Liao ijliao@csie.NCTU.edu.tw Yixin Jin yjin@rain.cs.ucla.edu Yoichi Asai yatt@msc.biglobe.ne.jp Yoichi Asai yatt@msc.biglobe.ne.jp Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp Yoshihiko OHTA yohta@bres.tsukuba.ac.jp Yoshihisa NAKAGAWA y-nakaga@ccs.mt.nec.co.jp Yoshikazu Goto gotoh@ae.anritsu.co.jp Yoshimasa Ohnishi ohnishi@isc.kyutech.ac.jp Yoshishige Arai ryo2@on.rim.or.jp Yuichi MATSUTAKA matutaka@osa.att.ne.jp Yujiro MIYATA miyata@bioele.nuee.nagoya-u.ac.jp Yukihiro Nakai nacai@iname.com Yusuke Nawano azuki@azkey.org Yuu Yashiki s974123@cc.matsuyama-u.ac.jp Yuval Yarom yval@cs.huji.ac.il Yves Fonk yves@cpcoup5.tn.tudelft.nl Yves Fonk yves@dutncp8.tn.tudelft.nl Zach Heilig zach@gaffaneys.com Zahemszhky Gabor zgabor@code.hu Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw arci vega@sophia.inria.fr der Mouse mouse@Collatz.McRCIM.McGill.EDU frf frf@xocolatl.com Ege Rekk aagero@aage.priv.no 386BSD パッチキットへのパッチ提供者 (名前でアルファベット順): Adam Glass glass@postgres.berkeley.edu Adrian Hall adrian@ibmpcug.co.uk Andrey A. Chernov ache@astral.msk.su Andrew Herbert andrew@werple.apana.org.au Andrew Moore alm@netcom.com Andy Valencia ajv@csd.mot.com jtk@netcom.com Arne Henrik Juul arnej@Lise.Unit.NO Bakul Shah bvs@bitblocks.com Barry Lustig barry@ictv.com Bob Wilcox bob@obiwan.uucp Branko Lankester Brett Lymn blymn@mulga.awadi.com.AU Charles Hannum mycroft@ai.mit.edu Chris G. Demetriou cgd@postgres.berkeley.edu Chris Torek torek@ee.lbl.gov Christoph Robitschko chmr@edvz.tu-graz.ac.at Daniel Poirot poirot@aio.jsc.nasa.gov Dave Burgess burgess@hrd769.brooks.af.mil Dave Rivers rivers@ponds.uucp David Dawes dawes@physics.su.OZ.AU David Greenman dg@Root.COM Eric J. Haug ejh@slustl.slu.edu Felix Gaehtgens felix@escape.vsse.in-berlin.de Frank Maclachlan fpm@crash.cts.com Gary A. Browning gab10@griffcd.amdahl.com Gary Howland gary@hotlava.com Geoff Rehmet csgr@alpha.ru.ac.za Goran Hammarback goran@astro.uu.se Guido van Rooij guido@gvr.org Guy Harris guy@auspex.com Havard Eidnes Havard.Eidnes@runit.sintef.no Herb Peyerl hpeyerl@novatel.cuc.ab.ca Holger Veit Holger.Veit@gmd.de Ishii Masahiro, R. Kym Horsell J.T. Conklin jtc@cygnus.com Jagane D Sundar jagane@netcom.com James Clark jjc@jclark.com James Jegers jimj@miller.cs.uwm.edu James W. Dolter James da Silva jds@cs.umd.edu et al Jay Fenlason hack@datacube.com Jim Wilson wilson@moria.cygnus.com Jörg Lohse lohse@tech7.informatik.uni-hamburg.de Jörg Wunsch joerg_wunsch@uriah.heep.sax.de John Dyson John Woods jfw@eddie.mit.edu Jordan K. Hubbard jkh@whisker.hubbard.ie Julian Elischer julian@dialix.oz.au Julian Stacey jhs@FreeBSD.org Karl Dietz Karl.Dietz@triplan.com Karl Lehenbauer karl@NeoSoft.com karl@one.neosoft.com Keith Bostic bostic@toe.CS.Berkeley.EDU Ken Hughes Kent Talarico kent@shipwreck.tsoft.net Kevin Lahey kml%rokkaku.UUCP@mathcs.emory.edu kml@mosquito.cis.ufl.edu Marc Frajola marc@dev.com Mark Tinguely tinguely@plains.nodak.edu tinguely@hookie.cs.ndsu.NoDak.edu Martin Renters martin@tdc.on.ca Michael Clay mclay@weareb.org Michael Galassi nerd@percival.rain.com Mike Durkin mdurkin@tsoft.sf-bay.org Naoki Hamada nao@tom-yam.or.jp Nate Williams nate@bsd.coe.montana.edu Nick Handel nhandel@NeoSoft.com nick@madhouse.neosoft.com Pace Willisson pace@blitz.com Paul Kranenburg pk@cs.few.eur.nl Paul Mackerras paulus@cs.anu.edu.au Paul Popelka paulp@uts.amdahl.com Peter da Silva peter@NeoSoft.com Phil Sutherland philsuth@mycroft.dialix.oz.au Poul-Henning Kampphk@FreeBSD.org Ralf Friedl friedl@informatik.uni-kl.de Rick Macklem root@snowhite.cis.uoguelph.ca Robert D. Thrush rd@phoenix.aii.com Rod Taylor rod@idiotswitch.org Rodney W. Grimes rgrimes@cdrom.com Sascha Wildner swildner@channelz.GUN.de Scott Burris scott@pita.cns.ucla.edu Scott Reynolds scott@clmqt.marquette.mi.us Sean Eric Fagan sef@kithrup.com Simon J Gerraty sjg@melb.bull.oz.au sjg@zen.void.oz.au Stephen McKay syssgm@devetir.qld.gov.au Terry Lambert terry@icarus.weber.edu Terry Lee terry@uivlsi.csl.uiuc.edu Tor Egge Tor.Egge@idi.ntnu.no Warren Toomey wkt@csadfa.cs.adfa.oz.au Wiljo Heinen wiljo@freeside.ki.open.de William Jolitz withheld Wolfgang Solfrank ws@tools.de Wolfgang Stanglmeier wolf@dentaro.GUN.de Yuval Yarom yval@cs.huji.ac.il diff --git a/ja_JP.eucJP/books/handbook/ports/chapter.sgml b/ja_JP.eucJP/books/handbook/ports/chapter.sgml index 1771213c2e..33d88ab691 100644 --- a/ja_JP.eucJP/books/handbook/ports/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/ports/chapter.sgml @@ -1,5352 +1,5367 @@ アプリケーションのインストール : 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 wheel -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.a /usr/local/lib install -c -o bin -g wheel -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 (X11 のプログラムの場合には /usr/X11R6) 以下に インストールします. 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' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] ftp> cd /pub/FreeBSD/ports/ports/databases ftp> get gnats.tar [gnats スケルトンの tarballs を取得] ftp> 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' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] ftp> cd /pub/FreeBSD/ports/ports ftp> get databases.tar [データベースディレクトリの tarballs を取得] ftp> 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 の仕組みに関する技術的な詳細については, アプリケーションの移殖方法をご覧ください. 苦情をいう. これは電子メールでだけに してください. そのようなメールはまず, その port の保守担当者 に送ってください. make maintainer とタイプ するか, Makefile を読むかして保守担当者 の電子メールアドレスを見つけてください. その port の名前, バージョン(Makefile にある $FreeBSD: の行をコピーしてください), そして エラーに至るまでの出力を忘れずに添えてください. もし満足のいく 返答がもらえない場合には, send-prを使って, バグレポートを送ることもできます. 忘れてしまう. これはほとんどの場合最も簡単な方法です. 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 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; make fetch ports をひとつだけ持ってくる方法は, きっと既にご存知だと思います. Q. マスタ FTP サイトから tarball を持ってくるより, 近くにある FreeBSD の ミラーサイトから持ってきた方が速いはずです. MASTER_SITES に書かれている サイト以外から持ってくるように ports に指示する方法はありませんか? A. もちろんあります. 例えば ftp.FreeBSD.org が MASTER_SITES に書かれている サイトより近いとしたら, 以下のようにしてください. &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 もしくは, 次のようにします. &prompt.root; cd /usr/ports/somewhere/grizzle &prompt.root; make deinstall 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; make extract &prompt.root; cd work/frobble-2.8 [あなたのパッチを当ててください] &prompt.root; cd ../.. &prompt.root; make package Q. この ports の技術は本当に賢いですね. どのようにして動いているのか 私はどうしても知りたいと思います. その秘密は何ですか? A. 秘密は一切ありません. 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/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. : (うんぬん.) 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 のアップグレートのとき, 楽に確認ができるようになります. packing list を手で作るのは時にはとても退屈な作業になります. もし多数のファイルをインストールする port なら, packing list を自動的に作る と時間の節約になるかもしれせん. チェックサムファイルの作成 ただ, make makesum と入力するだけです. bsd.port.mk にルールがあるので, 自動的にfiles/md5が生成されます. Portのテスト そのportが正しく動くことを, package化を含めて確認してください. 以下の重要なポイントを確認してください. PLIST にその port がインストールしないものが含まれていないこと. PLIST にその port がインストールする全てのものが含まれていること. reinstall ターゲットを使うことによって, 何度でもインストールが可能こと. deintall の際に 後片付け をすること. 推奨されるテストの手順 make install make package make deinstall pkg_add 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を作成する場合, 考慮しなくてはいけないことがさらにいくつかあります. この節では, それらのうちもっともありがちなものについて説明します. <command>ldconfig</command> 共有ライブラリをインストールするときには, 共有ライブラリのキャッシュを更新するために 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 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 C++ constructor/destructor の順序変更後の 3.1-STABLE 310002 3.2-STABLE 320001 3/4 の分岐後の 4.0-CURRENT 400000 dynamic linker の変更後の 4.0-CURRENT 400001 C++ constructor/destructor の順序変更後の 4.0-CURRENT 400002 dladdr(3) 機能追加後の 4.0-CURRENT 400003 __deregister_frame_info dynamic linker のバグ修正, EGCS 1.1.2 導入後の 4.0-CURRENT 400004 suser(9) の API 変更, newbus 後の 4.0-CURRENT 400005 cdevsw 登録方法の変更後の 4.0-CURRENT 400006 ソケットレベルの証明書 (credential) のための so_cred への追加後の 4.0-CURRENT 400007 libc_r への poll syscall ラッパー追加後の 4.0-CURRENT 400008 (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 list の生成 まず, あなたの port が PLISTPLIST の ないことを除いて完全なことを確認し, 空の PLIST を作ってください. &prompt.root; touch PLIST 次に, あなたの port をインストールすることができるディレクトリ階層 を新たに作成してください. また, 依存するものをインストールしてください. &prompt.root; mtree -U -f /etc/mtree/BSD.local.dist -d -e -p /var/tmp/port-name &prompt.root; make depends PREFIX=/var/tmp/port-name このディレクトリ構造を新しいファイルに保存してください. &prompt.root; (cd /var/tmp/port-name && find * \! -type d) > OLD-DIRS もしあなたの port が PREFIX にちゃんと従うなら, ここで port をインストールして package list を作ることができます. &prompt.root; make install PREFIX=/var/tmp &prompt.root; (cd /var/tmp/port-name && find * \! -type d) > pkg/PLIST 新しく生成されたディレクトリはいずれも packing list に追加する 必要があります. &prompt.root; (cd /var/tmp/port-name && find * -type d) | comm -13 OLD-DIRS - | sed -e 's#^#@dirrm#' >> pkg/PLIST 最後に, packing list を手で整える必要があります. 完全に自動化されていると言ったのはうそです. マニュアルのファイルは port の Makefile 中の MANn に記述されるべきで, package list にではありません. ユーザ設定ファイルは取り除くか, filename.sample としてインストールされるべきです. port によってインストールされるライブラリは, ldconfig の節で明示したように 記載されるべきです. 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. + + irc + Internet Chat Relay utilities. + + japanese Japanese language support. + + java + Java languge 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-servers + X11 servers. + + 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 で詳細な情報を得ることができます. やっとおしまい! いやはや, 長い文章ですみません. ここまで読んでくださった方に は感謝, 感謝でございます. (_ _) さあ, portの作り方がわかったところで, 世界中のソフトウェア をport化しましょう. FreeBSDプロジェクトに貢献するには, それ がもっとも簡単な方法です! :) diff --git a/ja_JP.eucJP/books/handbook/staff/chapter.sgml b/ja_JP.eucJP/books/handbook/staff/chapter.sgml index 40dc2717ba..f57249054d 100644 --- a/ja_JP.eucJP/books/handbook/staff/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/staff/chapter.sgml @@ -1,917 +1,917 @@ FreeBSDプロジェクトスタッフ 訳: &a.hanai;28 August 1996. FreeBSDプロジェクトは, 以下の人々によって管理運営されています. FreeBSD コアチーム FreeBSD コアチームは, プロジェクトの “運用委員会” を形成し, FreeBSD プロジェクトの全般的な目的や方針の決定を行います. さらに, FreeBSDプロジェクトの 特定の分野の 運用も行っています. (姓でアルファベット順): &a.asami; &a.jmb; &a.ache; &a.bde; &a.gibbs; &a.dg; &a.jkh; &a.phk; &a.rich; &a.gpalmer; &a.jdp; &a.dfr; &a.sos; &a.peter; &a.wollman; &a.joerg; FreeBSD の開発者たち (CVSの)commitする権利を持っていて, FreeBSD のソースツリーについて 作業をおこなっている人々がいます. すべてのコアチームのメンバはま た 開発者でもあります. &a.jmas; &a.ugen; &a.dbaker; &a.jhb; &a.mbarkah; &a.stb; &a.pb; &a.abial; &a.jb; &a.torstenb; &a.dburr; &a.charnier; &a.luoqi; &a.ejc; &a.kjc; &a.gclarkii; &a.archie; &a.chris; &a.alc; &a.cracauer; &a.adam; &a.dillon; &a.mdodd; &a.dufault; &a.uhclem; &a.tegge; &a.deischen; &a.eivind; &a.julian; &a.rse; &a.ru; &a.se; &a.jasone; &a.sef; &a.green; &a.fenner; &a.jfieber; &a.jfitz; &a.scrappy; &a.lars; &a.dirk; &a.shige; &a.billf; &a.tg; &a.gallatin; &a.brandon; &a.gioria; &a.graichen; &a.cg; &a.jgreco; &a.rgrimes; &a.jmg; &a.hanai; &a.mharo; &a.thepish; &a.jhay; &a.roger; &a.sheldonh; &a.helbig; &a.ghelmer; &a.erich; &a.nhibma; &a.flathill; &a.hosokawa; &a.hsu; &a.foxfair; &a.tom; &a.mph; &a.imura; &a.shin; &a.itojun; &a.iwasaki; &a.mjacob; &a.gj; &a.nsj; &a.kato; &a.andreas; &a.motoyuki; &a.jkoshy; &a.kuriyama; &a.grog; &a.jlemon; &a.truckman; &a.lile; &a.kevlo; &a.imp; &a.jmacd; &a.smace; &a.gehenna; &a.mckay; &a.mckusick; &a.ken; &a.hm; &a.tedm; &a.jim; &a.marcel; &a.amurai; &a.markm; &a.max; &a.newton; &a.rnordier; &a.davidn; &a.obrien; &a.danny; &a.ljo; &a.fsmp; &a.smpatel; &a.wpaul; &a.alfred; &a.wes; &a.cpiazza; &a.bp; &a.steve; &a.mpp; &a.jraynard; &a.darrenr; &a.csgr; &a.martin; &a.paul; &a.roberto; &a.chuckr; &a.jesusr; &a.guido; &a.dima; &a.sada; &a.nsayer; &a.wosch; &a.ats; &a.dick; &a.jseger; &a.simokawa; &a.vanilla; &a.msmith; &a.des; &a.brian; &a.mks; &a.stark; &a.karl; &a.sumikawa; &a.nyan; &a.tanimura; &a.taoka; &a.mtaylor; &a.dt; &a.cwt; &a.pst; &a.hoek; &a.nectar; &a.swallace; &a.dwhite; &a.nate; &a.yokota; &a.andy; &a.phantom; &a.jmz; FreeBSD ドキュメンテーションプロジェクト FreeBSD ドキュメンテーションプロジェクトは複数のサービスを提供 しています. それぞれのサービスは, 以下の担当者とその 副担当者によって運用されています. ドキュメンテーションプロジェクト担当 &a.nik; Web 管理責任者 &a.wosch; ハンドブックおよび FAQ 編集担当 &a.faq; ニュースフラッシュ編集担当 - &a.nsj; + - 副担当:&a.john; In the Press 編集担当 &a.jkoshy; FreeBSD Really-Quick NewsLetter編集担当 Chris Coleman chrisc@vmunix.com ギャラリーページ担当 - &a.nsj; + - 副担当&a.cawimm; 商用ベンダーページ担当 &a.nik; WEB 更新担当 - ユーザグループ担当 &a.grog; LinuxDoc から DocBook への移行 &a.nik; 担当者 最高技術責任者 &a.dg; ドキュメンテーションプロジェクト担当 &a.nik; 国際化 &a.ache; ネットワーク &a.wollman; ポストマスタ &a.jmb; リリースコーディネータ &a.jkh; 広報および渉外担当 &a.jkh; セキュリティ担当 &a.imp; CVS ツリー管理者 責任者: &a.peter; 副責任者: &a.jdp; 国際版 (暗号) 担当: &a.markm; ports コレクション担当 &a.asami; XFree86 Project, Inc. との渉外担当 &a.rich; Usenet サポート &a.joerg; GNATS 管理者 &a.phk; と &a.steve; Web 管理者 &a.wosch; diff --git a/ja_JP.eucJP/books/porter-handbook/book.sgml b/ja_JP.eucJP/books/porter-handbook/book.sgml index 1771213c2e..33d88ab691 100644 --- a/ja_JP.eucJP/books/porter-handbook/book.sgml +++ b/ja_JP.eucJP/books/porter-handbook/book.sgml @@ -1,5352 +1,5367 @@ アプリケーションのインストール : 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 wheel -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.a /usr/local/lib install -c -o bin -g wheel -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 (X11 のプログラムの場合には /usr/X11R6) 以下に インストールします. 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' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] ftp> cd /pub/FreeBSD/ports/ports/databases ftp> get gnats.tar [gnats スケルトンの tarballs を取得] ftp> 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' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] ftp> cd /pub/FreeBSD/ports/ports ftp> get databases.tar [データベースディレクトリの tarballs を取得] ftp> 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 の仕組みに関する技術的な詳細については, アプリケーションの移殖方法をご覧ください. 苦情をいう. これは電子メールでだけに してください. そのようなメールはまず, その port の保守担当者 に送ってください. make maintainer とタイプ するか, Makefile を読むかして保守担当者 の電子メールアドレスを見つけてください. その port の名前, バージョン(Makefile にある $FreeBSD: の行をコピーしてください), そして エラーに至るまでの出力を忘れずに添えてください. もし満足のいく 返答がもらえない場合には, send-prを使って, バグレポートを送ることもできます. 忘れてしまう. これはほとんどの場合最も簡単な方法です. 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 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; make fetch ports をひとつだけ持ってくる方法は, きっと既にご存知だと思います. Q. マスタ FTP サイトから tarball を持ってくるより, 近くにある FreeBSD の ミラーサイトから持ってきた方が速いはずです. MASTER_SITES に書かれている サイト以外から持ってくるように ports に指示する方法はありませんか? A. もちろんあります. 例えば ftp.FreeBSD.org が MASTER_SITES に書かれている サイトより近いとしたら, 以下のようにしてください. &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 もしくは, 次のようにします. &prompt.root; cd /usr/ports/somewhere/grizzle &prompt.root; make deinstall 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; make extract &prompt.root; cd work/frobble-2.8 [あなたのパッチを当ててください] &prompt.root; cd ../.. &prompt.root; make package Q. この ports の技術は本当に賢いですね. どのようにして動いているのか 私はどうしても知りたいと思います. その秘密は何ですか? A. 秘密は一切ありません. 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/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. : (うんぬん.) 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 のアップグレートのとき, 楽に確認ができるようになります. packing list を手で作るのは時にはとても退屈な作業になります. もし多数のファイルをインストールする port なら, packing list を自動的に作る と時間の節約になるかもしれせん. チェックサムファイルの作成 ただ, make makesum と入力するだけです. bsd.port.mk にルールがあるので, 自動的にfiles/md5が生成されます. Portのテスト そのportが正しく動くことを, package化を含めて確認してください. 以下の重要なポイントを確認してください. PLIST にその port がインストールしないものが含まれていないこと. PLIST にその port がインストールする全てのものが含まれていること. reinstall ターゲットを使うことによって, 何度でもインストールが可能こと. deintall の際に 後片付け をすること. 推奨されるテストの手順 make install make package make deinstall pkg_add 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を作成する場合, 考慮しなくてはいけないことがさらにいくつかあります. この節では, それらのうちもっともありがちなものについて説明します. <command>ldconfig</command> 共有ライブラリをインストールするときには, 共有ライブラリのキャッシュを更新するために 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 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 C++ constructor/destructor の順序変更後の 3.1-STABLE 310002 3.2-STABLE 320001 3/4 の分岐後の 4.0-CURRENT 400000 dynamic linker の変更後の 4.0-CURRENT 400001 C++ constructor/destructor の順序変更後の 4.0-CURRENT 400002 dladdr(3) 機能追加後の 4.0-CURRENT 400003 __deregister_frame_info dynamic linker のバグ修正, EGCS 1.1.2 導入後の 4.0-CURRENT 400004 suser(9) の API 変更, newbus 後の 4.0-CURRENT 400005 cdevsw 登録方法の変更後の 4.0-CURRENT 400006 ソケットレベルの証明書 (credential) のための so_cred への追加後の 4.0-CURRENT 400007 libc_r への poll syscall ラッパー追加後の 4.0-CURRENT 400008 (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 list の生成 まず, あなたの port が PLISTPLIST の ないことを除いて完全なことを確認し, 空の PLIST を作ってください. &prompt.root; touch PLIST 次に, あなたの port をインストールすることができるディレクトリ階層 を新たに作成してください. また, 依存するものをインストールしてください. &prompt.root; mtree -U -f /etc/mtree/BSD.local.dist -d -e -p /var/tmp/port-name &prompt.root; make depends PREFIX=/var/tmp/port-name このディレクトリ構造を新しいファイルに保存してください. &prompt.root; (cd /var/tmp/port-name && find * \! -type d) > OLD-DIRS もしあなたの port が PREFIX にちゃんと従うなら, ここで port をインストールして package list を作ることができます. &prompt.root; make install PREFIX=/var/tmp &prompt.root; (cd /var/tmp/port-name && find * \! -type d) > pkg/PLIST 新しく生成されたディレクトリはいずれも packing list に追加する 必要があります. &prompt.root; (cd /var/tmp/port-name && find * -type d) | comm -13 OLD-DIRS - | sed -e 's#^#@dirrm#' >> pkg/PLIST 最後に, packing list を手で整える必要があります. 完全に自動化されていると言ったのはうそです. マニュアルのファイルは port の Makefile 中の MANn に記述されるべきで, package list にではありません. ユーザ設定ファイルは取り除くか, filename.sample としてインストールされるべきです. port によってインストールされるライブラリは, ldconfig の節で明示したように 記載されるべきです. 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. + + irc + Internet Chat Relay utilities. + + japanese Japanese language support. + + java + Java languge 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-servers + X11 servers. + + 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 で詳細な情報を得ることができます. やっとおしまい! いやはや, 長い文章ですみません. ここまで読んでくださった方に は感謝, 感謝でございます. (_ _) さあ, portの作り方がわかったところで, 世界中のソフトウェア をport化しましょう. FreeBSDプロジェクトに貢献するには, それ がもっとも簡単な方法です! :) diff --git a/ja_JP.eucJP/books/porters-handbook/book.sgml b/ja_JP.eucJP/books/porters-handbook/book.sgml index 1771213c2e..33d88ab691 100644 --- a/ja_JP.eucJP/books/porters-handbook/book.sgml +++ b/ja_JP.eucJP/books/porters-handbook/book.sgml @@ -1,5352 +1,5367 @@ アプリケーションのインストール : 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 wheel -m 444 /usr/ports/devel/ElectricFence/work/ElectricFence-2.0.5/libefence.a /usr/local/lib install -c -o bin -g wheel -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 (X11 のプログラムの場合には /usr/X11R6) 以下に インストールします. 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' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] ftp> cd /pub/FreeBSD/ports/ports/databases ftp> get gnats.tar [gnats スケルトンの tarballs を取得] ftp> 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' でログインし, パスワードを要求されたら, あなたの電子メール アドレスを入力してください. バイナリモードを (イメージモードと呼ばれることも あります) 使うのをお忘れなく!] ftp> cd /pub/FreeBSD/ports/ports ftp> get databases.tar [データベースディレクトリの tarballs を取得] ftp> 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 の仕組みに関する技術的な詳細については, アプリケーションの移殖方法をご覧ください. 苦情をいう. これは電子メールでだけに してください. そのようなメールはまず, その port の保守担当者 に送ってください. make maintainer とタイプ するか, Makefile を読むかして保守担当者 の電子メールアドレスを見つけてください. その port の名前, バージョン(Makefile にある $FreeBSD: の行をコピーしてください), そして エラーに至るまでの出力を忘れずに添えてください. もし満足のいく 返答がもらえない場合には, send-prを使って, バグレポートを送ることもできます. 忘れてしまう. これはほとんどの場合最も簡単な方法です. 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 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; make fetch ports をひとつだけ持ってくる方法は, きっと既にご存知だと思います. Q. マスタ FTP サイトから tarball を持ってくるより, 近くにある FreeBSD の ミラーサイトから持ってきた方が速いはずです. MASTER_SITES に書かれている サイト以外から持ってくるように ports に指示する方法はありませんか? A. もちろんあります. 例えば ftp.FreeBSD.org が MASTER_SITES に書かれている サイトより近いとしたら, 以下のようにしてください. &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 もしくは, 次のようにします. &prompt.root; cd /usr/ports/somewhere/grizzle &prompt.root; make deinstall 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; make extract &prompt.root; cd work/frobble-2.8 [あなたのパッチを当ててください] &prompt.root; cd ../.. &prompt.root; make package Q. この ports の技術は本当に賢いですね. どのようにして動いているのか 私はどうしても知りたいと思います. その秘密は何ですか? A. 秘密は一切ありません. 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/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. : (うんぬん.) 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 のアップグレートのとき, 楽に確認ができるようになります. packing list を手で作るのは時にはとても退屈な作業になります. もし多数のファイルをインストールする port なら, packing list を自動的に作る と時間の節約になるかもしれせん. チェックサムファイルの作成 ただ, make makesum と入力するだけです. bsd.port.mk にルールがあるので, 自動的にfiles/md5が生成されます. Portのテスト そのportが正しく動くことを, package化を含めて確認してください. 以下の重要なポイントを確認してください. PLIST にその port がインストールしないものが含まれていないこと. PLIST にその port がインストールする全てのものが含まれていること. reinstall ターゲットを使うことによって, 何度でもインストールが可能こと. deintall の際に 後片付け をすること. 推奨されるテストの手順 make install make package make deinstall pkg_add 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を作成する場合, 考慮しなくてはいけないことがさらにいくつかあります. この節では, それらのうちもっともありがちなものについて説明します. <command>ldconfig</command> 共有ライブラリをインストールするときには, 共有ライブラリのキャッシュを更新するために 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 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 C++ constructor/destructor の順序変更後の 3.1-STABLE 310002 3.2-STABLE 320001 3/4 の分岐後の 4.0-CURRENT 400000 dynamic linker の変更後の 4.0-CURRENT 400001 C++ constructor/destructor の順序変更後の 4.0-CURRENT 400002 dladdr(3) 機能追加後の 4.0-CURRENT 400003 __deregister_frame_info dynamic linker のバグ修正, EGCS 1.1.2 導入後の 4.0-CURRENT 400004 suser(9) の API 変更, newbus 後の 4.0-CURRENT 400005 cdevsw 登録方法の変更後の 4.0-CURRENT 400006 ソケットレベルの証明書 (credential) のための so_cred への追加後の 4.0-CURRENT 400007 libc_r への poll syscall ラッパー追加後の 4.0-CURRENT 400008 (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 list の生成 まず, あなたの port が PLISTPLIST の ないことを除いて完全なことを確認し, 空の PLIST を作ってください. &prompt.root; touch PLIST 次に, あなたの port をインストールすることができるディレクトリ階層 を新たに作成してください. また, 依存するものをインストールしてください. &prompt.root; mtree -U -f /etc/mtree/BSD.local.dist -d -e -p /var/tmp/port-name &prompt.root; make depends PREFIX=/var/tmp/port-name このディレクトリ構造を新しいファイルに保存してください. &prompt.root; (cd /var/tmp/port-name && find * \! -type d) > OLD-DIRS もしあなたの port が PREFIX にちゃんと従うなら, ここで port をインストールして package list を作ることができます. &prompt.root; make install PREFIX=/var/tmp &prompt.root; (cd /var/tmp/port-name && find * \! -type d) > pkg/PLIST 新しく生成されたディレクトリはいずれも packing list に追加する 必要があります. &prompt.root; (cd /var/tmp/port-name && find * -type d) | comm -13 OLD-DIRS - | sed -e 's#^#@dirrm#' >> pkg/PLIST 最後に, packing list を手で整える必要があります. 完全に自動化されていると言ったのはうそです. マニュアルのファイルは port の Makefile 中の MANn に記述されるべきで, package list にではありません. ユーザ設定ファイルは取り除くか, filename.sample としてインストールされるべきです. port によってインストールされるライブラリは, ldconfig の節で明示したように 記載されるべきです. 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. + + irc + Internet Chat Relay utilities. + + japanese Japanese language support. + + java + Java languge 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-servers + X11 servers. + + 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 で詳細な情報を得ることができます. やっとおしまい! いやはや, 長い文章ですみません. ここまで読んでくださった方に は感謝, 感謝でございます. (_ _) さあ, portの作り方がわかったところで, 世界中のソフトウェア をport化しましょう. FreeBSDプロジェクトに貢献するには, それ がもっとも簡単な方法です! :)