Conaryは、dpkgあるいはRPMとYumの組み合わせをスリム化した構成となっており、これらのパッケージマネージャで使われるすべてのユーティリティを単一のコマンドに統合して、バージョン管理機能を取り込むことで、近代的なディストリビューションに求められる要件を満たしたものだと言える。
Conaryは、ソース管理システムを兼用するリポジトリと組み合わせることで機能するが、そこには各種のブランチや差分情報を収めた“changeset”と呼ばれるファイル群が設けられており、後者は特定パッケージ中で利用可能なバージョン間の相違点を特定する際に用いられる。現在主流のパッケージシステムではバージョン番号のみによってパッケージ間の識別をしているのに対し、Conaryリポジトリの登録名には独自の識別システムが用いられており、例えば、リポジトリ中のパッケージ格納位置、アップストリームのバージョン番号、ソースのバージョン、バイナリのビルド番号、使用可能なハードウェアアーキテクチャなどの情報を扱えるようになっている。
こうした独自の識別システムを採用したメリットとしては、ファイル間の関係を一目で把握できること、設定やアーキテクチャの異なるビルドを同一のリポジトリにまとめられること、ドキュメントなどのファイル類を共用できることなどが挙げられる。その他、あるプログラムの新バージョンが出現した際に必ずしも古いバージョンを上書きする必要がなく、両バージョンを共存させることも可能で、またパッケージデザインの不備から発生する一般的な依存性問題を回避できる場合もある。
パッケージを作成する際には、こうした独自の構成を厳密に遵守する必要があるが、ここではソースからパッケージへのコンパイル法を指定するいわゆるspecファイルの役割を.recipeファイルが果たすというように、“料理とレシピ”というメタファが使われている。例えば「cook レシピ 」というコマンドで、パッケージがビルドできるかのテストを行い、「cvc cook パッケージ名 」によってパッケージのリポジトリへのインストールを行うといった感じである。
Conaryを用いたソフトウェア管理
リポジトリの構成が厳密に管理されているという特徴は、ローカルシステムにおけるConaryの挙動にも反映されている。例えばConaryの基本設定は、/etcディレクトリ、カレントユーザのhomeディレクトリ、現在作業中のディレクトリという、3つの場所に保存できるようになっているが、上級ユーザであれば、特定パッケージの異なるバージョンや複数のリポジトリを試用する場合などに、これら各ディレクトリの設定情報を個別に使い分けるといった使用法ができるだろう。
パッケージ操作に関するコマンドについても、「conary アクション オプション パッケージ名 」という、共通化された構文で使用できるようになっている。こうしたアクションの大部分はフルネームおよび省略形によるアクセスが可能で、その点はシェル操作用の標準UnixオプションやGNUオプションと同様である。
操作性に優れた汎用ツールとしてのConaryを陰で支えているのは、独自のリポジトリ管理構造だと言っていいだろう。例えば、利用可能なソフトウェアについての情報を検索する「conary query」あるいは「conary q」という基本コマンドは、すべてのパッケージ、単一のパッケージ、特定パッケージの構成ファイル、あるいは当該パッケージの依存関係という情報を、ユーザの指定オプションに応じて“provides”および“requires”というカテゴリに分けた上でレポートさせることもできる。同じくリポジトリ情報を確認するための「conary repquery」というコマンドを用いると、すべてのパッケージとその利用可能なリビジョン、すべてのアーキテクチャで利用可能なパッケージ、あるいは、ローカルシステムが現在利用しているリポジトリブランチ内で利用可能なものといった情報を取得することも可能だ。これらの中でも特に有用なのは「conary update」というコマンドで、操作対象を、指定パッケージの特定バージョン、リポジトリ中の特定パッケージ群、システムにインストールされているすべてのパッケージなどとした上で、これらに対する、インストール、アップグレード、ダウングレードという操作を、ユーザによるオプション指定で使い分けられるようになっている。
更にすべてのアクションには分かりやすいネーミングが施されており、「conary updateall」あるいは「conary rollback」などのアクションが何の処理を行うかは、経験の浅いユーザであってもすぐに理解できるはずである。とは言うものの、たいていの場合これら基本コマンドを実行すると非常に詳細な項目が出力されるので、lessコマンドにパイプして必要な情報のみを表示させるにしても、思い通りの結果を得るには何度か試行錯誤的に実験してみる必要があるだろう。Conaryを使い始めるのに特殊なトレーニングを積んでおく必要はほとんどないが、一部の上級者用機能やその実行結果については、ある程度の時間をかけて学習する必要があるかもしれない。
数あるアクションの中でも特に有用なのは、ローカルパッケージを削除不可能にする「conary pin パッケージ名 」である。この指定の解除は「conary unpin パッケージ名 」で行うことができる。これらのpin系コマンドが役立つケースとしては、あるプログラムの異なる2つのバージョンを同一システム上で併用させたい場合を考えればいいだろう。
pin系コマンドのより具体的な使用例としては、「conary update kernel」コマンド（誤解しようがないネーミングである）を用いた新規カーネルのインストール処理が挙げられる。オンラインドキュメントには、念のためアップデートの実行前にカーネルがpin設定されていることを確認しておくよう注意が喚起されているが、デフォルトの設定では、すべてのカーネルに対してpin設定が施されるようになっている。逆に言えばアップデートの終了後、新しいカーネルでローカルのシステムが起動できることを確認してからunpinコマンドを用いてpin指定を解除しておかないと、古いカーネルをシステムから削除できないのである。
Conaryは基本的にコマンドラインで使用するツールであるが、同プロジェクトからはconary-guiというグラフィカルインタフェースも提供されている。ただし多くのパッケージシステム用インタフェースがそうであるように、conary-guiも簡単なソフトウェアのインストールや削除を行うには便利なのであるが、本来のコマンドラインツールに比べると機能的に見劣りする点があるのは否めない。それでも操作ウィンドウをInstalledとAvailableの2つに分けることができるのは、使っていて非常に便利だ。
Conaryの今後に対する展望
Conaryは構成的にも機能的にも、非常に使いやすくまとめられている。1つ不満を述べるとすれば、それは本システムのみで通用する特殊な用語が多用されている点だろう。本稿を執筆する際にそうした特殊な用語の使用はできるだけ避けてきたのだが、これらの存在がConaryを実際以上に取っつきにくく感じさせている要因となっているはずである。
例えばConaryでは“trove”（情報の集合体、データバンク）という用語が使われているが、これは本当に必要なコンセプトであろうか？ 同プロジェクトのWebサイトにはGlossaryページが用意されており、そこにある「trove」の項を見ると「a collection of files or other troves」（ファイルないし他のtroveの集合体）と簡潔な説明がされているのだが、こうした“他のtroveを内包したtrove”というのは要は“パッケージ”のことではないのだろうか。同じく「component」の項には“trove”の一種だという説明がなされているが、共通の名前を付けられて特定の目的で用いられるファイル群を内包するものということは、パッケージで使われるバイナリファイル、ドキュメント、ライブラリを意味するのではないのだろうか。また“flavor”という用語も同様で、これは主としてハードウェアアーキテクチャのことを指すそうだ（もちろんその他の意味で使われるケースもあるが）。その他にも“changeset”という用語などは、何を意味するのかやその必要性はある程度分からないことはないが、“absolute changeset”と“relative changeset”と“local changeset”という使い分けがされていると、具体的に何が違うのかと言うことになる。この種の特殊な用語の使用を強制されると、ユーザを無視した独善に陥っている感じがしてならない。同プロジェクトのWebサイトにはヘルプページが用意されていて、そこでの説明は簡潔かつ包括的にまとめられているのに、これらの難解な用語の多用によって損なわれているのが非常に残念である。
提供元であるrPathにとってのConaryとは、それ自体を開発することが目的ではなく、同社の本業である仮想アプライアンスを構築するためのサポートツールの1つにしかすぎないのだろう。ConaryはrPath Linuxでも使用されているが、rPath Linuxそのものが主としてカスタムディストリビューションを作成するメインツールの1つとして使われている関係上、Conaryが実用に供されている現場を確認したければ、rPath LinuxおよびrBuilder Online（カスタムディストリビューションのバージョン管理を目的としたrPathのツール）を用いて作られたディストリビューションを見てみるのがベストであるということになる。これらのディストリビューションの中で最も際だったものとしては、最新版のGNOMEを使用することに特化したForesightというディストリビューションが挙げられるだろう。
パッケージシステムとしてのConaryは、競合関係にある.debおよび.rpmたちにかなり距離を開けられてから登場したというハンデを背負っている。rPathがConaryの有用性を認識しているのは間違いないはずだが、コミュニティにとっての大方の捉え方となると、従来型のパッケージシステムを置き換える存在というよりも、ある種のインスピレーションを与える存在だと見なされているように、私には感じられる。Conaryを実際に使用したことのある人間はたいていその優秀性を認めるのに対して、メジャーなディストリビューションの中で既存パッケージシステムとの代替を積極的に進めているものは1つもないのが現状だ。しかしながら、これらのディストリビューションは遅かれ早かれより複雑化していくものであり、GNU/Linuxの商用化が進むほどリリースタイミングの迅速化に対する要求も高くなっていくはずであって、今後の流れとしては、Conary的な機能を独自に再構築するというケースがいくつか出てくるのかもしれない。
Bruce Byfieldは、コンピュータジャーナリストとして活躍しており、NewsForge、Linux.com、IT Manager's Journalに定期的に寄稿している。