aqua Registryはupstream releaseの不統一を正規化する
GitHub Releases等に置かれるCLI toolのartifactには共通したpackage formatがない。release tag、asset name、archive format、OS/architecture表記、実行ファイル名はprojectごとに異なり、同じprojectでもversion途中で変わることがある。
aquaはupstream releaseを正規化するパッケージマネージャーと捉えられる のaqua Registryは、この不統一を吸収する層として見ると理解しやすい。
典型的には、registry entryが次のような知識を持つ。
asset: release asset名のtemplatereplacements:amd64 -> x86_64、darwin -> Darwin等の名称変換format/format_overrides: tar.gz、zip、raw binary等の違いfiles: archive内のどのfileをcommandとして公開するかsupported_envs: 対応OS/architectureversion_prefix/version_filter: project固有のtag namingversion_overrides: version境界で変わったasset名やlayoutの例外
例えば、あるtoolが古いversionではfoo-v1.2.3-linux-amd64.tar.gz、新しいversionではfoo_1.2.3_Linux_x86_64.zipを公開していても、利用者側のaqua.yamlは同じpackage name/version指定のまま扱える。upstream側の歴史的な命名規則をregistryが吸収するからである。
これはpackage managerがbinaryをbuildしなくても提供できる大きな価値である。単純な「GitHub Release downloader」と違い、registryが release naming schemaの互換層 になる。
一方、この方式にはmaintenance costがある。upstreamがasset namingを変更したり、特定platformの配布を後から追加したりするとregistry entryも更新する必要がある。aquaのversion_overridesが存在するのは、この種のrelease historyをdeclarative metadataとして保持するためでもある。
miseのaqua backend documentationでも、registryのsupported_envsに後から追加されたplatformが反映されていないケースや、version prefix表現の修正が必要なケースを挙げている。つまりregistryは一度生成して終わりのcatalogではなく、upstream releaseと同期し続けるcompatibility databaseでもある。
この構造ではregistry metadata自体が重要なsupply-chain componentになる。誤ったasset templateはinstall failureを起こすだけだが、悪意あるregistryが別URLや別artifactを選べる設計ならsecurity問題になる。このtrust boundaryは package registry metadata自体がsupply-chain trust boundaryになる に分ける。
また命名規則を柔軟に吸収するために任意scriptを実行できるようにするか、declarative templateに制限するかも設計上の分岐になる。aquaは基本的にdownload + unarchiveへinstall processを制限しており、このtrade-offは installer scriptを許すほどpackage managerのtrust surfaceは広がる に繋がる。
upstream binary型package managerを評価する際は、登録package数だけでなく、release naming変更への追随方法、versionごとの例外表現、platform判定、registry更新のreview process を見る必要がある。