NetBSDのパッケージ管理システム
NetBSDのパッケージ管理システム
NetBSDのパッケージ管理システム
NetBSDのパッケージ管理システムには、pkg_*、pkgin、pkgsrcがあります。
というより、第4章 pkgsrcを使うからするとNetBSD標準のパッケージ管理システムpkgsrcには、pkgsrcとpkg_*があり、後にpkginも加わったという方が、より正確でしょうか。
もっと言えば、pkg_add、pkg_delete、pkg_info、pkg_create、pkg_adminから成るpkg_installパッケージと後に追加された接頭辞pkg_やpkgが付くコマンドやスクリプト群の便宜的な総称がNetBSDで言うところのpkg_*と言えるでしょう。
「pkgsrcは、FreeBSDのPorts Collectionを参考に作られたソースコードベースのパッケージ管理システム」と言われることが多く、これはこれでその通りのようですが、それなら、pkg_*は？と言うことで調べてみると情報が少ない・・・というより、調べた限りでは、まさに！という情報は皆無でした。。。が、
NetBSDのImplementing Wildcards for the NetBSD Packages Systemの5) Other changes in the NetBSD Packages Systemに"Since NetBSD picked up the pkg_* from FreeBSD in mid-1997,"というフレーズを見つけました。
一方、FreeBSD 10.0-stable Man Pages PKG(7)の末尾にあるHISTORYによれば、「pkg_add(1), pkg_info(1) and pkg_create(1)といったツール一式であるpkg_installを置き換え、。。。」とあります。
また、少なくともFreeBSD 2.0.5-RELEASE Man Pages pkg_delete(8)からFreeBSD 4.2-RELEASE and Ports Man Pages PKG_DELETE(1)までは、末尾のAUTHORSには、このように書かれていることから、FreeBSDプロジェクトで仕掛り中だったpkg_deleteが、NetBSDプロジェクトで洗練され、これをFreeBSDでも採用したと受け止めてよいのでしょう。
更にFreeBSDのThird-party software management under BSDというPDFを読み、NetBSDから分離・独立したOpenBSDの15.2 - Package Managementを見ると「"pkg*ツールとして参照されることもある"pkg_add/pkg_delete/pkg_info/pkg_createがある」旨、記載があるのでNetBSDにあるpkg_adminや他のpkg_*/pkg*が接頭辞に付くコマンドやスクリプトは、NetBSDのオリジナルと考えてよいのでしょう。
というわけでPortsを参考にしたpkgsrcだけでなく、pkg_*もFreeBSDがpkg_installを開発中の初期の頃にNetBSDが参考にし、pkg_deleteに磨きをかけ、(実装した後、OpenBSDが分離、)更にNetBSD内で独自に拡張されていったと考えてよさそうです。
のちにNetBSDで独自に開発されたものの中には、インストール済みパッケージの自動アップデートなどもできるバイナリベースのパッケージ管理システムpkginもあります。
pkgsrc、pkg_*/pkg*、pkginは何れも汎用として公開されており、Linux/PC-UNIX/*BSDなどプラットフォームを選ばず、利用可能です。
ちなみにNetBSDで言うところのpkg_install(当初、zoularisと呼んでいた？Solaris向けだけ？)は、NetBSD以外のプラットフォームにpkg_add、pkg_delete、pkg_info、pkg_create、pkg_adminを導入するためのパッケージであり、これには、audit-packagesとdownload-vulnerability-listの互換ラッパーも含まれるとされています。
pkg_*/pkg*
pkg_*/pkg*は、pkg_add、pkg_delete、pkg_info、pkg_create、pkg_adminと更に接頭辞にpkg_*/pkg*と付くコマンドやスクリプトからなるパッケージ管理ツール群を指す便宜的な総称です。
pkg_addは、インストール、[-u]/[-uu]/[-U]オプション付きでアップデート、pkg_deleteは、パッケージの削除、依存関係を含める場合には、[-r]/[-R]オプション付き、pkg_infoは、パッケージ情報の表示、pkg_adminはパッケージ管理用コマンドです。
pkg_addは、リポジトリパス付きでパッケージを指定することもできますが、予め、[~/.profile]などのログインシェル起動時に読み込まれる構成ファイルで環境変数PKG_PATHにリポジトリを設定して構成ファイルをシェルに読み込ませておけば、パッケージの指定だけでインストールやアップデートすることができます。
ただし、ウィンドウマネージャやデスクトップ環境上の仮想ターミナルにおいて[~/.profile]の読み込み([. ~/.profile])には、注意が必要です。
この時、後述のようにログイン後、すぐにウィンドウマネージャやデスクトップ環境を起動する目的で[~/.profile]に[xinit]や[startx]が、そして[~/.xinitrc]や[~/.xsession]に使用するウィンドウマネージャやデスクトップ環境が記述され、有効になっていると二重にこれらを起動しようとしてエラーとなるからです。
よって、こうした状況では、[~/.profile]内の[xinit]や[startx]を一時的にコメントアウトしておくなり、ウィンドウマネージャやデスクトップ環境を終了させてログインシェルから行なうなりする必要がありますが、これは、現実的とは言えないでしょう。
[pkg_add]は、[sudo]を使って一般ユーザーアカウントから実行することも可能ですし、([su -]ではなく)[su]で環境を引き継ぎつつ、rootアカウント権限を行使することもできますが、こうした場合、一般ユーザーアカウントの[~/.profile]に[PKG_PATH]をセットする必要があるので上記のような状況になる可能性があります。
[pkg_add]を使用する前提で、これを回避する為にには、rootアカウントではウィンドウマネージャやデスクトップ環境を使用しない前提で[/root]の[.profile]に[PKG_PATH]をセットし、[pkg_add]する際は、[su -]すると決めておく必要があるでしょう。
他の選択肢として、後述の[pkgin install]([pkgin in])を使用する方法もあり、通常は、こちらを使うのが無難でしょう。
尚、pkg_delete、pkg_info、pkg_adminについては、pkgsrc(pkg_*/pkg*/pkgin/pkgsrc)でインストールされたもの全てで利用可能です。
バイナリパッケージだけを基にして個々にアップデートするには[-u]/[-U]/[-uu]オプション付きでpkg_addを実行します。
これらオプションの違いですが、man pkg_addを何とか読み解いたり、やってみたりした結果
- [-u]は、インストール済みパッケージがリポジトリにあるバイナリパッケージよりも新しい場合にのみ、新しいバージョンのパッケージ及び指定した当該パッケージと依存関係にあるパッケージが古すぎる(依存関係として機能するか否かをチェック後、チェックに失敗した)場合にのみアップデートするが、バージョンが同一の場合には処理を停止
- [-U]が、[-u]と異なる点は、バージョンが同じであってもアップデート
(仮にインストール済みパッケージの方が新しい場合の挙動は未確認。wipやpkgsrcからmakeした場合に該当するのか含め、こうした状況があり得るのかどうかも未確認。)
ただし、[-uu]については、man pkg_addには一切説明がなく、説明としては、how to upgrade packages/pkg_add -uuにある程度、他方、バグ報告としてpkg/37680: pkg_add -uu deinstalls a package before checking whether the new version can be installedがあり、これだけを見ると未解決のままになっている模様。
よって前者のリンク先の説明が拠り所となりますが、そこの説明では、以下のようになっており、man pkg_addの各項と特に[TECHNICAL DETAILS]を参照すると少しニュアンスが違って見え、"Basically:..."の一文は、若干ニュアンスが違う気がするのですが気のせいでしょうか？
つまり、先の[-u]に書いた通り、manの説明には、次の一文があり、
これからすると、pkg_add -uにおける『基本』の1つとしては「指定したパッケージと依存関係にあるパッケージの内、依存関係としてはバージョンが古すぎて機能しないと判定されたものに関しては、依存パッケージもアップデートされる」と読み取れるかと。(書かれた・書き直された？時期が前後している可能性もあるのでどっちがどっちかわかりませんが、リンク先の説明には、マニュアルpkg_add参照とあるのでmanの解釈優先と判断しました。)
勘案すると[-uu]の現状はリンク先の概要と同様、次のように若干曖昧に説明せざるを得ないのではないかと。。。
- [-uu]は、指定したパッケージと依存関係にあるパッケージを含めて一連のパッケージをアップデート
バグ報告の表題にあるように「新しいバージョンがインストール可能か否かチェック。。」なのか「依存関係にある新しいバージョンのパッケージが機能するか否か」なのかは別として、pkg_add -uuにおいては、そうしたチェックについて直接的にしろ、間接的にしろ、言及されていないようですが、これをチェックしないと仮にアップデートが完了しても機能しないパッケージが出てくる可能性があるのでチェックしていると考えるのが妥当でしょう。
ただ、何れにしても、先のバグ報告では、その際、pkg_add -uuで指定したパッケージ自体がアップデートされないどころか、削除されてしまっています。
そこまでの過程が保持されているなら[pkg_add: Please resolve this conflict!]とあるようにこれを解決した後、再実行することで事なきを得ることができますが、リンク先のバグ報告のエラーメッセージからして、そもそもバイナリのリポジトリにパッケージがなかったとのことなので途中経過を保持しているか否か以前にパッケージ管理上の別の課題と絡んでくることかと。
それは、公式リポジトリに保持しておくべきバイナリパッケージ及びバージョンと、代替を含め、それが常に存在する(入れ替えるにしても実際に入れ替えるまで既存のものを削除しない)ことの保証です。
いろいろと難しい部分もあるかとは思いますが、これが滞りなく行なわれていれば、先のバグ報告はそもそも上がっていないはずなので。
(というか自身もパッと思いつくものとしては各種デスクトップ環境やブラウザなどパッケージによっては、なぜかリポジトリにない時期があり、その期間が結構長くなることが、しかも結構な頻度であって、その間に一括アップデートなどをしてハマることが多い。)
尚、バグ報告であがっているものも、自身の体験上もソースだけでなくバイナリとして通常存在するパッケージであり、更に自身の体験上は、バイナリが不足している際には、ソースも不足していてmakeで補うこともできないか、ソースはあっても一筋縄ではmakeが通らない状態になっているといった状況でした。
こうした背景には、概ね、Question about i386 binary package availability, vs amd64の回答にあるような事情があるのだとしても、年に1度、1日2日程度ならまだしも。。。この点は、早急な改善するなり、代替策を講じるなりした方がよいような。。。と思ったが、i386は少数派で減っていく一方だし、そんな必要はないのか。。。
リポジトリ上のバイナリを基にインストール済みパッケージを自動アップデートしたい場合には、後述のpkgin upgradeやpkgin full-upgradeがオススメです。
バイナリパッケージだけを基にしてインストール済みパッケージにおいて古いものを自動的にアップデートする方法として[pkg_chk -b -P packages_path -u]、不足するパッケージについてバイナリを基にインストール方法として[pkg_chk -b -P packages_path -a]もあります。
ただ、これは、後述するソースコードベースのパッケージ管理システムpkgsrcにおいてmake install、make updateなども日常的に使っていて慣れている場合、もしくは、これを管理してくれる人がいる場合に利用価値が高いのであって、それ以外のケースでは、これを使わず、pkgin upgradeやpkgin full-upgradeを使うのが賢明です。
なぜなら、pkg_chkによるアップデートは、アップデート対象リストを保持するものの、対象を全てアンインストールしてから再インストールする方法を採る一方、環境変数、または、コマンドラインオプションで指定したパスに依存関係を含む全てのパッケージが存在しないと完了できないからです。
これには、主要パッケージも依存関係にのみ使われるようなパッケージも、それぞれ明示的に指定しない限り、デフォルトでは、コンパイル済みのバイナリパッケージを生成しないという背景があり、公式リポジトリにおいても全てのバイナリが存在するとは、限らないからです。
もし、バイナリパッケージが存在しない状態でpkg_chkに[-u]や[-a]を実行してしまうと、これらに関連するパッケージは、その時点では、再インストールされず、システム上には存在しない状態となってしまいます。
そうしたケースでも[pkg_chk -as]としてソースコードからコンパイルして不足するパッケージを追加すれば、不足して終了したところまでの過程をマージして処理が再開、継続され、完了します。
よってpkg_chkによるアップデートにおいて、その全てをバイナリを使ってアップデートするためには、予め自身が必要なバイナリパッケージを全てローカルに生成しておくことが前提となります。
その際、chroot環境下で作業する場合、後述の[pkg_comp]や[mksandbox]を使うこともできます。
ちなみにソースコード情報を元にアップデートする方が、バイナリを元にアップデートする以上に最新に維持することができます。
そうしたい場合には、[-u]と[-s]や[-s]と[-a]オプション付きのpkg_chk、または、[-u]オプション付きで依存関係を含めて個々に順を追って強制的に置き換えていき、[-v]オプション付きで詳細表示するpkg_rolling-replace(pkg_chkよりも高速とされる)を実行します。
何れにしてもNetBSDで最も安全なソースコードベースのインストール済みパッケージの一括アップデートのようにするのが最も安全かつ効率的な方法と言えるでしょう。
ソースコードを元にした方が。。。というのは、NetBSDに限らないことですが、バイナリベースの自動アップデートに加え、このようにソースベースで自動アップデートまでできるのは、NetBSDをはじめとする*BSD、Linuxでは、Gentoo系くらいと、かなり限られます。
というわけでバイナリを基にインストール済みパッケージの更新対象を全てアップデートするというのが目的なら、最も簡単に安全に実現できる後述の[pkgin upgrade]や[pkgin full-upgrade]を使うのが賢明です。
他のNetBSDマシン用にバイナリパッケージをまとめて生成したり、LiveCDの作成、カーネルやユーザーランドなどのアップデートを既存のシステムに影響なく行なう為のchroot環境を自動構築してくれる[pkg_comp](や[mksandbox])もあります。
後述のpkgsrcと共用、もしくは、pkgsrc管理用も含めるとpkg_chk、pkg_rolling-replace、pkg_select、pkg_compなどなど、たくさんあり、pkglintやpkgfindのようにアンスコの付かないpkg*コマンドや、やや変則的なlintpkgsrcといったようなシステムツールもあります。(pkglintやlintpkgsrcは、Cソースコードのチェック用プログラムlintに由来する名称と思われます。)
尚、pkg_chk、pkg_rolling-replace、pkg_select、pkg_compなどなどは、デフォルトではインストールされないので利用する場合には、予めインストールしておきます。
pkgin
pkgin(http://pkgin.net/)は、pkg_add/pkg_deleteをベースとしつつ、これらを改良すると共に大幅増強したパッケージ管理システムでpkgin install、pkgin upgrade、pkgin full-upgrade、pkgin remove、pkgin search、pkgin avail、pkgin list...etc.から成るDebian系のaptやRed Hat系のyumにも似たバイナリベースのパッケージ管理システムです。
pkginは、デフォルトではインストールされていないので利用するには、まず、インストールします。
次にpkginをインストール時に一緒に生成されるリポジトリ登録構成ファイル[repository.conf]に利用するリポジトリを必要に応じて編集しておきます。
その後、[pkgin update](、または、[pkgin up])としてローカルデータベースにリポジトリにあるパッケージを登録・更新します。
[pkgin]の書式は、[pkgin ...]のように修飾子(≒サブコマンド)を伴います。
pkgin installはパッケージのインストール、pkgin upgradeはnon removableと印付けされたパッケージでバイナリのリポジトリにより最新のものがあり、かつ各種パッケージの依存関係上、必要であるものを除いたインストール済みパッケージの自動アップデート、pkgin full-upgradeはインストール済みパッケージ全てを対象にバイナリのリポジトリに最新版があるもの全てを自動アップデート、pkgin removeはパッケージの削除、pkgin searchはリポジトリ上のパッケージの検索、pkgin availはリポジトリ上で利用可能なパッケージの一覧表示、pkgin listはインストール済みパッケージの一覧表示用のコマンドで他にも多くの機能があります。
それぞれ、pkgin in、pkgin ug、pkgin fug、pkgin rm、pkgin se、pkgin av、pkgin ls...etc.のように略記を使うこともできます。([pkgin -h]参照。)
また、[pkgin search]を使うと指定したキーワードにマッチする個々のパッケージを検索でき、[pkgin avail]は登録済みリポジトリにあるパッケージを一覧、[pkgin list]は、システムにインストール済みのパッケージを一覧してくれるので後者2つについては、grepと併用すると特に便利でしょう。
[pkgin install]は、指定したパッケージが、インストール済みである場合、更新が必要ならアップグレードもします。
ちなみに、これらのコマンドを知るまでは、どんなコマンドやライブラリがあるのかを調べたりする際、NetBSD用のXfceだとデフォルトでメニューにも登録されるAll NetBSD Packagesを他のデスクトップを使っている時もブラウザで参照していたものの、数が多いこともあり、サーバも相応に負荷がかかるでしょうし、時に読み込みに時間がかかり、平行作業していると不便なことがあったのですが、これらコマンドのおかげでそういう不便が完全に解消されました。
場合によっては、仮想ターミナルを横に2つ並べてpkgin av | grep -i xxxとpkgin ls | grep -i xxxを、更にもう1つ仮想ターミナルを開いて後述のpkgsrc用のpkgfind xxxやpkg_selectなどを見比べつつ、もう1つでpkgin inしたりもでき、ものすごく便利です。
尚、時として[pkgin avail](やリンクを辿って実際)にあってもpkgin install時に「リポジトリ内のパッケージが利用可能ではない」という旨のエラーに遭遇することもあるので心しておきましょう。
pkgsrc
当初、NetBSD Packages Collectionと呼ばれていたpkgsrcは、バイナリパッケージを扱うpkg_add/pkg_deleteやpkgin包含する呼称でもありますが、ソースコードベースのパッケージ管理システムです。
インストール時にpkgsrcをダウンロード・展開しなかった場合でも、次のようにすれば、[/usr]以下に[pkgsrc]をダウンロード・展開することができます。
尚、[stable/]ディレクトリは、安定版ですが、現在進行形の最新版が必要なら、[current/]ディレクトリにあります。
マシンの性能にもよりますが、ブロードバンド環境ならtarによる展開も含めて数分あれば完了するでしょう。
ただ、cvsを使って取得する方法がより推奨されますので詳しくは先のリンク先を参照ください。
ローカルにカテゴリごと、パッケージごとにソースコードのある場所などを記したMakefileやパッチファイルなどを収録したディレクトリを持つディレクトリツリー(標準では/usr/pkgsrc)を持ち、必要なパッケージのディレクトリに移動してコマンドを実行します。
(NetBSDにおいては、)makeはコンパイル、make installはコンパイル及びインストール、make dependsは、当該パッケージの依存関係にあるパッケージ全てをフェッチ(取得)・インストール、make updateはコンパイル及びアップデート、非公式かつ上級者のみ利用すべきとされるmake replaceはコンパイル及び強制入れ替え、make packageは、コンパイル及びバイナリパッケージの作成、make deinstallは削除、make cleanはコンパイル時に生成された作業ディレクトリの削除、make clean-dependsは当該パッケーに依存するパッケージ(群)のコンパイル時に生成された作業ディレクトリの削除、make show-optionsは、コンパイルオプションの表示、pkgsrcツリートップ(/usr/pkgsrc等)でmake search key=Keywordを実行するとpkgsrc内のパッケージ検索といった具合にいろんな操作を簡単に行なうことができます。
尚、make install clean clean-dependsのように続けて指定することもできます。
これらが個別のパッケージやその依存関係にあるパッケージ用であるのに対し、/usr/pkgsrc以下全てのworkディレクトリを削除してくれるpkgcleanコマンドもあります。
ちなみにmake search key=Keywordの代わりに、任意のパスで実行可能で、より簡単・迅速なpkgfind Keyword、make deinstallの代わりに任意のパスで実行可能なpkg_deleteを使うこともできますし、pkgsrc内の複数のパッケージのあらゆる情報を調べたり、管理したいならpkg_selectもあり、make replaceがパッケージごとであるのに対し、インストール済みパッケージ全てのアップデート(強制入れ替え)をしたい場合には、pkg_rolling-replaceを使うことができます。
lintpkgsrc -i、もしくは、pkg_chk -q -uとするとpkgsrcの情報を基にアップデートが必要なインストール済みパッケージをリストアップしてくれます。
これらのコマンドの実行やpkg_chk -gとするとpkgsrcパス直下にアップデートを要するパッケージリストpkgchk.confが生成され、これを使ってpkg_rolling-replaceやpkg_chkにアップデート用オプション[u]や不足パッケージ追加オプション[a]とバイナリパッケージをインストールする[b]とリポジトリ指定の[P]、もしくは、ソースコード情報からコンパイルしてインストールする[s]などを組み合わせることでインストール済みパッケージの自動アップデートを行なうことができ、途中エラーとなって対処が必要となった後も対処さえできれば、再度実行することで先のリストを基に(マージして)アップデートを途中から再開することができます。
ローカルに保持するpkgsrcは簡単にアップデートでき、最新にしたpkgsrcを基にインストール済みパッケージをアップデートすれば、特にNetBSDに限らず、本家とディストリビューション間でバージョンの同期がとれていないことが一般的なサードパーティ製ソフトウェアについては、バイナリのリポジトリを基にアップデートする以上に遥かに新しい状態を維持できるので巷のサービスを利用するにしてもセキュリティ面からしても理想的な状態にすることができます。
尚、cvs updateは、pkgsrcツリートップ(/usr/pkgsrc等)で実行します。
NetBSD(pkgsrc)マシンが複数台ある場合でもpkgsrcを最新にした(最速のマシン)1台を基に、その際、同時にバイナリパッケージを作成しておけば、他のマシンはpkgsrcを持たずとも済む上、インターネットではなく、LAN上のNFS/Network File SystemやSamba(CIFS/SMBFS)経由でpkgin upgrade、pkgin full-upgradeなどでバイナリを使ったインストール済みパッケージの自動アップデート(やpkgin installやpkg_addでインストール)ができる為、こうした全てのマシンにおいて効率的にシステムを理想的な状態に保つことができます。
pkgsrcの利用を始めるにあたっては、stableを使うかcurrentを使うかは、それらの違いを理解することを含め、重要な選択と言えます。
現行、stable branchは、currentから年に4回分岐され、その後はセキュリティ上の更新のみが行なわれる安定版リリースであり、年と四半期ごと(Q1〜Q4)の枝番が付与されるもので例えば、tarballなら、pkgsrc-2016Q1.tar.gz、pkgsrc-2016Q2.tar.gz...のような名称となります。
currentは、最新バージョンや最新の状態にあるパッケージであると同時に現在進行形なので全てが完全であるとは限らない為、makeが通らないパッケージがあっても不思議ではありません。
自身は、「最新」という認識しかなく、公式採用されていないwipの存在もあり、なんでpkgsrcにリリースされたパッケージなのにmakeが通らないケースが多々あるんだろう。。。と思いつつ、ハマり続け、恥ずかしながら、数年経った今頃になって、どうやらcurrentを使いつづけていたこと、これがその理由か。。。と気づくに至りました。。。
それでも今となってはcurrentでいいかなとも思わなくもなく、まだ試してはいませんが、stable branchを使っていれば、未知のバグの可能性はあるにしても基本、安定して利用できていたということであり、pkg_chkやpkg_rolling-replaceが経過を保持してくれるとはいえ、途中のエラーを解決しきれず、インストール済みパッケージが全部削除された状態になってハマるなんてこともなくなるはず。
自身のようなマヌケな話はないかとは思いますが、cvsなどを使うと簡単にアップデートできてしまうpkgsrcだからこそ、stableとcurrentの意味を理解するのは「最初こそが」肝心と言えるでしょう。
関連リンク
