LTSが無事にリリースされました。今回はUbuntuを使う上では欠かせない存在となったPPAについて,改めてその使い方を見直してみます。LTSがリリースされました。アップグレード時の問題などが報告・修正されているので,Topicsでも言及されているように当分は本番環境のアップグレードを控えた方がいいでしょう(※1⁠)⁠。14.04のユーザーは,ある程度問題が洗い出されるポイントリリースまでは,アップグレードを控えるようにしてください。※1この記事は16.04からYakkety/16.10にアップグレードした環境で執筆しています。2年ぶりのリリースということもあって,前回や前々回のLTSである14.04や12.04からのアップグレードを予定されている方も多いことでしょう。2年も使いつづけていると「秘伝のたれ」化が進行し,再インストールによって同じ環境を再現することが難しい状況になっているかもしれません。PPAを使っている場合は,「⁠秘伝のたれ」度が高くなる傾向があります。Ubuntuは,ディストリビューションのアップグレードの際にPPAを含むサードパーティのリポジトリを無効化します。アップグレードが完了した後に,ユーザーが必要に応じて個々のリポジトリを再度有効化する必要があるのです。よって,これを機に,そのPPAが本当に必要なのかどうか見直すことにしましょう。Archive)はUbuntuを使う上で非常に便利な機能です(※2⁠)⁠。以下の用途で使用します。※2PPAの使い方そのものは第46回の水野さんの記事を参照してください。7年以上前の記事ですが,今でも通用する内容です。PPAの登録や削除は坂本さんの第314回が参考になるでしょう。リポジトリには存在しないパッケージを提供するリポジトリよりも新しいバージョンのパッケージを提供するパッケージのCIを実現する公式リポジトリからは提供されないソフトウェアをインストールしたい場合,ソースコードをダウンロードし,ビルドし,インストールするという手法が古くから使われてきました。この方法はあまりユーザーフレンドリーではありません。大きなプロジェクトだとビルドに時間がかかってしまいます。そのため開発者があらかじめビルドしたバイナリパッケージを提供するという手法が出てきました。独立したソフトウェアであればこの方法で大体まかなえますが,自動的なアップグレードには対応できません。他のパッケージに依存する場合は,さらに一手間必要になります。そこでUbuntuではPPAという形で,公式リポジトリと同じパッケージビルドサーバーとリポジトリを,ソフトウェアの開発者も使えるようにしました。ソフトウェア開発者から見れば,バイナリパッケージのビルド・リリースのためのインフラを構築・運用する手間が省けますし,一般ユーザーから見れば,一度PPAを登録してしまえば公式リポジトリと同じUIでソフトウェアのインストールやアップグレードを行えます。Ubuntu側としては,PPAでビルドできるソースパッケージをソフトウェア開発者が作成してくれれば,将来的に公式リポジトリにも取り込みやすくなります(※3⁠)⁠。※3有償サービスではありますが,クローズドなプロジェクト向けのPPAも構築できます。Ubuntuの公式リポジトリは,一度リリースしたら不具合の修正とセキュリティ対応がメインで,パッケージのバージョンをできるだけあげないというスタンスをとっています。よって特定のパッケージの新しいバージョンを使いたい場合は,どうしても新しいリリースを使わざるを得ません。これを回避するために個人がPPAを使うということもよくあります。PPAは公式リポジトリの別リリースや,他のユーザーのPPAからのパッケージのコピーに対応しています。これをうまく使えば,パッケージの構築知識がなくても自前のPPAを作れるのです。最近はGitやBazaarリポジトリのHooksに応じてパッケージをビルドする機能も公開されているため,パッケージのCI用途にもPPAが使われています。PhoneもPPAでビルドしたあとにテストを通ったものが,開発版リポジトリに投入される仕組みになっています。このようにPPAはUbuntuの内外で深く使われているのです。PPAはマシンの健康を害する恐れがあります便利なPPAですが,当然のことながら万能ではなく,リスクも存在します。目的以外のパッケージがアップグレードされるUbuntuの公式リポジトリのパッケージは,基本的にそれなりにパッケージングの知識がある人がチェックしています。それでも「残念な」品質のパッケージが投入されたり,意図しない不具合が紛れ込むことが発生します。PPAは公式リポジトリのようなチェックは行われませんし,そもそもパッケージを作る人がパッケージングに詳しい保証もありません。インストールはできるけれども削除はできない,ましてやアップグレードなんて不可,そんなパッケージがPPAに紛れ込んでいる可能性も十分にあるのです。lintianやpiuparts,autopkgtestといったパッケージそのものやその内容をテストするツールはたくさんあります。アップロードする人がそれを使っているとは限らないのです。信頼性は品質に内包される問題です。チェックが入らない以上,パッケージをアップロードする人がこっそりと悪さをするパッチを仕込むことも可能です。利用規約上許されないことですが,言い換えると利用規約でしか防げていないということです。本当にそのPPAを作った人を信用できるかどうか,PPAを導入する前に一考すべきです(※4⁠)⁠。※4当然のことながら,これらの懸念点は公式リポジトリにも存在します。一応,パッケージをアップロードできる人は制限されていますし,アップロードする人が確認する前提になっています。PPAは「問題に遭遇する可能性が高くなる」という程度問題でしかありません。最後のリスクは,あまり話題にはならないかもしれません。PPAを導入すると,そのPPAに存在するパッケージと公式リポジトリのパッケージの優先度は同じ値になります。PPAに存在するパッケージのバージョンが公式リポジトリのバージョンより高かったら,アップグレード時にPPA版のバージョンに更新されてしまうのです。PPAに目的のパッケージしか存在しなければ,そこまで問題にはなりません。新しいバージョンのパッケージをインストールするためには,他の依存するライブラリも更新しなくてはならないということはよくあります。そのため,そのようなパッケージを提供するPPAなら,新しいライブラリパッケージも提供していることが一般的です。ライブラリを更新すると,PPAとは関係ない他のパッケージが動かなくなってしまう可能性もあります。よってPPAを導入するには,どのパッケージが更新されるのかを把握しておくことが必要になります。個人用途のPPAには,複数の目的のパッケージを一つのPPAにまとめてしまっていることがよくあります。そのようなPPAを安易に導入してしまうと,芋づる式に他のパッケージまでアップグレードされてしまうのです。一般的に,システムをより安定した状態で運用したいのであれば,PPAの導入はできるだけ避けるべきです。PPAを導入するごとにそのシステムの好感度は下がり,あまりに下がりすぎると突然別れを告げられる,それぐらいの覚悟はもっておきましょう。コンテナもBackportsもあるんだよ上記のリスクを避ける一つの解決策は,コンテナや仮想マシンを使うということです。目的の用途の隔離環境を一つ用意し,PPAはその環境でのみ使うことにします(※5⁠)⁠。コンテナや仮想マシンであれば,バックアップをとったり,他のホストに環境ごと移行することも簡単です。ホスト側のアップグレード時にPPAが無効化されたとしても,隔離環境内部への影響を考える必要はありません。若干手間がかかるという問題点をクリアできるなら,PPAは隔離環境でのみ使うというポリシーにしてしまうことをおすすめします(※6⁠)⁠。※5たとえば第416回では,コンテナの中にScratchをインストールして利用するという手法を用いました。GUIアプリであっても,隔離環境で動かすことが可能なのです。※6ただし隔離環境からは見えない特定のハードウェアを使うために必要なPPA,などになってくるとホストにPPAを導入せざるを得ないでしょう。そのようなケースは限定的なので,例外として扱ってもそこまで問題にはならないはずです。「より新しいバージョン」が必要なのであれば,「⁠Backports」を使うという手もあります。Ubuntuは一度リリースすると,公式リポジトリのバージョンをあげることは原則行いません。Backportsに限っては,このルールが若干緩い形で運用されます。ライブラリのような影響範囲の広いパッケージのアップグレードは行われませんが,単独のソフトウェアや少量の依存関係であればBackports上で新しいバージョンのパッケージを提供できます。Backportsに,目的のバージョンのパッケージが存在するなら,PPAではなくBackportsを試してみましょう。Backportsはインストール時点で有効化されています。自動的にはインストールされません。LTSでlxcパッケージのバージョンを確認してみます(※7⁠)⁠。LTSはリリースされたばかりなので,まだBackportsには新しいパッケージが存在しません。使い方は14.04と同じなので,ここでは14.04で説明します。ちなみに16.04のaptコマンドは,ほぼこれまでの「apt-なんとか」を代替できるようになりました。policy」として実行できます。Packages1.0.3がリリース時のバージョンです。セキュリティアップデートに対応した結果,1.0.7や.1.0.8などがリポジトリに存在します。上にある1.1.5がBackportsにあるパッケージです。上記の「候補」が1.0.8になっていることからもわかるように,Backportsにあるパッケージはそのままではインストールされません。Backportsのパッケージをインストールする方法は2種類存在します。lxc前者については依存パッケージはBackportsではなく通常のリポジトリからしか導入しません。よって依存パッケージもBackportsから取得したい場合は後者を利用してください。逆に依存パッケージはBackportsのバージョンに更新したくない場合は,前者を利用することになります。このようにBackportsを使えば,PPAを導入しなくても良い場合がしばしば存在します。Backportsは公式リポジトリではあるものの,セキュリティアップデートを保証しているわけではないことに注意してください。