portupgrade ( pkgtools ) -20091029 でエラー

ports の更新をした。ports-mgmt/portupgrade-devel が更新された。

この -20091029 だが、私の環境では以下のようなエラーが出る。

$ sudo portinstall -v lang/tcl86-thread -l ~/log/20091110.03.tcl86-to-sqlite3.list
--->  Session started at: Tue, 10 Nov 2009 17:51:43 +0900
[Gathering depends for lang/tcl86-thread ..--->  Session ended at: Tue, 10 Nov 2009 17:51:47 +0900 (consumed 00:00:04)
/usr/local/sbin/portinstall:878:in `get_all_depends': private method `scan' called for #<Set: {}> (NoMethodError)
 from /usr/local/sbin/portinstall:871:in `get_all_depends'
 from /usr/local/lib/ruby/1.8/set.rb:195:in `each'
 from /usr/local/lib/ruby/1.8/set.rb:195:in `each_key'
 from /usr/local/lib/ruby/1.8/set.rb:195:in `each'
 from /usr/local/sbin/portinstall:870:in `get_all_depends'
 from /usr/local/sbin/portinstall:887:in `get_notinstalled_depends'
 from /usr/local/sbin/portinstall:773:in `main'
 from /usr/local/sbin/portinstall:751:in `each'
 from /usr/local/sbin/portinstall:751:in `main'
 from /usr/local/lib/ruby/1.8/optparse.rb:1310:in `call'
 from /usr/local/lib/ruby/1.8/optparse.rb:1310:in `parse_in_order'
 from /usr/local/lib/ruby/1.8/optparse.rb:1306:in `catch'
 from /usr/local/lib/ruby/1.8/optparse.rb:1306:in `parse_in_order'
 from /usr/local/lib/ruby/1.8/optparse.rb:1254:in `catch'
 from /usr/local/lib/ruby/1.8/optparse.rb:1254:in `parse_in_order'
 from /usr/local/lib/ruby/1.8/optparse.rb:1248:in `order!'
 from /usr/local/lib/ruby/1.8/optparse.rb:1241:in `order'
 from /usr/local/sbin/portinstall:559:in `main'
 from /usr/local/lib/ruby/1.8/optparse.rb:791:in `initialize'
 from /usr/local/sbin/portinstall:231:in `new'
 from /usr/local/sbin/portinstall:231:in `main'
 from /usr/local/sbin/portinstall:2213

2回ほど、portupgrade-devel を pkg-delete して make clean install から入れ直してみたが症状は変わらない。

ざっくり検索しても、似た症状が見当たらない。一番近いのが Ruby gem から datamapper を使ったときの[DataMapper] private method `scan' error という 昨年9月の記事。リンクを辿ると、DataObjects を新しくしたら?とだけ書いてあって、あとのフォローがない。

しばし考えたが、 ports-mgmt/portupgrade (-devel のついていない、安定版) にしてしまった。

コンパイルの最中に、再現性のない Segmentation fault を起こすような今のマシン環境では最新版のテストをして報告をできる状態でもないだろう、ということだ。

ハードが不安定なのだ、と睨んでいるので、あまり手を入れる気がない。

まじめにやるなら、databases/datamapper とその依存モジュールを下から順番に入れてみるという手もある。しかし scan なんてありふれた名前の関数が同じものだという保証はないわけで…