ports ネタ

ビルドとインストール

distfile を(まだ)持っていない場合、proxy 経由でも入手可能。 ダウンロード・ビルド・インストール・掃除 は、まとめて行える。

# HTTP_PROXY=http://proxy.host.domain:port
# export HTTP_PROXY
# cd /usrt/ports/genre/software_you_want
# make install clean

LAN 内など、近場に distfiles を持っているサーバがあるのであれば、 それを make.conf に指定しておくとよい。

MASTER_SITE_BACKUP="ftp://11.22.33.44/pub/FreeBSD/distfiles/${DIST_SUBDIR}/"
MASTER_SITE_OVERRIDE?=  ${MASTER_SITE_BACKUP}

cvsup

この項の賞味期限は、「2013.02/末 まで」です。

ports tree は 他のソースツリーと同様 Subversion への移行が終り、 svn から cvs へ export した上での CVSup の対応も、2013.02/末 にて終息します。 というわけで、この項の賞味期限は、「2013.02/末 まで」です。

まず、cvsup かもしくは cvsup-bin を ports なりなんなりで入れる。
いずれも net カテゴリにある。 ディスクをケチりたい人は、-bin のほうを入れると良い。

次に、cvsup コマンドのパラメータとなるsupfile を作る。 サンプルは /usr/share/examples/cvsup/ に転がっている。 作ったファイルはどこにおいても構わない。 個人的には /usr/local/etc/ に置くのがいいんじゃないかと思っている。 できた supfile を make.conf に指定する。

SUP_UPDATE=yes
PORTSSUPFILE=/usr/local/etc/supfile-ports

できたネタを使って、ports ツリーの同期を行い、 portupgrade を使うための ports データベースも更新しておく。

# cd /usr/ports/
# make update
# make fetchindex
# portsdb -u

cvsup 先のサーバが直近の mirror ではない場合、 fetchindex するとローカルに持っている ports tree とアンマッチな INDEX-5 が できてしまうことになる。 この場合は手動で INDEX-5 を作りなおせばよい。 遅いマシンではかなり時間がかかるので覚悟する。

# cd /usr/ports
# portsdb -Uu

ports の検索

知っていると意外と便利。

% cd /usr/ports
% make search key=hogehoge

make.conf のサンプル

ports で make をかけるときにコンパイルオプションを与えるには、 毎回 make の引数を打鍵しても別に構わないが、/etc/make.conf に書いておくのが楽。 make.conf のサンプルは以下の場所にある。 ports では コンパイルオプションだけでなく configure オプションも 与えることができるので、面倒くさがらずに書いておくのが吉。

4.x 系 /usr/share/examples/etc/defaults/make.conf  
5.x 系 /usr/share/examples/etc/make.conf  

例:
.if ${.CURDIR} == "/usr/ports/java/eclipse"
WITH_MOZILLA=firefox
.endif

portupgrade

ビルドにとても時間がかかる、とか 多少古くても問題ないぞ、とか 「このバージョンで縛りたい」とか そういうケースでは、portupgrade をついつい実行してしまって 上がっちゃって逆に困ることがある。

こういうケースでは、pkgtools.conf に HOLD 指定をしておけばよい。 このファイルはデフォルトでは /usr/local/etc に置かれている。 こんな具合だ。

  HOLD_PKGS = [
    'bsdpan-*',
    'wmnet-*',
    'windowmaker-*',
  ]

また、本当にそのバージョンを取っておく必要があるなら、 パッケージを作成しておくべきだろう。 pkg_create で、今既に導入されている ports/packages を package にまとめることができる。

パッケージを作成して保存しておく場合、 そのパッケージの前提となっているパッケージも取っておかないと 戻せなくなるので虚しい。この場合、pkg_info で required なものを いちいち調べていってもいいが、いくらなんでも面倒だろうから 依存しているものもいっしょにパッケージ化してしまえ。 だが、それでも依存連鎖の罠が無くなるわけではないので、 ここで嗅覚を働かせておくことは重要だ。

# pkg_create -R -b パッケージの正式名

パッケージの正式名は pkg_info で調べる。 面倒だったら /var/db/pkg を ls しても手を抜いてもよいかもしれない。

# ls -d /var/db/pkg/ja*nvi*
/var/db/pkg/ja-nvi-eucjp-1.79.20040401,1

なお、あるパッケージの依存については、以下の通り調べることができる。 ports のデータベースが壊れているとちゃんとした出力を得られないので、 pkgdb -F して依存関係をクリアにしてから実施するべき。

pkg_info -r pkgname  …そのパッケージが依存しているパッケージの情報
pkg_info -R pkgname  …そのパッケージを必要とするパッケージの情報
[$Revision: 1.8 $ $Date: 2012.09.09 22:40:36 $]
[EOF]