この記事の要点

DEB (.deb) は Debian/Ubuntu/Mint など Debian 系 Linux のパッケージ形式 実体は ar アーカイブ + 内部に control.tar.gz（メタ情報）と data.tar.xz（実ファイル） 低レベルツール dpkg -i pkg.deb / 依存解決込みの高レベル apt install ./pkg.deb debian/control でパッケージ名・依存・メンテナを宣言、postinst/prerm でフックスクリプト 署名は SecureApt（リポジトリ Release.gpg の GPG 署名）で検証

要点

• DEB（.deb）は、Debian および Debian 系ディストリビューション（Ubuntu、Linux Mint、Raspberry Pi OS など）で用いられるバイナリパッケージ形式。
• 実体は Unix の ar アーカイブで、内部に debian-binary、control.tar.*、data.tar.* の三つのメンバを持つ。
• 低レベルでは dpkg、高レベル（依存関係解決付き）では apt / apt-get / aptitude が扱う。
• 厳密なメタデータ（control）と依存関係グラフによって、システム全体の整合性を保つ仕組みが組み込まれている。

概要

DEB は 1993 年に Ian Murdock が始めた Debian プロジェクトとともに整備された、Linux 黎明期から続くソフトウェア配布の標準形式のひとつである。Ubuntu の急速な普及により、現在では世界で最も広く使われているパッケージ形式と言ってもよい。

DEB ファイルは「ソフトウェア本体のファイル群」と「インストールに必要なメタデータ・スクリプト」を一つのアーカイブにまとめたものであり、対応するパッケージマネージャに渡せば、配置先のパス、所有者、パーミッション、依存パッケージの解決まで自動で行われる。

同種の形式である RPM（.rpm） と比較されることが多いが、設計思想・ツール体系ともに大きく異なる。詳細は「関連形式との比較」で扱う。

内部構造

DEB は Unix ar アーカイブであり、file コマンドで見ると Debian binary package (format 2.0) と表示される。ar t package.deb で内容を一覧でき、典型的には次の三つのメンバが含まれる。

• debian-binary — フォーマットバージョン（通常は 2.0）を書いたテキストファイル
• control.tar.{gz,xz,zst} — メタデータ群。control（パッケージ名・バージョン・依存・説明）、md5sums、preinst / postinst / prerm / postrm（インストール前後・削除前後に走るシェルスクリプト）など
• data.tar.{gz,xz,zst} — 実際にシステムへ展開されるファイル群（/usr/bin/、/usr/share/ などのパスを含むディレクトリツリー）

control ファイルの中身は RFC 822 風の「キー: 値」形式で、次のようなフィールドを持つ。

Package: hello
Version: 2.10-2
Architecture: amd64
Maintainer: Example <dev@example.org>
Depends: libc6 (>= 2.34)
Description: The GNU Hello program
 produces a familiar, friendly greeting.

圧縮アルゴリズムは時代とともに gzip → xz → zstd と移ってきており、Debian 12 / Ubuntu 24.04 では zstd の採用が広がっている。

主な用途

• OS 標準ソフトウェアの配布 — apt リポジトリにある数万のパッケージはすべて DEB 形式。
• サードパーティ製アプリの配布 — Google Chrome、Slack、VS Code、Zoom などはベンダーが .deb を直接配布している。
• 自社製品のインストーラ — 業務システム、エージェント、ドライバなど、Debian/Ubuntu サーバへ配布するための公式手段。
• 独自リポジトリ運用 — reprepro や aptly でプライベート apt リポジトリを構築し、CI で生成した .deb を配信する運用が広く行われている。

関連形式との比較

• vs RPM — RPM が cpio + ヘッダ構造なのに対し、DEB は ar + 二つの tar というシンプルな入れ子。メタデータ形式も RPM は専用バイナリヘッダ、DEB はテキスト。dpkg と rpm でデータベースの持ち方も異なる（dpkg は /var/lib/dpkg/status のテキスト DB）。
• vs AppImage — AppImage は 1 ファイル完結でディストリ非依存、システムへの統合は最小限。DEB はシステムに「インストール」する形式で、依存関係を OS と共有する。
• vs Snap / Flatpak — Snap / Flatpak はサンドボックス化された配布形式。DEB はサンドボックスなしで、システム全体の信頼境界に入る。
• vs アーカイブ・圧縮形式 — 単なる tar.xz と異なり、DEB はメタデータ + ライフサイクルスクリプトを内包する点が決定的に違う。

コマンド・ツール

• dpkg -i package.deb — 単一の .deb をインストール（依存は解決しない）
• dpkg -I package.deb — control 情報の表示
• dpkg -c package.deb — 含まれるファイル一覧
• dpkg -L <pkg> — インストール済みパッケージのファイル一覧
• dpkg -S /path/to/file — どのパッケージに属するか逆引き
• apt install ./package.deb — 依存解決込みでローカル .deb をインストール（apt 1.1 以降）
• apt-get update / upgrade / install — リポジトリ経由の通常運用
• dpkg-deb -b builddir package.deb — ディレクトリから .deb を組み立てる（個人ビルド用）
• debuild / dpkg-buildpackage — 公式ルールに従って .deb を生成する（メンテナ向け）
• lintian package.deb — Debian Policy への準拠を機械チェック

注意点

• 依存地獄を避ける。dpkg -i だけだと依存が落ちて壊れた状態になりうる。apt -f install で復旧する流れを覚えておくと安心。
• ディストリビューションとアーキテクチャの一致。Ubuntu 22.04 用 .deb を 18.04 へ入れると glibc バージョンの違いでクラッシュすることがある。amd64 / arm64 / armhf の取り違えにも注意。
• postinst スクリプトはルート権限で走る。アーカイブ・圧縮形式と違って、信頼できる配布元からのみインストールすること。ベンダー配布の .deb は必ず公式サイト・公式 GPG 鍵で署名検証する。
• サードパーティリポジトリの放置に注意。/etc/apt/sources.list.d/ に追加した古い PPA がディストリアップグレード時に競合を起こすことがあるので、不要になったら削除する。
• ファイル名規約は <name>_<version>_<arch>.deb。アンダースコア区切りであり、ハイフン区切りの RPM と紛らわしいので注意。

関連リンク

• 実行ファイル・パッケージ（親カテゴリ）
• ファイル拡張子とは（概論）
• RPM（.rpm）（Red Hat 系の対抗形式）
• AppImage（.appimage）（Linux ポータブル配布）
• EXE（.exe）（Windows 実行ファイル）
• DMG（.dmg）（macOS 配布イメージ）
• アーカイブ・圧縮形式（tar / xz / zstd を内部で利用）