壊れたportsの適当な直し方

portsは、慣れないうちにリポジトリ操作のミス、更新手順の不備、手順前後、勝手な削除、継ぎ足しなどで、徐々に壊れて更新がままなくなることがある。　

一番多いのは、依存関係に矛盾が生じる削除。　pkgdb -F で、似たようなパッケージがあればそれに依存関係を接続しなおす作業が必要になる。

たとえば、あるパッケージが なんちゃらのm4が必要だとしよう。 でもこのm4は、自分の使いたいm4と違って文法エラーが出まくって、みなみ最近…イライラする（笑）・・・　というような時には、間違ってなんちゃらのm4をぶっ飛ばしてしまうかもしれない(訳注：pkg_deinstall なんちゃらのm4) ので、こういう時には、別のm4で接ぎ穂を足されなくてはならない。そうでもしないと単にportsdbを眺めるだけのportsversionすら追跡できない。

autotool辺りはこのバージョン違いが激しく存在し、autoconf-2.13から、autoconf-2.62までのすべてのバージョンを持っているシステムというのも、現時点では存在する可能性がある。
そして、それぞれのバージョンコンパチビリティが低いので、相互補完できず、こいつのwrapperがキチンと入るまで相当に混乱していた。　　3年位前まではそんなこんなで、荒馬のportsを乗りこなすのには、狭いパッケージ選択を余儀なくされていたが、wrapperの出現で管理はしやすくなったといえよう。　だが、未だにwrapperもなく、バージョンコンパチの無いシステムがおおい。

あと、ソースレベルから駄目なものの例として、OpenLDAP、bdbがあるだろうか。　bdbはバージョン4の中ならば、それほど違いが無いのだが、やはりデータベースのフォーマットが異なってるために、入れ替えれば、再構築がつき物である。　もちろん bdbは、単なるdbmに過ぎないから、物理的にむき出しになったファイルを管理する傾向が強く、やはり何かの管理・操作ミスで破壊されやすいことが良く知られているためか、練れたアプリケーション側には修復ツールが必ず付いてきて、データベースを自動的に直すようになっているので、めったに酷い目にはあわないのだが、やっぱりその自動修復には時間がかかり、最近イライラする！　という傾向にある。　また、OpenLDAPに至っては、2.1～2.4までインストール作業を行ってきて、そのたんびに ldifに落として入れなおす。　バイナリはもちろん、扱うデータ形式も変わってしまうのだから注意が必要だ。


こんなパッケージの状態に加えて重要なのが、portsそのものの健全性だったりする。
昔からあるのは、portsカテゴリの移動で、これに追跡が追いつかず、自動的なupgradeが頓挫するのを良く見たもんだ。

一般に、portsは放置していると腐ってしまい依存関係を無視してもコンパイルが出来なくなる。

であるから、まず一番重要なのは



１．新鮮なものを手に入れること。

　　2008年に2006年頃のportsイメージを広げても、その根拠になるhttp/ftpでアクセス可能なソース配布元が消滅している可能性がある。古いのは駄目だ。


２．OSバージョンとの絡み

　　バージョンが違えばportsの対象も異なる。 6.xがメインストリームになってから、4.xで動かないものは多々作られ、8.xがメインストリームになる頃には、6.xで動かない物だらけだろう。 6.xは幸い6.4で終わるので良い（4.x台が 11まで行ったのが異常）が。

３．OSマイナーバージョンで、portsの作法が変更されること。

　おそらく 6.xだけに起きた事ではないだろう。 6.2というここ5年の間ではかなり安定したバージョンのFreeBSDをインストールしたマシンでは、現行の6.4を想定したものが動かなくなりつつある。 インクルードファイルが追加されているので、 6.4に順次移行していく必要がある。


という具合である。　Xやphp 関連の話をすると、portsをキチンと管理しないと、Windowsのソフトウェア管理にも似た酷い状況があって、削除の嵐やら、強制アップデートなどという蛮行をしないと、もはやどうにもならないがこれについては別徒書くことにする。