Ubuntu Weekly Recipe

第419回 長期サポート版で改めて見直す,PPAとのお付き合い

この記事を読むのに必要な時間:およそ 6 分

Ubuntu 16.04 LTSが無事にリリースされました。今回はUbuntuを使う上では欠かせない存在となったPPAについて,改めてその使い方を見直してみます。

そのPPAは本当に必要ですか?

2016年4月22日(地球のどこかのタイムゾーン)に,Ubuntu 16.04 LTSがリリースされました。さっそくアップグレード時の問題などが報告・修正されているので,Topicsでも言及されているように当分は本番環境のアップグレードを控えた方がいいでしょう※1)⁠特に14.04のユーザーは,ある程度問題が洗い出されるポイントリリースまでは,アップグレードを控えるようにしてください。

※1
この記事は16.04からYakkety/16.10にアップグレードした環境で執筆しています。

さて2年ぶりのリリースということもあって,前回や前々回のLTSである14.04や12.04からのアップグレードを予定されている方も多いことでしょう。2年も使いつづけていると「秘伝のたれ」化が進行し,再インストールによって同じ環境を再現することが難しい状況になっているかもしれません。特にPPAを使っている場合は,⁠秘伝のたれ」度が高くなる傾向があります。

Ubuntuは,ディストリビューションのアップグレードの際にPPAを含むサードパーティのリポジトリを無効化します。アップグレードが完了した後に,ユーザーが必要に応じて個々のリポジトリを再度有効化する必要があるのです。よって,これを機に,そのPPAが本当に必要なのかどうか見直すことにしましょう。

この素晴らしいPPAに祝福を

PPA(Personal Package Archive)はUbuntuを使う上で非常に便利な機能です※2)⁠主に以下の用途で使用します。

※2
PPAの使い方そのものは第46回の水野さんの記事を参照してください。7年以上前の記事ですが,今でも通用する内容です。PPAの登録や削除は坂本さんの第314回が参考になるでしょう。
  • リポジトリには存在しないパッケージを提供する
  • リポジトリよりも新しいバージョンのパッケージを提供する
  • パッケージのCIを実現する

公式リポジトリからは提供されないソフトウェアをインストールしたい場合,ソースコードをダウンロードし,ビルドし,インストールするという手法が古くから使われてきました。しかしながらこの方法はあまりユーザーフレンドリーではありません。特に大きなプロジェクトだとビルドに時間がかかってしまいます。

そのため開発者があらかじめビルドしたバイナリパッケージを提供するという手法が出てきました。独立したソフトウェアであればこの方法で大体まかなえますが,自動的なアップグレードには対応できません。また,他のパッケージに依存する場合は,さらに一手間必要になります。

そこでUbuntuではPPAという形で,公式リポジトリと同じパッケージビルドサーバーとリポジトリを,ソフトウェアの開発者も使えるようにしました。ソフトウェア開発者から見れば,バイナリパッケージのビルド・リリースのためのインフラを構築・運用する手間が省けますし,一般ユーザーから見れば,一度PPAを登録してしまえば公式リポジトリと同じUIでソフトウェアのインストールやアップグレードを行えます。Ubuntu側としては,PPAでビルドできるソースパッケージをソフトウェア開発者が作成してくれれば,将来的に公式リポジトリにも取り込みやすくなります※3)⁠

※3
有償サービスではありますが,クローズドなプロジェクト向けのPPAも構築できます。

またUbuntuの公式リポジトリは,一度リリースしたら不具合の修正とセキュリティ対応がメインで,パッケージのバージョンをできるだけあげないというスタンスをとっています。よって特定のパッケージの新しいバージョンを使いたい場合は,どうしても新しいリリースを使わざるを得ません。これを回避するために個人がPPAを使うということもよくあります。PPAは公式リポジトリの別リリースや,他のユーザーのPPAからのパッケージのコピーに対応しています。これをうまく使えば,パッケージの構築知識がなくても自前のPPAを作れるのです。

さらに最近はGitやBazaarリポジトリのHooksに応じてパッケージをビルドする機能も公開されているため,パッケージのCI用途にもPPAが使われています。たとえばKubuntuチームのCIWaylandのデイリービルドもPPAを使っていますし,Ubuntu 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はインストール時点で有効化されています。ただし自動的にはインストールされません。たとえばUbuntu 14.04 LTSでlxcパッケージのバージョンを確認してみます※7)⁠

※7
Ubuntu 16.04 LTSはリリースされたばかりなので,まだBackportsには新しいパッケージが存在しません。使い方は14.04と同じなので,ここでは14.04で説明します。ちなみに16.04のaptコマンドは,ほぼこれまでの「apt-なんとか」を代替できるようになりました。⁠apt-cache policy」「apt policy」として実行できます。
$ apt-cache policy lxc
apt-cache policy lxc
lxc:
  インストールされているバージョン: (なし)
  候補:               1.0.8-0ubuntu0.3
  バージョンテーブル:
     1.1.5-0ubuntu3~ubuntu14.04.1 0
        100 http://jp.archive.ubuntu.com/ubuntu/ trusty-backports/main i386 Packages
     1.0.8-0ubuntu0.3 0
        500 http://jp.archive.ubuntu.com/ubuntu/ trusty-updates/main i386 Packages
     1.0.7-0ubuntu0.7 0
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main i386 Packages
     1.0.3-0ubuntu3 0
        500 http://jp.archive.ubuntu.com/ubuntu/ trusty/main i386 Packages

1.0.3がリリース時のバージョンです。セキュリティアップデートに対応した結果,1.0.7や.1.0.8などがリポジトリに存在します。一番上にある1.1.5がBackportsにあるパッケージです。上記の「候補」が1.0.8になっていることからもわかるように,Backportsにあるパッケージはそのままではインストールされません。

Backportsのパッケージをインストールする方法は2種類存在します。

そのパッケージのみをBackportsから取得する方法
$ sudo apt-get install lxc/trusty-backports

依存パッケージも含めてBackportsから取得する方法
$ sudo apt-get install -t trusty-backports lxc

前者については依存パッケージはBackportsではなく通常のリポジトリからしか導入しません。よって依存パッケージもBackportsから取得したい場合は後者を利用してください。逆に依存パッケージはBackportsのバージョンに更新したくない場合は,前者を利用することになります。

このようにBackportsを使えば,PPAを導入しなくても良い場合がしばしば存在します。ただしBackportsは公式リポジトリではあるものの,セキュリティアップデートを保証しているわけではないことに注意してください。

著者プロフィール

柴田充也(しばたみつや)

Ubuntu Japanese Team Member株式会社 創夢所属。数年前にLaunchpad上でStellariumの翻訳をしたことがきっかけで,Ubuntuの翻訳にも関わるようになりました。

コメント

コメントの記入