Ubuntu日和
【第4回】これで脱・初心者。Ubuntuのパッケージ管理入門
2022年6月4日 06:24
第3回では、エルデンリングをはじめとするメジャーな最新ゲームをUbuntuでもプレイできることを紹介した。おそらく今ごろは、王になるべく広大な狭間の地で旅を続けていることだろう。最終的に読者の身体が闘争を求めてくれることを切に願っている。
さて、今回は再び基本に立ち返って、Ubuntuでソフトウェアをインストールする上で重要な 「パッケージ管理」 について解説する。ここでパッケージ管理を持ってきたのは、今後いろんなソフトウェアをインストールし活用していく上で、今回の話を抑えておくと理解度がぐっとあがるからだ。とりあえずこの記事の内容を理解し活用できるようになれば、「Ubuntuの初心者」を脱出したと言って良いだろう。
ソフトウェアのインストール方法あれこれ
Ubuntuは「初心者向け」を標榜していることもあって、デスクトップ版で最初からインストールされているソフトウェアは、デスクトップPCとして最低限必要なものに加えて如何にも初心者が必要そうなアプリケーションに限られている。極端な話、Webブラウザ、ファイルブラウザ、オフィスソフトウェア、メディアプレイヤー、ソリティア、マインスイーパーあたりがあれば、おおよそPCとしては事足りるだろう。
言い方を変えると、「最初から入っているソフトウェア以外を使ってみよう」と思うのが、初心者からの脱却の第一歩と言える。少し前のWindowsユーザーなら、PCを購入したあとに「WebブラウザであるInternet Explorerを起動して、インターネットをエクスプロールするためのWebブラウザのインストーラーをダウンロード」という、とても哲学的な行為に耽った記憶もあるのではないだろうか。
Ubuntuでも一歩先の使い方を目指すなら、ソフトウェアのインストールが必要になる。そこでまず、Ubuntu上に特定のソフトウェアをインストールする方法の選択肢を紹介しよう。
- 公式リポジトリからパッケージをインストール
- snap・Flatpak・AppImageパッケージをインストール
- PPAや非公式リポジトリからパッケージをインストール
- debファイルを直接インストール
- プログラミング言語固有の仕組みを使う
- 自分でソフトウェアをビルドする
数は多いように見えるが、選び方自体はおおよそ決まっているためそこまで難しくはない。
まず最初はUbuntuの パッケージ管理システム(apt) などのツール(Ubuntu SoftwareやSynaptic、apt/snapコマンド)を用いて、公式リポジトリに求めるソフトウェアのパッケージがないかを探そう。もし存在し、バージョン等の条件も満たされるなら、そのパッケージを使うことを強く推奨する。なぜならUbuntuのパッケージは、Ubuntuシステム上できちんと動くように必要な調整が行なわれている可能性が高いからだ。
最近のUbuntuは、Linuxの中でもメジャーな地位を確立したため、開発元が提供するLinux版のソフトウェアがそのまま動く可能性は高い。しかしながらソフトウェアの開発者は必ずしもUbuntuの流儀を把握しているわけではない。たとえばUbuntuのshコマンドは、「Debian Almquist Shell」というPOSIX互換のシェルになっている。これは比較的システム内部でも利用頻度の高いシェルスクリプトは、軽量で高速なシェルで動かしたほうが良いという判断が行なわれた結果だ。
それに対してDebian系以外のshコマンドは、より高機能で独自の拡張を備えたGNU bashとなっていることも多い。結果として、sh用のスクリプトとして書きながらbashの独自拡張機能を使ってしまい、Ubuntuではエラーになってしまう、なんてこともよく発生する。Debian/Ubuntuにおいてパッケージング作業を担う パッケージメンテナー が作成している公式リポジトリのパッケージだと、このあたりの互換性の問題を調整している可能性が高い。ただしあくまで「可能性が高い」だけで、すべてなんとかなっているとは限らない点に注意は必要だ。所詮、人間がやっていることである以上ミスや漏れはある、そういうおおらかな気持ちで使ってほしい。
そして何より統一したUIを利用してパッケージを管理できることで、普段使うマシンの作業コストが大きく下げられる。ソフトウェアをインストールするために、Webブラウザでzip・exe・msiファイルを探してダウンロードしなくても良いし、システムにお任せすればセキュリティアップデートが適用されるし、アンインストールやアップグレードで問題が起きることも少ない。いいことずくめと言えるだろう。
ただしバージョンはちょっと古いし、余計なパッチが当たっていることもあるし、そのせいでたまにうまく動かないこともある。やはり人間がやっていることである以上ミスや漏れはあるので、何度も言うがおおらかに受け入れる気持ちが重要だ。コンピュータに関するだいたいの問題は人類の存在そのものに原因があるのだから。
上図では公式のsnap版があればまずそれを試す流れになっているが、ここは好みが分かれるところだ。現状だと日本語表示/入力に問題がないか、あたりを確認しておけば良いだろう。後述するようにsnapパッケージはまだまだ登場したばかりなので、最初から選択しから除外してしまうという手もある。
公式リポジトリにパッケージが存在しない、存在してもバージョンが古く欲しい機能がない、という場合はほかの手段を選ぶことになる。ここから先で何を選ぶかは「ソフトウェアによる」としか言えない。よって上図では「開発元のドキュメントを読め」という身も蓋もないことしか書いていない。上手はあくまで「判断基準の1つ」だ。たとえば「俺は自分でコンパイルしたバイナリしか信じない」という考え方もあるだろう。その時はソフトウェアに寄らず「ビルド」一択になる。ただしそれなら、Ubuntuよりも、パッケージ管理システムの中にセルフコンパイルの仕組みも組み込まれたGentoo Linuxがおすすめだ。
Ubuntuの公式リポジトリの活用
Ubuntuで公式に提供しているパッケージは、すべて特定のビルドサーバーでビルドした上でパッケージ化し、公式リポジトリから提供されている。一部繰り返しになるが、まずは公式リポジトリのパッケージを使う利点をあげておこう。
- Ubuntu用に調整されたソフトウェア群の提供
- 依存関係の自動解決
- セキュリティアップデート
- パッケージの更新が簡単
- 「出所の怪しいバイナリ」を使わなくて済む安心感
- ソースコードの取得
- 上記を統一したUIで利用可能
さて、ここまで何の説明もなく使っていた 「公式リポジトリ」 について解説しておく。端的に言うと「公式リポジトリ」とは「Ubuntuコミュニティによってそのリリースごとにメンテナンスされており、Ubuntuインストール時に最初から有効化されている、ソフトウェアパッケージを提供するHTTPサーバー」となる。
システム上では一般的に「/etc/apt/sources.list」に公式リポジトリのURLなどが記録されている。ちなみに日本語環境としてインストールした場合は、日本の公式ミラーサーバーである「jp.archive.ubuntu.com」とセキュリティアップデートのみを適用する「security.ubuntu.com」が有効化されているはずだ。
ミラーサーバーは、Superキー(Windowsキー)を押し、「software」を検索することで表示される「ソフトウェアとアップデート」を起動するとそこから変更できる。
Ubuntuの公式リポジトリには「22.04」などのリリースとは別の概念として「コンポーネント」が存在する。上図で言うところの、 「main・universe・restricted・multiverse」 がそれに該当する。ドキュメントによっては、これをもって「リポジトリ」と呼ぶこともある。「main・universe・restricted・multiverse」はUbuntu独自の分類方法で、それぞれ次のようなパッケージが所属する。
- main：Canonicalが公式にセキュリティアップデートを提供するソフトウェアで、おおよそフリーソフトウェアなライセンスで構成される
- universe：コミュニティがセキュリティアップデートを提供するソフトウェアで、おおよそフリーソフトウェアなライセンスで構成される
- restricted：フリーソフトウェアではないものの、デバイスを動かすためには必要なソフトウェア
- multiverse: ライセンスや法律的な制約があるソフトウェア
ちなみにDebian/Ubuntuにおける「フリーソフトウェアかどうか」は、原則としてオープンソースの定義の元にもなった「Debianフリーソフトウェアガイドライン(DFSG)」に準拠しているかどうかで判断されている。しかしながらいくつかのハードウェア向けのファームウェアやドライバは再配布は許容しているものの、ソースコードが公開されているか公開されていても改変は許可されていないこともある。そこでCanonicalが特定のハードウェアを公式にサポートする上で必要なものについては、restrictedに所属する。また、CPUのマイクロコードなどの「Ubuntu的にはソフトウェアではない」と判断されたものについては、ライセンスの内容に関わらずmainに所属している場合もある。
mainとrestrictedに所属するソフトウェアについては、Ubuntuプロジェクトを支援するCanonicalのセキュリティチームのメンバーがその仕事の範囲内で、セキュリティアップデート等の対応を行なう。それに対してuniverseやmutliverseは、あくまでUbuntuプロジェクトのコミュニティメンバーの努力に期待する。ただしCanonicalのコア開発者はおおよそコミュニティメンバーでもあるため、メジャーなソフトウェアに関してはmainかuniverseに関係なく、セキュリティアップデートを提供されることが多い。
パッケージのビルドはビルドサーバー(buildd)の仕事だ。これは公式リポジトリは異なるサーバーで行なわれている。古いUnix/Linuxだとソフトウェアのインストールと言えば「./configure; make; make install」みたいな流れだったが、現在ではバイナリパッケージの配布が主流となっている。
たとえばDebian/Ubuntuの場合は、コンパイラやlibcのバージョンといったリリースごとで採用された「パッケージのビルド環境」がコミュニテイ内部で合意されており、どのパッケージもそれを利用してビルドされた結果、個々の環境の差をそこまで気にすることなく共通のバイナリを使えるからだ。
配布しているバイナリが正しいかどうかは、GNUPG(GPG)を用いて担保されている。具体的にはリポジトリ上のパッケージ一覧が更新されたら、リリースごと・コンポーネントごとのパッケージ名・ファイル名・そのハッシュ値等を保存したファイル(Packages等)が更新される。さらにそのリリースごとのPackages等のハッシュ値はすべて、InReleaseファイルに記録され リポジトリの秘密鍵 で署名される。ちなみにミラーサーバー側には、署名済みの状態で同期しているため、ミラーサーバー側で個別に署名することはない。
パッケージ管理システムを用いてバイナリデータを取得するUbuntuマシン側では、あらかじめ リポジトリの公開鍵(リポジトリ鍵) がインストールされている。最近のUbuntuだとubuntu-keyringパッケージが提供する「/etc/apt/trusted.gpg.d/ubuntu-keyring-2018-archive.gpg」がそれに該当する。パッケージ管理システムはこの公開鍵を用いて、取得したInReleaseがリポジトリの秘密鍵で署名されたかを検証し、その検証が正しければ、その先はハッシュ値をたどることでバイナリの正当性を判断できる、というわけだ。
このためパッケージのリポジトリはHTTPSを必要としていない。もちろんHTTPSを使っても良いし、最近のaptは最初からHTTPSに対応している。しかしながら、今のところUbuntuの公式リポジトリおよび公式ミラーは、HTTPでの運用となっている。
パッケージ管理システムの基本的な使い方
リポジトリの雰囲気が分かったところで、パッケージ管理システム(apt)の基本的な使い方を説明しよう。といっても、そこまで難しいことではない。画面左のランチャー部分にあるバッグ型のアイコンや、Superキー(Windowsキー)を押して「software」で検索すれば表示される「Ubuntu Software」を起動して、ソフトウェアを検索、インストールボタンを押すだけだ。
ポイントは「ソースの選択」になる。Ubuntuは現在、従来のaptシステム(debパッケージ)とは別に「snapパッケージ」を開発している。Ubuntu Softwareを使用したとき、もし検索結果にsnapパッケージがあれば、それを優先的にインストールするようになっているのだ。しかしながら、snapパッケージは便利な反面、アプリケーションによっては日本語入力ができないことがあるなど、まだまだ問題も多い。例に挙げたOBS Studioなら問題はないものの、両方選べるアプリケーションは、どちらが良いかは実際に使って判断すると良いだろう。ちなみにどちらのケースも、インストール後に表示されるゴミ箱アイコンを押せばアンインストールできる。
Ubuntu Softwareは公式リポジトリ上のデスクトップアプリのインストールに特化している。このためサーバーアプリケーションなどは検索してもヒットしない。デスクトップ以外のアプリケーションをインストールするにはCLIでaptコマンドを使うのが定番だが、GUI版で操作したければSynaptic Package Managerをインストールして使うのも1つの手だろう。Synapticはaptコマンドの操作性をそのままGUIにしたような作りであるため、ある程度aptに使い慣れていると分かりやすいが、パッケージのインストール程度であれば初見でもなんとかなるはずだ。
ついでにCLI版のインストール方法も紹介しておこう。デスクトップ版のUbuntuを使っているのであれば、まずは「Ctrl+Alt+t」で端末を起動しておく。そこから次のように入力するだけだ。
$ apt search obs studio
(中略)
obs-studio/jammy 27.2.3+dfsg1-1 amd64
recorder and streamer for live video content
(中略)
$ apt show obs-studio
Package: obs-studio
Version: 27.2.3+dfsg1-1
(中略)
Description: recorder and streamer for live video content
OBS Studio is designed for efficiently recording and streaming live video
content. It supports live RTP streaming to various streaming sites.
(中略)
$ sudo apt install obs-studio
(ログイン時に使うパスワードを入力)
パッケージの検索や情報表示には管理者権限は不要だが、インストールには管理者権限が必要となる。CLI版の場合は「sudo」コマンドを用いて、権限昇格を行ない処理するのが定番だ。ちなみにパッケージのアンインストールは「sudo apt remove obs-studio」となる。
パッケージの更新は、セキュリティアップデートなら原則自動で行なわれ、不具合更新などは1週間ごとぐらいに通知ダイアログが表示される。このあたりは第2回の「便利なパッケージ管理システム」でも簡単に紹介した。もしCLIで明示的に実行したいなら次のように対応しよう。
$ sudo apt update
$ sudo apt upgrade
前者の「update」がパッケージのメタデータ、前述のInReleaseやPackagesファイルを更新する。後者の「upgrade」は更新されたパッケージがあるならそれをダウンロード・更新する。また「apt list –upgradable」で「upgrade」時に更新されるパッケージのリストを表示できる。
snap・Flatpak・AppImageパッケージとは
最近のLinuxディストリビューションでは 「ユニバーサルパッケージングシステム」 と呼ばれるシステムおよびそのためのパッケージフォーマットが流行りだしている。
これは何なのかというと、「どのLinuxディストリビューション・どのリリースでも使える統一的なパッケージフォーマットを作ろう」という試みだ。現在は、Ubuntuを含むDebian系だとdebファイルだし、RHEL系だとrpmファイルなど、現在のLinuxはディストリビューションごとに採用しているパッケージフォーマットが異なる。さらにLinuxディストリビューションのリリースごとに採用されているライブラリのバージョン等が異なるため、リリースごとにも異なるバイナリパッケージをビルドしなくてはならないことも多い。
ソフトウェアの開発元がバイナリパッケージを提供しようとすると、これはかなり面倒な状態だ。本来この面倒な作業は、個々のディストリビューションのパッケージメンテナーが肩代わりしていたわけだが、最近は比較的短い周期でリリースされることも増えてきたため、メンテナーも追いかけるのが大変になっている。Linuxディストリビューションの違いによって修正しているのであれば、その維持も必要になる。
これがユニバーサルパッケージになれば、UbuntuやRHELのどのリリースでも同じバイナリパッケージを利用できるというわけだ。その仕組み自体はまた別の機会に解説するとしよう。
現在、ユニバーサルパッケージとしては、Ubuntuが推進するsnap、Fedoraなどが採用するFlatpak、追加でソフトウェアを用意することなく動かせるAppImageあたりが、主流になりつつある。そう、この時点でもう ユニバーサルと名乗りつつ3種類に分断している 。リリース依存性が低くなったというメリットはあるものの、開発者にとってもユーザーにとっても「結局どれにすればいいのか」と余計に悩む結果になってしまった。このあたりはもう特定の企業によって支配的にコントロールできるわけではない、Linuxディストリビューションのチャームポイントと笑うしかない。
現時点で、snap版・Flatpak版・AppImage版のすべてが存在するソフトウェアの場合、Ubuntuではsnap版のインストール・アップグレードが簡単だ。しかしながらデスクトップアプリケーションの場合はFlatpak版のほうが品質が高い傾向がある。複数のバージョンを併用したいならAppImage版が一番楽に実現できる。よってsnap版で試して、それで不満が出ればFlatpak版を試す、バージョンによってはAppImage版を使うという選択肢が無難だろう。
ユニバーサルパッケージはまだ本格的に活用されだしたばかりということもあって混沌とした状態になっている。いずれフォーマット間の相互運用性等も確立し、もう少しまともな状況になるはずだ。
ここまでで、公式リポジトリを利用したパッケージの管理方法はおおよそ掴めたかと思う。公式リポジトリのみを使う限り、パッケージ管理そのものについてはそうそう問題が起きないはずだが、このあたりは「どれくらい痛い目を見たか」で練度も変わってくるのが実情だ。そこで次回はよりトラブルが起きやすい、「リリース間のアップグレード」や「サードパーティのリポジトリ」について説明しよう。