はじめに
あるパッケージに依存する明示的な指定によりインストールされたパッケージを調べたいでも取り上げたように、この手の調査をする頻度が高くなったこともあり、pkg コマンド拡張してみようかと手を出してみました。
何ができるようになったの？
以下のような問い合わせができるようになります／した（2026/01/17時点では未リリース）。
pkg query -e "%dn = python312" "%o"
従来 -e オプションでは単一属性1（%n など）でしか問い合わせできせんでした。今回、複数属性1（%d など、後述）でも問い合わせできるように拡張した、というものになります。
ただし、拡張を実施するにあたり、その判定方法は、指定された条件が「ある」または「ない」となるため、例えば
-
%dn = python312の場合は依存するパッケージ名にpython312が「ある」 -
%dn != python312の場合は依存するパッケージ名にpython312が「ない」
という風に若干意味合いが異なることになります。前者の認識に異存は無いとは思いますが、後者に対する解釈が若干独特となります。
これは集合に対する評価としては納得できるものと認識しています。
従来通りの単一属性に対する %dn != python312 という評価を、そのままストレートに python312 ではないパッケージに依存する、と解釈してしまうと、大抵なんでも依存してしまうので、調査としては無意味だからです。
より具体的なイメージとして説明すると、%dn != python312 は下記の事例で言う py312-cffi、py312-bcyrpt に一致してしまう、ということになってしまうという意味です。これが期待した機能であるかは言うまでも無いと思います（自分は期待していない）。
$ pkg query "%dn" py312-cryptography
python312
py312-cffi
py312-bcrypt
そのため否定形については「python312 という名前のパッケージ」に依存「しない」という評価をします。そのため、下記のようなパターンを想定した評価になります。
$ pkg query "%dn" python312
readline
mpdecimal
libffi
gettext-runtime
拡張された物は？
下記の属性が問い合わせ対象になります。
-
%d[nov]: 依存パッケージ (Name, Origin, Version) -
%r[nov]: 被依存パッケージ (Name, Origin, Version) -
%C: カテゴリ -
%L: ライセンス -
%B: 要求された共有ライブラリ -
%b: 提供する共有ライブラリ -
%A[tv]: アノーテーション(Tag, Value)
プロトタイピング時は全属性に対応してみて、実際に実行・評価して有意性がありそう…として残った物となります。
拡張されなかった物は？
下記の属性には対応しませんでした。試した限りでは有意性を感じませんでした。この辺りは pkg query "%Fp" 何かパッケージ のようにして実行してみると、その空虚さが分かると思います。
-
%F[psugmftl]: ファイルのリスト -
%S[pugmf]: （サブ）ディレクトリのリスト -
%O[kvdD]: オプションのリスト -
%U: 必要なユーザーのリスト -
%G: 必要なグループのリスト
おそらくは %Fp くらいは価値がありそうな気はしているのですが、その場合 pkg which -q を使用した方がいいかもしれません。まぁ何かうまいユースケースが思いついたら実装するで。
ＡＩプロトタイピング
今回の対応にあたって、Ｇｅｍｉｎｉを使用してプロトタイピングしてみました。やってみて思ったのは思考のギャップを埋めるための対話が重要ということを噛み締めています。
- 要求や実装されたイメージについてはおおよそ目算がついていた
- 実際に指示してみるとズレてる
- プロンプトに書いた内容とイメージとでズレがある
- 素直にイメージしていたと思っていた内容が、無意識の置き換えが行われていて、実は素直でなかった
- 実際に実行してみて無意味だった（全然ストレートでなかった）
その他、生成されるコードの質の問題等ありますが、とにかく実行イメージとプロンプトの間の差分を深掘りしていくのが大変でした。
最終的には pkg-query: support evaluation of complex attributes (lists) というプルリクエストに帰結したのですが、こちら自体は途中経過は無視した内容となります。
正直、即座に反応があり、すぐにでもマージされるとは思っていませんでした。おそらくは次のリリース（バージョン 2.5.2）で利用できるようになります。
生成ＡＩに対する取り扱いについて、ＡＩによって生成されたコードの取り込みは色々と議論がされていると思います。その本質は、生成されたコードをそのままプルリクエストすることの問題であり、生成されたコードを評価、改修、その変更内容についてきちんと説明する分には問題ありません。
今回、プロタイピングについては生成ＡＩのみで行っています。
- プログラムコード改修
- ドキュメント改修
- テスト改修
最終的にプルリクエストに起こすために、以下の対応を行っています。
- 必要な機能の取捨選択
- コードのクリーンナップとトンマナ合わせ（位置合わせ含む）
- テストの実行（
make check） - 一通りコマンドの実行
また以下の対応についてはＡＩを使用しています。
- 修正したコードとドキュメントとの整合性（過不足）の確認
- コミットログのプロトタイプ（ほぼそのまま採用）
前者については無条件で鵜呑みにしていますが、後者についてはあんまり手を入れる所がなく…。
参考文献
- FreeBSD pkg コマンド概要
- FreeBSDでgemini-cliとMCPを試してみる
- pkg-query: support evaluation of complex attributes (lists)