[gentoojp-docs 469] Portage のman の追加分

[Mamoru KOMACHI <usata@xxxxxxxxxxxxxxxxxxxxxxx>]

小町です。

Portage の man の追加分を訳したので添付します。どれもそんなに長くあり
ません。「CVS ヘッダ」の部分には原文の CVS ヘッダを入れときました(RCS
で使っているとデフォルトでキーワード展開されてしまうので、$Header: $
は取り除いてあります)。査読をお願いします。今回のも groff のソースのま
ま貼り付けるので、必要があれば groff -Tnippon -mandoc cvs.5 > cvs.5.catman 
みたくして整形してからお読みください。もしかしたらメールにそのままペー
ストしたから ISO-2022-JP になっているかもしれないので(もとは EUC-JP で
す)、うまく groff にかからなかったら EUC-JP に変換してください。

さてこれで一応 manpages について考える暇ができたわけですが、どうしましょ
うね。Portage の man はあとでも足せるので manpages-ja だけでもコミット
しておく、ということもできますが、いかがでしょう。

-- 
Mamoru KOMACHI <usata@xxxxxxxxxxxxxxxxxxxxxxx>
http://www.sodan.ecc.u-tokyo.ac.jp/~usata/

.TH "CVS" "5" "Jun 2003" "Portage 2.0.48" "Portage"
.SH "名前"
cvs \- 一般的な cvs fetch 機能を提供
.SH "説明"
\fBcvs\fR eclass は「live」cvs ebuild を作成するために使うことができる
関数を持っている。「live」cvs ebuild という名前は、emerge の時 cvs
リポジトリからチェックアウトし、そのチェックアウトしたソースコードから
コンパイルするために、そう呼ばれている。
この eclass は普通とても不安定な ebuild を生成する……が、
「live」cvs チェックアウト以上の最先端を使うことはできないだろう :)

.br
この eclass のよくある利用方法としては、まず \fBECVS_SERVER\fR 
と \fBECVS_MODULE\fR を設定して適切な cvs ソースを取得し、
cvs eclass に \fBsrc_unpack\fR を定義させる。
.SH "変数"
.TP
.B "ECVS_CVS_COMMAND" = \fI"cvs -q -f -z4"\fR
cvs リポジトリからモジュールをチェックアウトするために実行するコマンド。
これを変更する必要はない。
.TP
.B "ECVS_UP_OPTS" = \fI"-dP"
update を実行する時に \fBECVS_CVS_COMMAND\fR に渡すオプション。
これを変更する必要はない。
.TP
.B "ECVS_CO_OPTS" = \fI""\fR
checkout を実行する時に \fBECVS_CVS_COMMAND\fR に渡すオプション。
これを変更する必要はない。
.TP
.B "ECVS_TOP_DIR" = \fI"${DISTDIR}/cvs-src"\fR
cvs モジュールが保存され、そしてアクセスされる場所。
これを変更する必要はない。
.TP
.B "ECVS_SERVER" = \fI"offline"\fR
この変数にはソースを checkout するサーバを設定する。
この変数に「offline」を設定すると、cvs eclass はモジュールが
すでに checkout されていて \fBECVS_TOP_DIR\fR にあると仮定する。
ほぼ必ずこの変数は設定しなければならない。
.TP
.B "ECVS_AUTH" = \fI"pserver"\fR
ソースを checkout するために使う認証方法。
現在サポートされている方法は「pserver」だけであることに注意。
これを変更する必要はない。
.TP
.B "ECVS_USER" = \fI"anonymous"\fR
サーバにログインするユーザ名。
.TP
.B "ECVS_PASS" = \fI""\fR
サーバにログインするパスワード。
.TP
.B "ECVS_MODULE" = \fI""\fR
cvs サーバから checkout するモジュール名。
この変数は *必ず* 設定することに注意。
.TP
.B "ECVS_BRANCH" = \fI"HEAD"\fR
ソースを checkout するブランチ。
よくあるターゲットは HEAD (現在「stable」の cvs コード) と
SPLIT (現在「unstable」の cvs コード)。
.SH "関数"
.TP
.B cvs_fetch
この関数は \fBECVS_TOP_DIR\fR をセットアップし、
その他 checkout の前に必要な準備を実行する。
そしてサーバにログインし、最終的に cvs からソースを checkout する。
普通この関数を自分で呼ぶ必要はなく、
\fBcvs_src_unpack\fR に実行させる。
.TP
.B cvs_src_unpack
この関数は cvs ファイルを保存し、checkout のあと置いておく必要の
ある場所を決める。最終的な結果としては、\fB${WORKDIR}\fR の
\fBECVS_MODULE\fR に cvs ソースコードのコピーが保存される。
したがって、大抵 \fB${S}\fR には \fB${WORKDIR}/${ECVS_MODULE}\fR
を設定することになる。
.SH "バグ報告"
バグ報告は https://bugs.gentoo.org/ 経由で行ってください。
.SH "参照"
.BR ebuild (5)
.SH "ファイル"
.BR /usr/portage/eclass/cvs.eclass
.SH "著者"
Mike Frysinger <vapier@xxxxxxxxxx>
.SH "CVS ヘッダ"
原文: /home/cvsroot/gentoo-src/portage/man/cvs.5,v 1.2 2003/07/13 04:25:36 vapier

.TH "DISTUTILS" "5" "Jun 2003" "Portage 2.0.48" "Portage"
.SH "名前"
distutils \- distutils ベースの Python モジュールのインストール補助
.SH "説明"
\fBdistutils\fR eclass は distutils ベースの Python
モジュールのインストールと Gentoo Linux
システムへの組み込みが簡単になるように設計されている。
この eclass では \fBsrc_compile\fR と \fBsrc_install\fR
が定義されている。
追加変数や追加関数を設定しなくても簡単に ebuild が作成できるはずである。
.SH "変数"
.TP
.B PYTHON_SLOT_VERSION = \fI"[0|2.1]"\fR
この変数を使うと python-2.1 に依存関係を持つことができる。
これは通例 -py21- の ebuild でだけ必要である。
そうでなければこの変数は設定すべきではない。
.TP
.B DOCS = \fI"<dodoc に与えるファイル名>"\fR
この変数を使うと \fBsrc_install\fR で
通常ではインストールされない文書を追加でインストールできる。
.SH "関数"
.TP
.B distutils_python_version
この関数は \fBPYVER_MAJOR\fR、\fBPYVER_MINOR\fR そして \fBPYVER\fR
変数に、それぞれ相当する Python バージョンの値を設定する。
.TP
.B distutils_python_tkinter
パッケージが tkinter サポートを要求していれば、
この関数を呼ぶと tkinter サポートが存在しなければ ebuild が失敗する。
そして、ユーザにその ebuild を emerge するためにには tkinter
サポートつきで Python を再コンパイルする必要があることを、
具体的に教えるメッセージが表示される。
.SH "バグ報告"
バグ報告は https://bugs.gentoo.org/ 経由で行なってください。
.SH "参照"
.BR ebuild (5)
.SH "ファイル"
.BR /usr/portage/eclass/distutils.eclass
.SH "著者"
Mike Frysinger <vapier@xxxxxxxxxx>
.SH "CVS ヘッダ"
原文: /home/cvsroot/gentoo-src/portage/man/distutils.5,v 1.1 2003/06/30 00:18:12 vapier

.TH "EUTILS" "5" "Jun 2003" "Portage 2.0.48" "Portage"
.SH "名前"
eutils \- ebuild で使われる追加の(でもよく使われる)いろいろな関数
.SH "説明"
\fBeutils\fR eclass は ebuild.sh にすでに含まれている関数を補助する
関数セットを持っている。考え方としては、全 ebuild
に必須というわけではないが、共通の置き場所を定めるには十分、
というような関数セットを集めている。
.SH "関数"
.TP
.BR "draw_line"
$* と同じ長さの「=」からなる線を引く単純な関数。
`draw_line 1234 5678` を実行すれば、1行に9文字の「=」が得られる。
.TP
.BR "edos2unix " "\fI<ファイル>\fR"
dos2unix、recode、fixdos などなどを手軽に置き換える。
この関数はスクリプトベースのものなので、これを使えば DEPEND
変数からこれらのテキストユーティリティを全部取り除くことができる。
変換するファイル名を与えるだけで、
DOS の CRLF 形式から UNIX の LF 形式に変換することができる。
.TP
.BR "enewgroup " "\fI<グループ名>\fR \fI[gid]\fR"
この関数を使えば、
グループをシステムに追加する正しい方法を知らなくてもよくなる。
追加する \fIグループ名\fR を与えれば、\fBenewgroup\fR 
が残りをやってくれる。そのグループに \fIgid\fR
を指定することもできるし、次に使用できる \fIgid\fR
を自動で確保して割り当てることもできる。
.TP
.BR "enewuser " "\fI<ユーザ名>\fR \fI[uid]\fR \fI[シェル]\fR \fI[ホームディレクトリ]\fR \fI[グループ名]\fR \fI[パラメータ]\fR"
\fBenewgroup\fR と同じで、
ユーザをシステムに追加する正しい方法を知らなくてよくなる。
必須のパラメータは \fIユーザ名\fR だけである。
.br
.BR "デフォルト値"
.br
\fIuid\fR: 次に使用できる値
(デフォルトのふるまいをさせたければ -1 を渡す)
.br
\fIシェル\fR: /bin/false
.br
\fIホームディレクトリ\fR: /dev/null
.br
\fIグループ名\fR: グループなし
.br
\fIパラメータ\fR: \fBuseradd\fR(8) が受け取れるその他のパラメータ全部。
詳しくは man ページ参照
.TP
.BR "epatch"
下記 \fBepatch\fR セクション参照。
.TP
.BR "gen_usr_ldscript"
/lib にあるダイナミックライブラリのためのリンカースクリプトを
/usr/lib に生成する。 これは /lib に .so、そして /usr/lib に .a
があるときのリンク問題を解決するためのものである。
ときどき、gcc や libtool のライブラリ検索パスを変更していると、
ダイナミックリンクのとき /lib にある .so ではなく
/usr/lib にある .a が使われる、ということが起きるのである。
.TP
.BR "get_number_of_jobs"
システムに存在する CPU の数を調べ、得られた結果それに従って
MAKEOPTS に -j を設定する。
.TP
.BR "have_NPTL"
この関数は glibc の NPTL pthread の実装を使っていると真を返す。
.TP
.BR "make_desktop_entry " "\fI<バイナリ>\fR \fI[名前]\fR \fI[アイコン]\fR \fI[種類]\fR \fI[パス]\fR"
GNOME や KDE のメニューにアプリケーションへの小さなショートカットを作る。
実行するバイナリの名前を渡すだけで、残りは全部やってくれる。
メニューに表れる名前を変えたければ、この関数に \fI名前\fR 
のパラメータを渡す。\fIアイコン\fR (デフォルトは \fB${PN}\fR.png)
を指定したければ、/usr/share/pixmaps/ からの相対パス、
もしくはファイルへの絶対パスで画像ファイルの名前を渡す。
アイコンがインストールされるメニューのセクションを
(\fB${CATEGORY}\fR で決定されるデフォルトの場所ではなく)
指定したければ、\fI種類\fR の値を指定する
(取りうる値については
http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html
参照)。最後に、
アプリケーションが特別なディレクトリで起動しなければならないなら、
最後の値をフル \fIパス\fR 名として渡す。
.SH "EPATCH"
.TP
.B "epatch について"
\fBepatch\fR はパッチを簡単にするために設計された。
開発者が \fBpatch\fR(1) コマンドを使ったときにもするであろう、
一般的なチェックを全部やってくれる。
この関数は、いろいろなオフセット値 (-p0 から -p5 まで、\fBepatch\fR 
が呼ばれたときの作業ディレクトリに相対的に)でパッチを当てようと試みる。
パッチを当てるのに(--dry-run でテストすることによって)失敗すれば、
\fBepatch\fR は \fBdie\fR を呼ぶことによって emerge
プロセスを停止させる。
デバッグが簡単なように、パッチを試行した出力がログファイルとして残る。
パッチが成功すれば、
どのパッチが当たったのかを示すきれいに整形されたメッセージが出力される。
\fBepatch\fR は山のようなパッチを当てるのにも、
ほんの1つや2つのパッチを当てるのにも使うことができる。
それに加え、この関数は bzip2、gzip、compress (Z) そして zip
形式で圧縮されたパッチファイルを扱うこともできる。
.TP
.B "使用方法"
.RS
.TP
.B "epatch " "\fI<パッチファイル>\fR"
\fBepatch\fR を使うもっとも簡単で一般的な方法は、
単にパッチファイルへのフルパスを与えるだけである。
.TP
.B "epatch " "\fI<ディレクトリ>\fR"
さらに強力な使い方は、ディレクトリにパッチをたくさん入れ、
そして \fBepatch\fR にそのディレクトリにあるパッチ全部を当てさせる、
というものである。パッチは ??_${\fBARCH\fR}_foo.${\fBEPATCH_SUFFIX\fR}
という形式でなければならない。
こうするときちんとパッチが順序づけられていることが保証され、
\fBARCH\fR 固有のパッチを当てることもできる。

.br
01_all_misc-fix.patch.bz2
.br
   全アーキテクチャ向けに最初人 misc-fix のパッチを当てる
.br
02_sparc_another-fix.patch.bz2
.br
   SPARC のときだけ another-fix パッチを2番目に当てる
.RE
.TP
.B 変数
.RS
.TP
.B "EPATCH_SOURCE" = \fI"${WORKDIR}/patch"\fR
\fBepatch\fR が当てるパッチやパッチのディレクトリの名前。
この変数は \fBepatch\fR をパラメータつきで呼べば自動で設定される。
.TP
.B "EPATCH_SUFFIX" = \fI"patch.bz2"\fR
たくさんのパッチを当てるとき、
この値が全てのパッチの持つ suffix になる。
.TP
.B "EPATCH_OPTS" = \fI""\fR
\fBpatch\fR(1) に渡す追加オプション。
我々も全てお見通しという訳ではないので、制限する理由もない :)
デフォルトはもちろん "" である。
.TP
.B "EPATCH_EXCLUDE" = \fI""\fR
スペースで区切られた (いや、本当のところは \fBIFS\fR で区切られた……)
ファイル名のリストで、
たくさんのパッチを当てるとき飛ばすパッチのファイル名を列挙する。
ファイル名だけ書き、フルパスは使わないこと。
.TP
.B "EPATCH_SINGLE_MSG" = \fI"Applying <パッチ名>"\fR
たった1つのパッチをあてるのだとすれば、
デフォルトのメッセージを表示するのではなく、
なんでも言いたいことを言うよう変更できる。
もしやりたければ、もちろん「わたしを無線装置 51 と呼ばないで」
と表示させることだってできる。
.TP
.B "EPATCH_FORCE" = \fI"[yes|no]"\fR
この変数では \fBEPATCH_SOURCE\fR にあるパッチが
??_${\fBARCH\fR}_foo.${\fBEPATCH_SUFFIX\fR}
というファイル名のルールに則っていなくても全て当てるかどうか決める。
デフォルトでは上記のルールを使ってもらいたい。
.RE
.SH "バグ報告"
バグ報告は https://bugs.gentoo.org/ 経由で行なってください。
.SH "参照"
.BR ebuild (5)
.SH "ファイル"
.BR /usr/portage/eclass/eutils.eclass
.SH "著者"
Mike Frysinger <vapier@xxxxxxxxxx>
.SH "CVS ヘッダ"
原文: /home/cvsroot/gentoo-src/portage/man/eutils.5,v 1.2 2003/07/01 02:11:08 vapier

.TH "FLAG-O-MATIC" "5" "Jun 2003" "Portage 2.0.48" "Portage"
.SH "名前"
flag\-o\-matic \- CFLAGS/CXXFLAGS を簡単かつ安全に操作
.SH "説明"
\fBflag\-o\-matic\fR eclass は CFLAGS/CXXFLAGS
変数を操作するための関数セットである。
.SH "関数"
.TP
.BR "append-flags " "\fI<フラグ>\fR"
現在の CFLAGS/CXXFLAGS に追加のフラグを設定する。
.TP
.BR "filter-flags " "\fI<フラグ>\fR"
CFLAGS/CXXFLAGS から特定のフラグを取り除く。
この関数はフラグに完全マッチする。
.TP
.BR "get-flag " "\fI<フラグ>\fR"
指定されたフラグの値を探し、エコーする。
.TP
.BR "is-flag " "\fI<フラグ>\fR"
フラグが CFLAGS か CXXFLAGS にあれば真を返す。
.TP
.BR "replace-flags " "\fI<旧フラグ>\fR \fI<新フラグ>\fR"
旧フラグを全部新フラグで置き換える。
.TP
.BR "strip-flags"
安全なフラグだと知られていないフラグ以外を全て CFLAGS/CXXFLAGS
から除去する。stable プロフィールのユーザは下記のフラグしか
使えないよう制限されている:
.br
.I "-O -O1 -O2 -mcpu -march -mtune -fstack-protector -pipe -g"
.br
unstable プロフィールのユーザは上のフラグに加えて下記のフラグを
使用することができる:
.br
.I "-Os -O3 -freorder-blocks -fprefetch-loop-arrays"
.SH "バグ報告"
バグ報告は https://bugs.gentoo.org/ 経由で行なってください。
.SH "参照"
.BR ebuild (5),
.BR make.conf (5)
.SH "ファイル"
.BR /usr/portage/eclass/flag\-o\-matic.eclass
.SH "著者"
Mike Frysinger <vapier@xxxxxxxxxx>
.SH "CVS ヘッダ"
原文: /home/cvsroot/gentoo-src/portage/man/flag-o-matic.5,v 1.1 2003/06/25 14:01:16 vapier

.TH "GAMES" "5" "Jun 2003" "Portage 2.0.48" "Portage"
.SH "名前"
games \- ゲームのインストールの標準化
.SH "説明"
\fBgames\fR eclass はシステムにゲームを emerge
する方法を集中コントロールするために使われる。
基本的にはこの eclass で全てのファイルがインストールされる場所と
所有者をコントロールする。自分の game がインストールされる方法を
変えたいなら、ちょっと \fBgames\fI eclass を編集してみよう! :)
.SH "VARIABLES"
.TP
.B "GAMES_PREFIX" = \fI"/usr/games"\fR
ゲームをインストールする場所の prefix。
.TP
.B "GAMES_PREFIX_OPT" = \fI"/opt"\fR
バイナリ配布されているゲームをインストールする場所の prefix。
.TP
.B "GAMES_DATADIR" = \fI"/usr/share/games"\fR
共通データファイルをインストールする場所の prefix。
.TP
.B "GAMES_DATADIR_BASE" = \fI"/usr/share"\fR
上と同じだが、ゲームによってはデータディレクトリのパスに自動で
「/games/」を加えるものがある。
.TP
.B "GAMES_SYSCONFDIR" = \fI"/etc/games"\fR
ゲームが設定ファイルを保存する場所。
.TP
.B "GAMES_STATEDIR" = \fI"/var/games"\fR
実行時ゲームが状態を保存する場所。
これにはハイスコアファイルのようなものも含む。
ゲームが2つ以上ファイルを作成するなら、
全ファイルは \fB${GAMES_STATEDIR}/${PN}\fR
ディレクトリの中に保存されるようにする。
そうでなければ、単に \fB${GAMES_STATEDIR}/\fR
の中ににファイルを1つ作成する。
また、この場所に直接ファイルを作成するなら、
そのファイルにはパッケージ固有の名前を使うよう心がけること。
.TP
.B "GAMES_LIBDIR" = \fI"/usr/games/lib"\fR
ゲームがライブラリを保存する場所。
.TP
.B "GAMES_BINDIR" = \fI"/usr/games/bin"\fR
ゲームが実行バイナリを保存もしくはリンクする場所。
ゲームのバイナリをここに置くことで、$PATH
の膨張を防ぐことができる。
.TP
.B "GAMES_ENVD" = \fI"90games"\fR
env.d に登録するとき使うファイル名。
.TP
.B "GAMES_USER" = \fI"games"\fR
ゲーム関係の全ファイルを所有するユーザ名。
.TP
.B "GAMES_GROUP" = \fI"games"\fR
ゲーム関係の全ファイルを所有するグループ名。
.SH "関数"
.TP
.B "prepgamesdirs" \fI[ディレクトリ]\fR
\fBGAMES_*\fR 変数で指定されたディレクトリと、パラメータとして指定された
追加ディレクトリの中で見つかった全ファイル/ディレクトリの所有権を変更する。
この関数は、全ディレクトリのパーミッションを 750 (u+rwx,g+rx-w,u-rwx)
に変更し、そして全ファイルのパーミッションに g+r,o-rwx
のマスクをかける。
.br
\fB*注意\fR: この関数は *必ず* \fBsrc_install\fR
関数の中で最後に呼ばれるものでなければならない。
もし仮に Portage でこの関数の前に他の関数を呼ぶならこの関数は
\fBsrc_install\fR の最後まで待たせることができるが、
最後に来るまでにこの関数を呼ぶのを忘れないこと!
.TP
.B games_pkg_setup
この関数は自動で \fBGAMES_USER\fR と \fBGAMES_GROUP\fR
をシステムに追加する。
ebuild で \fBpkg_setup\fR を定義しているなら、
\fBpkg_setup\fR 関数の最後でこの関数を呼ぶのを忘れずに。
.TP
.B games_pkg_postinst
この関数は自動で \fBGAMES_ENVD\fR ファイルを生成し、
ゲームを遊ぶためには \fBGAMES_GROUP\fR
に所属する必要があることを簡単に表示する。
ebuild で \fBpkg_postinst\fR を定義しているなら、
\fBpkg_postinst\fR 関数の最後でこの関数を呼ぶのを忘れずに。
.TP
.B egamesconf
\fBeconf\fR 関数と同じだが、ゲーム関係の変数(上記参照)を渡す。
詳しい情報は \fBebuild\fR(5) の \fBeconf\fR を参照。
.TP
.B egamesinstall
\fBeinstall\fR 関数と同じだが、ゲーム関係の変数(上記参照)を渡す。
詳しい情報は \fBebuild\fR(5) の \fBeinstall\fR を参照。
.TP
.B dogamesbin dogamessbin
\fBdobin\fR や\fBdosbin\fR とそれぞれ同じだが、\fBGAMES_PREFIX\fR
にバイナリをインストールする。詳しい情報は \fBebuild\fR(5) を参照。
.TP
.B dogameslib dogameslib.a dogameslib.so
\fBdolib\fR、\fBdolib.a\fR そして \fBdolib.so\fR とそれぞれ同じだが、
\fBGAMES_PREFIX\fR にバイナリをインストールする。
詳しい情報は \fBebuild\fR(5) を参照。
.TP
.B newgamesbin newgamessbin
\fBnewbin\fR や \fBnewsbin\fR とそれぞれ同じだが、
\fBGAMES_PREFIX\fR にバイナリをインストールする。
詳しい情報は \fBebuild\fR(5) を参照。
.TP
.B gamesowners \fI<ファイルまたはディレクトリ>\fR
\fBgamesowners\fR は所有者と所有グループをそれぞれ \fBGAMES_USER\fR
と \fBGAMES_GROUP\fR に変更する。
.TP
.B gamesperms \fI<ファイルまたはディレクトリ>\fR
\fBgamesperms\fR はパーミッションを u+rw,g+r-w,o-rwx
のマスクで変更する。
.SH "バグ報告"
バグ報告は https://bugs.gentoo.org/ 経由で行なってください。
.SH "参照"
.BR ebuild (5)
.SH "ファイル"
.BR /usr/portage/eclass/games.eclass
.SH "著者"
Mike Frysinger <vapier@xxxxxxxxxx>
.SH "CVS ヘッダ"
原文: /home/cvsroot/gentoo-src/portage/man/games.5,v 1.3 2003/06/26 22:21:51 vapier

.TH "GCC" "5" "Jun 2003" "Portage 2.0.48" "Portage"
.SH "名前"
gcc \- gcc についてよく必要とされる情報を得る関数
.SH "説明"
\fBgcc\fR eclass はコンパイルに使われるバージョンの gcc
についての情報を得るために使う関数セットを持っている。
この eclass を使えば開発者はそもそも gcc
の仕様を探す方法を考えるのではなく、gcc
の仕様自体に頭を悩ませればよくなる。
.SH "変数"
.TP
.B WANT_GCC_3 = \fI"[yes|no]"\fR
複数のバージョンの gcc コンパイラ(たとえば gcc-2.95.3 と gcc-3.2.1)
がインストールされていたら、
このクラスでは下記の関数を呼ぶとき gcc-3.x
についての情報がほしいのだと特定することができる。
.SH "関数"
.TP
.B gcc-getCC
C コンパイラバイナリの名前を返す。普通は「gcc」。
.TP
.B gcc-getCXX
C++ コンパイラバイナリの名前を返す。普通は「g++」。
.TP
.B gcc-fullversion
`$CC -dumpversion` でバージョンを返す。
.br
GCC \fI2.95.3\fR は \fI2.95.3\fR を返し、
.br
GCC \fI3.2.1\fR は \fI3.2.1\fR を返す。
.TP
.B gcc-version
バージョンを返すが、<メジャーバージョン>.<マイナーバージョン>だけ返す。
.br
GCC \fI2.95\fR.3 は \fI2.95\fR を返し、
.br
GCC \fI3.2\fR.1 は \fI3.2\fR を返す。
.TP
.B gcc-major-version
メジャーバージョンを返す。
.br
GCC \fI2\fR.95.3 は \fI2\fR を返し、
.br
GCC \fI3\fR.2.1 は \fI3\fR を返す。
.TP
.B gcc-minor-version
マイナーバージョンを返す。
.br
GCC 2.\fI95\fR.3 は \fI95\fR を返し、
.br
GCC 3.\fI2\fR.1 は \fI2\fR を返す。
.TP
.B gcc-micro-version
マイクロバージョンを返す。
.br
GCC 2.95.\fI3\fR は \fI3\fR を返し、
.br
GCC 3.2.\fI1\fR は \fI1\fR を返す。
.TP
.B gcc-libpath
gcc の内部ライブラリのパスを返す。
.TP
.B gcc-libstdcxx-version
libstdc++.so のフルバージョンを返す。
.TP
.B gcc-libstdcxx-major-version
libstdc++.so のメジャーバージョンを返す。
.TP
.B gcc2-flags
gcc-2.95.3 で使える CFLAGS と CXXFLAGS を export する。
.SH "バグ報告"
バグ報告は https://bugs.gentoo.org/ 経由で行なってください。
.SH "参照"
.BR ebuild (5)
.SH "ファイル"
.BR /usr/portage/eclass/gcc.eclass
.SH "著者"
Mike Frysinger <vapier@xxxxxxxxxx>
.SH "CVS ヘッダ"
原文: /home/cvsroot/gentoo-src/portage/man/gcc.5,v 1.1 2003/06/25 19:38:50 vapier

.TH "PERL-MODULE" "5" "Jun 2003" "Portage 2.0.48" "Portage"
.SH "名前"
perl-module \- 一般的な Perl モジュールの ebuilds を操作する
.SH "説明"
\fBperl-module\fR eclass は Portage システム内で Perl
モジュールのコンパイル、テスト、そしてインストールを行なうために使われ、
モジュールを扱うのに
\fBExtUtils::MakeMaker\fR(3pm) か \fBModule::Builder\fR(3pm)
のいずれかの手順をそのまま利用する。
.SH "変数"
.TP
.B "style" = \fI"[builder|makemaker]"\fR
この変数でモジュールをビルドするのに使うデフォルトのパッケージを選択する。
\fIstyle\fR を指定しなければ、デフォルトでは
\fBExtUtils::MakeMaker\fR(3pm) が使用される。
.SH "関数"
.TP
.B perl-module_src_prep
最初の Makefile を作成する。
.TP
.B perl-module_src_compile
まだ呼ばれていなければ \fBperl-module_src_prep\fR を呼び、
最初の make を実行する。
.TP
.B perl-module_src_test
呼ばれれば、そのモジュールといっしょに配布されている全テストを実行する。
.TP
.B perl-module_src_install
`make install` (もしくは \fBModule::Builder\fR(3pm)
がビルドモジュールであればそれに相当するもの) を実行する。
また、pod ファイルのためにビルドパスを消去し、
perllocal.pod を生成する。
.TP
.B perl-module_pkg_setup
\fBperlinfo\fR を呼ぶ。
.TP
.B perl-module_pkg_preinst
\fBperlinfo\fR を呼ぶ。
.TP
.B perl-module_pkg_postinst
\fBupdatepod\fR を呼ぶ。
.TP
.B perl-module_pkg_prerm
\fBupdatepod\fR を呼ぶ。
.TP
.B perl-module_pkg_postrm
\fBupdatepod\fR を呼ぶ。
.TP
.B perlinfo
Gentoo の pods 文書を更新する。
.TP
.B updatepod
ARCH_LIB と SITE_LIB にある perllocal.pods を消す。
.SH "バグ報告"
バグ報告は https://bugs.gentoo.org/ 経由で行なってください。
.SH "参照"
.BR ebuild (5),
.BR ExtUtils::MakeMaker (3pm),
.BR Module::Build (3pm),
.BR perl (1)
.SH "ファイル"
.BR /usr/portage/eclass/perl-module.eclass
.SH "著者"
Michael Cummings <mcummings@xxxxxxxxxx>
.br
Mike Frysinger <vapier@xxxxxxxxxx>
.SH "CVS ヘッダ"
原文: /home/cvsroot/gentoo-src/portage/man/perl-module.eclass.5,v 1.1 2003/07/01 13:28:22 vapier

.TH "RPM" "5" "Jun 2003" "Portage 2.0.48" "Portage"
.SH "名前"
rpm \- RPM を展開するのに便利なクラス
.SH "説明"
\fBrpm\fR eclass は RPM を展開してくれるためにある。
これを使えば開発者は RPM からソースアーカイブを展開するために、
それぞれ独自のコツを使わなくて済む。この eclass では
\fBsrc_unpack\fR 関数が定義されており、展開を全部面倒見てくれる。
unpack 関数は \fBrpmoffset\fR か \fBrpm2cpio\fR のいずれかを用い、
RPM を展開する。システムにどちらも存在する場合、\fBrpm2cpio\fR
が使用される。
.SH "変数"
.TP
.B USE_RPMOFFSET_ONLY = \fI"[0|1]"\fR
\fBrpm2cpio\fR が見つかったとしても RPM 展開に \fBrpmoffset\fR
を強制的に使わせたい場合、この変数を1に設定する。
.SH "関数"
.TP
.B rpm_unpack \fI"<展開するファイル>"\fR
\fBunpack\fR が他のアーカイブを展開するのと同じように RPM
ファイルを展開する。RPM ファイルの中身は
\fB${WORKDIR}\fR に展開される。
.TP
.B rpm_src_unpack
この関数は \fBsrc_unpack\fR を置き換え、\fB${A}\fR
を通して全ファイルを展開する。そのファイルが RPM
であれば \fBrpm_unpack\fR が呼ばれ、RPM
でなければデフォルトの \fBunpack\fR 関数が使用される。
.SH "バグ報告"
バグ報告は https://bugs.gentoo.org/ 経由で行なってください。
.SH "参照"
.BR ebuild (5)
.SH "ファイル"
.BR /usr/portage/eclass/rpm.eclass
.SH "著者"
Mike Frysinger <vapier@xxxxxxxxxx>
.SH "CVS ヘッダ"
原文: /home/cvsroot/gentoo-src/portage/man/rpm.5,v 1.1 2003/06/30 00:01:10 vapier

.TH "STARDICT" "5" "Jun 2003" "Portage 2.0.48" "Portage"
.SH "名前"
startdict \- stardict 辞書のインストールに便利なクラス
.SH "説明"
\fBstartdict\fR eclass には stardictionary のための ebuild
を手軽に作るための適切な変数と関数が含まれている。
この eclass では \fBsrc_compile\fR と \fBsrc_install\fR
が定義されている。やらなければならないのは、
このクラスを inherit する前に
\fBDICT_SUFFIX\fR、\fBDICT_P\fR、\fBFROM_LANG\fR 
と \fBTO_LANG\fR 変数を設定することだけである。
.SH "変数"
.TP
.B FROM_LANG = \fI"翻訳元の言語"\fR
その辞書が翻訳しようとしている元の言語は?
英独辞書を持っているのであれば、
この変数は「English」に設定される。
.TP
.B TO_LANG = \fI"翻訳先の言語"\fR
その辞書が翻訳しようとしている先の言語は?
英独辞書を持っているのであれば、 
この変数は「German」に設定される。
.TP
.B DICT_PREFIX = \fI"「dictd_www.mova.org_」のような SRC_URI prefix"\fR
「dictd_www.mova.org_」のような SRC_URI prefix。
.TP
.B DICT_SUFFIX = \fI"prefix に続く SRC_URI"\fR
prefix に続く SRC_URI。
.SH "バグ報告"
バグ報告は https://bugs.gentoo.org/ 経由で行なってください。
.SH "参照"
.BR ebuild (5)
.SH "ファイル"
.BR /usr/portage/eclass/stardict.eclass
.SH "著者"
Mike Frysinger <vapier@xxxxxxxxxx>
.SH "CVS ヘッダ"
原文: /home/cvsroot/gentoo-src/portage/man/stardict.5,v 1.1 2003/06/30 00:09:54 vapier

.TH "VIM" "5" "Jun 2003" "Portage 2.0.48" "Portage"
.SH "名前"
vim \- vim-core、vim と gvim のための共通ビルドルーチン
.SH "説明"
\fBvim\fR eclass は \fBvim-core\fR、\fBvim\fR と \fBgvim\fR
をビルドするのに使われる関数セットを持っている。
vim-core ebuild は xxd と vimtutor バイナリに加え、
/usr/share/vim、/usr/share/doc と /etc/vim
にインストールされる共通ファイルである。
vim ebuild は端末ベースのバージョンの vim である。
gvim ebuild はグラフィカルなバージョンの vim である。
これら3つの ebuild は同じソース、同じパッチ、
そしてほとんど同じ configure オプションからからビルドされる。
.P
\fBvim.eclass\fR を使った ebuild の中で定義する関数がないのは、
vim.eclass が展開、コンパイルそしてインストールまで全部やるからである。
.SH "変数"
.TP
.B VIM_VERSION = \fI"バージョン文字列"\fR
この変数は重要である。というのは、その ebuild バージョン
(たとえば 6.2_pre5) が vim のバージョン (たとえば 6.2e)
に相当するのにもかかわらず、ebuild
の作者がこの変数を設定しなければ ebuild は vim のバージョン (6.2e)
を知る方法がないからである。
歴史的には vim.eclass 内で ebuild のバージョンから vim
のバージョンを計算する方法があったのだが、
そうすると ebuild の作者は毎回 ebuild
が正しくバージョンづけられているのか確認しなければならなかった。
この問題を回避するために ebuild 自体の中で \fBVIM_VERSION\fR 
を単に指定することで、バージョンの確認が簡単になった。
.TP
.B VIM_GENTOO_PATCHES = \fI"ファイル名"\fR
vim に当てる Gentoo のパッチのファイル名。 vim の新バージョンに対して
Gentoo のパッチを更新する必要は必ずしもないので、
この変数は ebuild や vim のバージョンと、
パッチ tarball のバージョンを分離する。
パッチディレクトリのレイアウトについては、たとえば
\fBvim-6.2.011-gentoo-patches.tar.bz2\fR
を見るとよい。
.TP
.B VIM_ORG_PATCHES = \fI"ファイル名"\fR
vim に当てるパッチのファイル名。
これは \fBftp://ftp.vim.org/pub/vim/patches/\fR から取得した
パッチの tarball であり、現在のバージョンの vim に当てるものである。
vim.org のパッチ tarball の例としては、
たとえば \fBvim-6.2.011-patches.tar.bz2\fR を参照。
.SH "バグ報告"
バグ報告は https://bugs.gentoo.org/ 経由で行なってください。
.SH "参照"
.BR ebuild (5),
.BR vim (1)
.SH "ファイル"
.BR /usr/portage/eclass/vim.eclass
.SH "著者"
Aron Griffis <agriffis@xxxxxxxxxx>
.br
Ryan Phillips <rphillips@xxxxxxxxxx>
.br
Seemant Kulleen <seemant@xxxxxxxxxx>
.SH "CVS ヘッダ"
原文: /home/cvsroot/gentoo-src/portage/man/vim.5,v 1.1 2003/06/29 22:32:25 agriffis