portupgrade の方が portmaster よりも好き - glib20 が自己依存2026年01月04日 14時18分15秒

FreeBSD に pkg が導入されたが、一部の削除されたプログラムを保持していたいので、一部で ports をまだまだ利用中。そんなわけで、動的ライブラリをしっかりと保存しつつ、一つずつ順次ビルド、再インストールを繰り返していかないといけない。ports 更新となると portupgrade か portmaster になる。

portmaster の方が先行者になるのだが、こちらの方が長年使っているので馴染みがあっていい。あれこれと特殊な状況でも使っているので、問題にあっても対処の仕方が分かるのも利点。ただ、問題点は依存関係の構築に時間がかかること。

時折 UPDATING に portmaster での更新のやり方しか書いていなくて、使う事がある。こちらは滅多に使わないので、なかかな慣れないのもある。一番困るのが、動的ライブラリを保持しておくのにオプションを付けないといけないこと。滅多に使わないので忘れる事が多い。あと、依存関係順のビルドの時の動作が信用できない。何度か動かなくなったプログラムがあるので、信用度はいまいち。portupgrade での -rR 等での再構築に出てくるプログラムが少ないので、依存関係が追い切れていない印象がある。利点は、プロセスをバックグラウンドに送って作業をしてくれることと、起動直後の動作が早いこと。

最近 portupgrade -aiを使ったら、CPU 100% になる問題に遭遇した。portupgrad -irR で、よく使うプログラムを元に更新していくと、おかしな ports を発見。glib20 をビルドするのに glib20 がインストールされていないといけないと言う、自らへの循環依存。ports 側では特別な手順で回避しているみたいで、これが portupgrade に混乱を引き起こしているようだった。

コメント

_ Tomoaki AOKI ― 2026年01月19日 22時06分07秒

portupgradeは確か最古のports更新ツールで、それ以前は手作業で依存関係を追いかけて影響を受けるものを更新するなり諦めて新しいReleaseが出たところでゼロベースでインストールし直すかだったと記憶しています。
その後に「古いライブラリを残すのって脆弱性の修正があったとき危ないでしょ」「Rubyに依存するのは嫌!baseにある/bin/shでないと」という面々がportmasterを作ったかと。
そのため旧版ライブラリの保存のポリシーが逆になっていますよね。
ただ、portupgradeは放置されているパッチがBugzillaに大量に残っていて、どれとどれを共存しても安全かの判断に悩み、特にFLAVORにきちんと対応できていないのが痛いです。 一部挙動が違ったり「-o」オプションが無かったりという難はありますが、pkg_replaceがportupgradeの/bin/shでの再実装という方向性になっています。
とはいえpkg_replaceはportscleanを含まないので、「-o」オプションの件と併せてどうあってもportupgradeから完全に卒業することはできません。

glib20の件は、UPDATINGの20250402付エントリのものでは?

コメントをどうぞ

※メールアドレスとURLの入力は必須ではありません。 入力されたメールアドレスは記事に反映されず、ブログの管理者のみが参照できます。

※なお、送られたコメントはブログの管理者が確認するまで公開されません。

名前:
メールアドレス:
URL:
コメント:

トラックバック

このエントリのトラックバックURL: http://uyota.asablo.jp/blog/2026/01/04/9828169/tb

※なお、送られたトラックバックはブログの管理者が確認するまで公開されません。