1月24日、デフォルトの perl が ver. up
$ ls /var/db/pkg | grep bsdpan- | sed -e 's/bsdpan-//;s,-[0-9.]*$,,;s/-/::/g;' | uniq > /tmp/now.list $ sudo pkg_deinstall -f bsdpan-\* ( perl の本体と、数少ない p5-* を update してから ) $ sudo cpanp -i `cat /tmp/now.list`
基本、cpan 系コマンドでたいがいのモジュールを置き換えているから、こんな具合になる。
2月18日に csup したら
/usr/ports/UPDATING をみたら、21日づけで 8.2-RELEASEタグをつけたよとフライング気味に書いてあった。
2月25日夜に ports を csup したら
数が多いので、処理が面倒になって portupgrade -a
をかけたら、あちこちに不具合がでて参った。
portupgrade コマンド群のなかに含まれる portversion コマンドは /usr/ports/INDEX-versionNo を参照する。このファイルは、ワンセットな更新が終わってから最後にひとまとめに更新がかかる。こっちを更新の基準情報にしないといけないわけだ。
portupgrade -a
では、それぞれの ports ディレクトリの Makefile を参照してシステムにインストールされたものと比較するらしい。よって、更新がアトミック (= ワンセットな更新をワンセット ) に扱えない。て、ことのようだ。
以降、気をつける。
3月12日。デフォルトの Python が ver.up
$ sudo portupgrade -o lang/python27 lang/python26 $ sudo portupgrade -Of py26-\*
で殆どが済む はずだった。
python27 を make するときの dialog で、GNU pthread を使用
を選んだら、ハマる、ハマる。
FreeBSD の精妙に構成された Makefile 群の、評価順序を調べるのがおもしろいとしばらく GNU pthread を使ったまま py26-* を更新できるかチャレンジした。
一応の結論としては、ports の make のときだけ有功になるように、たとえば /usr/local/etc/pkgtools.conf
に以下の設定を追加
MAKE_ARGS = { '*/py-*' => [ 'WITH_PTH=true' ] }
/etc/make.conf
の中にも 条件分岐が使えて
.if defined(WITH_PTH) LIB_DEPENDS+= pth:${PORTSDIR}/devel/pth _PTH_CPPFLAGS= "-I${LOCALBASE}/include/pth" _PTH_LDFLAGS= "-L${LOCALBASE}/lib/pth" CONFIGURE_ENV+= CPPFLAGS="${_PTH_CPPFLAGS} ${CPPFLAGS}" CONFIGURE_ENV+= LDFLAGS="${_PTH_LDFLAGS} ${LDFLAGS}" CFLAGS+= "${_PTH_CPPFLAGS} ${_PTH_LDFLAGS}" .endif
と追加、とすれば。これが最後に読み込まれて、他のオプションも活かしたうえで有功になるというのが結論。
しかしながら。私の場合だと devel/py-sip
なんて、けっこう基本のライブラリで、configure に与えるオプションを決め打ちした行儀の悪い Makefile なのに気づいて断念。
Python はよく知らないが、このファイルは直せるよ。今回だけなら。パッチも出せるよ。
でも、このあと継続して GNU pthread が使えるように py-* をメンテナンスするほどには、python のことをよく知らないもの。
一晩かけて Makefile のお勉強はしたけれど、もしも報告 (send-pr ) するならば lang/python における WITH_PTH は旧い (obsolute)
といった内容にするべきかな、と。
……おっと、Mercurial は、hg コマンドの shell bang 行に python26 と書いてあったので 27 に書き換えた。
追記 : 上記の記事を書いた3時間後、こんな処理で洗い出して対処 (portupgrade -fO ) してみた。
$ grep -l python2\.6/site-packages /var/db/pkg/*/+CONTE*
0 コメント:
コメントを投稿