こんにちは、かつコーチです。
「apt installしたら知らないパッケージまで大量にインストールされた」。
「削除しようとしたら『他のパッケージが依存しています』と止められた」。
前回の記事でaptコマンドの基本操作を紹介しましたが、この記事ではもう一歩踏み込んで、パッケージ管理の裏側にある依存関係とリポジトリの仕組みを解説します。
仕組みを理解しておくと、エラーの原因を自分で推測できるようになり、サーバー運用の安心感が大きく変わります。
検証環境はUbuntu 26.04 LTSです。
依存関係とは？
依存関係の定義
依存関係とは、あるパッケージが正常に動作するために必要な、別のパッケージやライブラリとのつながりのことです。
たとえばWebサーバーのnginxは、単体のファイルだけで動いているわけではありません。
暗号化通信に使うlibsslや、文字コード処理に使うlibpcreなど、複数のライブラリを内部で呼び出しています。
これらの「必要な部品」がすべて揃っていないと、パッケージは正常に動作しません。
なぜ依存関係の管理が必要なのか
依存関係を手動で管理しようとすると、次のような問題が起きます。
- 必要なライブラリのバージョンを1つずつ調べて揃える必要がある
- ライブラリAとライブラリBが要求するバージョンが競合することがある
- 削除するときに、他のパッケージが使っているライブラリを誤って消してしまう
aptのようなパッケージ管理システムは、こうした依存関係の解決を自動で行ってくれます。
apt install nginxを実行したときに、頼んでいないパッケージまで一緒にインストールされるのは、この依存関係の自動解決が働いているからです。
依存関係の仕組みを理解する
インストール時に依存パッケージが自動解決される
実際にaptのインストール時の出力を見てみましょう。
$ sudo apt install nginx
以下の追加パッケージがインストールされます:
libnginx-mod-http-image-filter nginx-common nginx-core
提案パッケージ:
fcgiwrap nginx-doc
以下のパッケージが新たにインストールされます:
libnginx-mod-http-image-filter nginx nginx-common nginx-core
0 個をアップグレード、4 個を新たにインストール
nginx本体だけでなく、nginx-commonやnginx-coreといった関連パッケージが自動で選ばれています。
これはaptがパッケージの依存関係リストを読み取り、必要なものをまとめて計算した結果です。
依存関係を事前に確認する
インストール前に依存関係の内容を知りたい場合は、apt-cache dependsを使います。
$ apt-cache depends nginx
nginx
依存: nginx-core
nginx-full
nginx-light
nginx-extras
推奨: fcgiwrap
「依存」はインストールに必須のパッケージ、「推奨」はあると便利だが必須ではないパッケージを表します。
構成をなるべく最小限にしたいサーバーでは、この違いを見て--no-install-recommendsオプションの利用を検討します。
# 推奨パッケージを含めずにインストールする
$ sudo apt install --no-install-recommends nginx
逆依存を確認する（このパッケージに依存しているものは？）
あるライブラリを削除してよいか判断するときは、「誰がこのパッケージに依存しているか」を先に確認します。
$ apt-cache rdepends libssl3
libssl3
逆依存:
openssh-server
nginx-core
curl
libssl3を削除すると、openssh-server（SSH接続に使うサービス）まで巻き込んで壊れる可能性があることが、この出力から分かります。
リポジトリの仕組み
リポジトリとは何か
リポジトリとは、パッケージが保管されているサーバー（配布元）のことです。
apt installを実行すると、手元のPCやサーバーは直接ソフトを作っているわけではなく、あらかじめ登録されたリポジトリにアクセスしてパッケージを取得しています。
Ubuntuでは、どのリポジトリを使うかの設定が/etc/apt/sources.listと/etc/apt/sources.list.d/以下に記述されています。
$ cat /etc/apt/sources.list
deb http://archive.ubuntu.com/ubuntu noble main restricted
deb http://archive.ubuntu.com/ubuntu noble-updates main restricted
deb http://archive.ubuntu.com/ubuntu noble-security main restricted
apt updateがリポジトリ情報を更新する理由
前回の記事で触れた「apt updateはパッケージそのものではなくリポジトリの一覧を更新するコマンド」という説明は、この仕組みを理解すると腑に落ちます。
apt updateは、sources.listに登録された各リポジトリへ問い合わせて、「今どんなパッケージのどのバージョンが配布されているか」という一覧（パッケージインデックス）だけをローカルにダウンロードします。
実際のパッケージ本体をダウンロードするのは、その後のapt installやapt upgradeのタイミングです。
サードパーティのリポジトリを追加する
公式リポジトリにないソフトを使いたい場合は、リポジトリを追加します。
# 例：Node.jsの公式リポジトリを追加する場合
$ curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
$ sudo apt install nodejs
ただし、リポジトリを追加するということは「そのサーバーの管理者を信頼する」ということでもあります。
出所が不明なリポジトリを安易に追加すると、悪意あるパッケージを実行してしまうリスクがあるため、公式サイトのURLかどうかを必ず確認してください。
よくあるつまずきポイント・エラー対処
依存関係の欠落でインストールが止まる
私が実際に検証環境で古いパッケージファイル（.deb）を個別にダウンロードしてインストールしようとしたとき、次のエラーに遭遇しました。
❌ Before
$ sudo dpkg -i sample-app.deb
dpkg: 依存関係の問題により sample-app の設定ができません:
sample-app は以下に依存 (depends) します: libfoo2 (>= 2.0)
しかし:
パッケージ libfoo2 はまだインストールされていません。
dpkg: パッケージ処理中にエラーが発生しました: sample-app (--install)
dpkgは依存関係を自動解決してくれないため、必要なライブラリを自分で用意しなければならないのが原因でした。
✅ After
# apt --fix-brokenで不足している依存パッケージを自動的に補う
$ sudo apt --fix-broken install
$ sudo dpkg -i sample-app.deb
sample-app (1.2.0) を設定しています ...
apt --fix-broken installを実行すると、不足している依存パッケージを自動で探してインストールし、壊れた状態を修復してくれます。
.debファイルを直接インストールするときは、この一手間を覚えておくとトラブルを避けられます。
リポジトリの署名エラーで更新が失敗する
サードパーティのリポジトリを追加した直後、apt updateで次のエラーに遭遇したこともあります。
❌ Before
$ sudo apt update
W: GPG エラー: https://example.com/repo noble InRelease: 公開鍵が利用できないため、以下の署名を検証できませんでした: NO_PUBKEY A1B2C3D4E5F6
E: リポジトリ https://example.com/repo noble InRelease に署名がありません。
リポジトリの正当性を確認するためのGPG鍵（署名検証用の公開鍵）が登録されていないことが原因でした。
✅ After
# リポジトリが指定する公開鍵を取得して登録する
$ curl -fsSL https://example.com/repo/gpg | sudo gpg --dearmor -o /usr/share/keyrings/example-repo.gpg
$ sudo apt update
ヒット:1 https://example.com/repo noble InRelease
鍵を正しく登録すると署名検証が通り、apt updateが正常に完了しました。
GPG鍵の登録元は、必ずリポジトリの公式ドキュメントに記載されたURLを使ってください。
応用・一歩先の使い方
パッケージのバージョンを固定運用する
依存関係は便利な反面、意図しないタイミングでバージョンが上がり、動作が変わってしまうリスクもあります。
本番サーバーでは、L18で紹介したapt-mark holdと組み合わせて、重要なミドルウェアのバージョンを固定するのが定石です。
$ sudo apt-mark hold nginx
nginx はバージョン固定に設定されました。
依存関係グラフをイメージで確認する
依存関係が複雑なパッケージは、apt-cache dependsだけでは全体像がつかみにくいことがあります。
debtreeのようなツールを使うと、依存関係を図として可視化できます。
$ sudo apt install debtree
$ debtree nginx | dot -Tpng > nginx-deps.png
複雑な依存関係で困ったときの選択肢として覚えておくとよいでしょう。
まとめ
この記事のポイント
- 依存関係とは、パッケージが動作するために必要な他パッケージとのつながり
apt-cache dependsで必要な依存を、apt-cache rdependsで逆依存を確認できる- リポジトリはパッケージの配布元で、
/etc/apt/sources.listなどに登録されている apt updateはリポジトリのパッケージ一覧だけを更新し、本体はinstall/upgrade時に取得される- 依存関係が壊れたときは
apt --fix-broken installで修復できる
次に読むべき記事
- L18「apt・yumでパッケージを管理する基本」で基本コマンドをおさらいする
- L20「SSH接続の基本：リモートサーバーに安全に繋ぐ」でリモートサーバーへの接続方法を学ぶ
- L23「よくあるLinuxエラーとトラブルシューティング」でさらに幅広いエラー対処を確認する