Synaptic - APT パッケージ管理システムのGUI
パッケージ管理システム （パッケージかんりシステム、英 : package management system ）、またはパッケージマネージャ （英 : package manager ）とは、コンピュータプログラム のインストール 、アップグレード、設定、アンインストール のプロセスを一貫した方法で自動化するシステムである[ 1] [ 2]
パッケージ管理システムはパッケージ を扱う。これは、ソフトウェアやデータをアーカイブ 化したものである。パッケージには、ソフトウェアの名前、説明、バージョン番号 、ベンダー 、チェックサム （暗号学的ハッシュ関数 が望ましい）、ソフトウェアが適切に実行されるために必要な依存関係のリストなどのメタデータ が含まれる。インストール時に、メタデータはローカルパッケージデータベースに保存される。パッケージ管理システムは通常、ソフトウェアの不一致や前提条件の不足を防ぐために、依存関係とバージョン情報のデータベースを保持する。パッケージ管理システムは、ソフトウェアリポジトリ 、バイナリリポジトリマネージャー、およびアプリケーションストア と密接に連携する。
パッケージ管理システムは、手動でのインストールやアップグレードの必要性を排除するように設計されている。通常、数百あるいは数万の個別のソフトウェアパッケージで構成されるオペレーティングシステム を持つ大企業にとって、これは特に便利である[ 3]
初期のパッケージ管理システムとして、IBM AIX のSMIT （およびそのバックエンドinstallp）があった。SMITは1989年にAIX 3.0で導入された[要出典 。
1994年頃の初期のパッケージ管理システムには自動で依存関係を解決する機能はなかったが[ 4] [ 5]
1995年頃、CPAN に始まり、パッケージ管理システムはリポジトリからパッケージをダウンロードし、その依存関係を自動的に解決することで必要に応じてインストールすることができるようになり、ソフトウェアのインストールやアンインストール、更新がはるかに簡単になった[ 6]
ソフトウェアパッケージは、コンピュータプログラムとそのデプロイ に必要なメタデータ を含むアーカイブファイル である。コンピュータプログラムは、最初にコンパイル してビルド する必要があるソースコード である場合がある[ 7]
パッケージ管理システムは、ユーザーのコマンドに応じてソフトウェアパッケージを検索、インストール、保守、またはアンインストールする。パッケージ管理システムの一般的な機能は次のとおりである。
静的ライブラリ リンクではなく動的ライブラリ（英語版 ） リンクに依存するコンピュータシステムでは、パッケージやアプリケーション間で実行可能ライブラリを共有する。これらのシステムでは、異なるバージョンのライブラリを必要とするパッケージ間の競合関係により、俗に「依存関係地獄 」と呼ばれる問題が発生する。Microsoft Windows システムでは、動的にリンクされたライブラリを使用する場合、これは「DLL地獄 」とも呼ばれる[ 8]
最新のパッケージ管理システムでは、複数のバージョンのライブラリ（OPENSTEP のFrameworkシステムなど）や、あらゆる種類の依存関係（Portage のスロットなど）、さらには異なるコンパイラバージョンでコンパイルされたパッケージ（安定したABI が存在しないGlasgow Haskell Compiler によって構築された動的ライブラリなど）の並列インストールを許可することで、これらの問題をほぼ解決し、他のパッケージがリンクされたバージョンやインストールされたバージョンを指定できるようにしている。
システムアドミニストレータ は、パッケージ管理ソフトウェア以外のツールを使用してソフトウェアをインストールおよび保守する場合がある。たとえば、ローカル管理者がパッケージ化されていないソースコードをダウンロードし、コンパイルしてインストールする場合がある。これにより、ローカルシステムの状態がパッケージ管理システムのデータベースの状態と同期 されなくなる可能性がある。ローカル管理者は、一部の依存関係を手動で管理したり、変更をパッケージ管理システムと統合したりするなど、追加の対策を講じる必要がある。
ローカルでコンパイルされたパッケージがパッケージ管理システムに統合されていることを確認するためのツールがある。.deb ファイルと.rpm ファイルベースのディストリビューションやSlackware にはCheckInstall があり、Gentoo Linux などのレシピベースのシステムやArch Linux などのハイブリッドシステムでは、最初にレシピを記述して、パッケージがローカルパッケージデータベースに適合するようにすることができる[要出典 。
ソフトウェアのアップグレードで特に厄介なのは、設定ファイル のアップグレードである。少なくともUnix システムでは、パッケージ管理システムはファイルアーカイバ の拡張機能として始まったため、通常は設定ファイルにルールを適用することはできず、設定ファイルを上書きするか保持するかしかできない。ただし、カーネル設定は例外である（カーネル設定が壊れていると、再起動後にコンピューターが使用できなくなる）。設定ファイルの形式が変わると問題が発生する可能性がある。たとえば、古い設定ファイルで無効にすべき新しいオプションが明示的に無効になっていない場合などである。Debian のdpkg など、一部のパッケージ管理システムでは、インストール中に設定を行うことができる。他の状況では、たとえば多数のコンピュータへのヘッドレス インストールなど、パッケージをデフォルト設定でインストールしてからこの設定を上書きすることが望ましい場合がある。このような事前設定済みインストールも、dpkgによってサポートされている。
ユーザが自分のシステムにインストールを許可するソフトウェアの種類をより細かく制御できるようにするため（また、ディストリビューター側の法的または利便性上の理由により）、ソフトウェアは多くの場合、複数のソフトウェアリポジトリ からダウンロードされる[ 9]
ユーザーがパッケージ管理システムを操作してアップグレードを行う場合、通常、実行するアクションのリスト（通常はアップグレードするパッケージのリストで、場合によっては古いバージョン番号と新しいバージョン番号も表示される）がユーザーに提示され、ユーザーがアップグレードを一括で受け入れるか、アップグレードするパッケージを個別に選択できるようになる。多くのパッケージ管理システムは、特定のパッケージをアップグレードしないように設定したり、ソフトウェアのパッケージ作成者が定義したように、以前のバージョンに重大な脆弱性や不安定性が見つかった場合にのみアップグレードするように設定したりできる。このプロセスは、バージョンピンニング（version pinning）と呼ばれることもある。
例として、以下のようなものがある。
yum は、構文 exclude=openoffice* でこれをサポートする[ 10] pacman は、IgnorePkg=openoffice を使用する[ 11] dpkg とdselectは、パッケージ選択の hold フラグを通じてこれを部分的にサポートする。APT は、複雑なピン留めメカニズムを通じて hold フラグを拡張する[ 12] [ 13] aptitude には、hold フラグと forbid フラグがある。portage は、package.mask 設定ファイルを通じてこれをサポートする。
より高度なパッケージ管理システムの中には「カスケードパッケージ削除（cascading package removal）」を提供するものもあり[ 11]
コマンドはパッケージ管理システムごとに固有であるが、ほとんどのパッケージ管理システムが同様の機能を提供しているため、大部分は翻訳可能である。
基本的なコマンド比較（OSのパッケージ管理システムのみ）
ツール
インストール
アップデート
アンインストール
APT[ 14] [ 15]
apt install <パッケージ名> apt upgrade [ パッケージ名] [ 注釈 1] [ 注釈 2] apt remove <パッケージ名>
DNF / yum[ 16] [ 17]
dnf install <パッケージ名> dnf update [ パッケージ名] dnf remove <パッケージ名>
Homebrew[ 18]
brew install <パッケージ名> brew update brew remove <パッケージ名>
Nix[ 19]
nix-env -i <パッケージ名> nix-env -u [ パッケージ名] nix-env -e <パッケージ名>
Pacman[ 20]
pacman -S <パッケージ名> pacman -Syu pacman -R <パッケージ名>
ZYpp[ 21] [ 22]
zypper install <パッケージ名> zypper update [ パッケージ名] zypper remove <パッケージ名>
Arch Linux wiki Pacman/Rosettaでは広範な概要が提供されている[ 23]
OSになんらかのソフトウェアを追加インストールする場合には、ソフトウェアに関係するファイル一式をまとめた「パッケージ」が利用される。パッケージの形式は複数あるが、利用される形式はOSによって限定されることが多い。
以下のパッケージには、インストールされるデータ・依存関係のみが含まれており、OSに搭載されているパッケージ管理システムを用いることでインストールできる。
RPM 形式パッケージ
Red Hat Linux 用に開発されたパッケージ形式。Red Hat Enterprise Linux のほかTurbolinux やVine Linux 等でも利用される。
deb 形式パッケージ
Debian 用に開発されたパッケージ形式。dpkg やAPT を用いてインストール・管理される。
ports（英語版 ） 形式パッケージ
FreeBSD で利用されるパッケージ形式。
pkg形式パッケージ
Solaris で利用されるパッケージ形式。FreeBSD 10.0でも、以前はpkgngと呼ばれていた形式がpkg(8)として採用されている[ 24]
ソフトウェアのアーカイブにインストール処理を行う仕組みを追加した形式。Mac OS やWindows でよく使われ、Linuxディストリビューション 向けのソフトウェアでも稀に利用される。依存関係の解決・インストールは、パッケージが独自に行う。
InstallShield ベースのパッケージ
InstallShieldは、Windows をはじめ、macOS やLinux 等のPC-UNIX 向けのインストーラーを作成できる。
シェルスクリプト ベースのパッケージ
主にBash で書かれ、複数のディストリビューションを対象としたLinux向けのプロプライエタリソフトウェア に用いられる形式。
この他、ソフトウェアのソースコードがアーカイブされたパッケージも存在する。LinuxやFreeBSD等を含むUnix系 OS等では、おもにtar.gz 形式やtar.bz2 形式などで配布されている。利用者は対象とするPC環境に合わせて構成やコンパイル 等の作業を行った上でインストールする。多くの場合、Autotools によって作成された「configure」という名前のシェルスクリプトが付属しており、これを実行することでその環境における依存関係の確認や、コンパイルのためのMakefile の作成が行われる。ソースコードと、コンパイルのために必要なパッケージ（ビルド依存）は、パッケージ管理システムの機能を利用してダウンロードできる場合もある。
パッケージ管理システムの自動更新機能。
dpkg
deb形式パッケージを対象としたDebian GNU/Linuxで開発されたツール。
APT
deb形式を対象として開発された、dpkgの高機能フロントエンド。apt-getやapt-cache等の複数のコマンドから成る。配布パッケージの自動入手先として、インターネット 、LAN 、CD-ROM 等をapt-lineとして複数指定することができる。追加インストールのほか、導入済パッケージのアップデート作業も自動処理できる。Debianから派生したディストリビューションでは、それぞれ個別のapt-lineを用意していることが多い。
aptitude
TUI 上で動くメニュー形式のツール。内部的にAPTを呼び出す仕組みで、DebianのOSインストール中にも、aptitudeが呼び出されるようになっている。
synaptic
GUI(X Window System )上で動くメニュー形式のツール。内部的にAPTを呼び出し処理する。
apt-watch / update-manager
GUI上で動く、自動更新アプレット。レッドハット のパッケージ管理ツールである RHN と類似した機能を有することが特徴である。内部的に APT を呼び出し処理する。
RPM
rpm形式パッケージを対象とした Red Hat Linux で開発されたツール。単純なインストールのほか、src.rpm形式やnosrc.rpm形式 + ソースアーカイブなどを使って、ソースからのリビルドを行いrpmパッケージを生成する機能もある。以下のパッケージ管理ツールはいずれも RPM を置き換えるものではなく、RPMをバックエンドとして利用し、より高度な機能を提供している。
apt-rpm、aptitude、synaptic
本来deb形式対応のこれらのツールは RPM 対応版が作成され、Fedora や Vine Linux 等で利用されている。
TurboPackage
rpm形式パッケージを対象としたTurbolinuxで開発されたツール。
up2date
rpm 形式パッケージを対象にしたレッドハットのパッケージ管理ツール。同社のRed Hat Enterprise Linux （バージョン4まで）で採用されている。Fedora の古いバージョンでも採用されていた。
Yum
rpm 形式パッケージを対象としたYellow Dog Linux で開発されたツール。Red Hat Enterprise LinuxやCentOS などで標準として採用されている。Fedoraではバージョン21まで標準で採用されていた。
DNF
rpm 形式パッケージを対象としたYumからフォーク して開発されたツール。Fedoraではバージョン22より標準として採用された。
Conary
Conary はForesight Linux やrPath Linuxにより採用され、RPM、CVS 、Portage などの優れた点を集め、さらにいくつか優れた機能を追加し、明解なリビジョン・コントロールを行う先進的な次世代パッケージ管理システムである。Conary はアップデートされる必要があるパッケージにおいて、特定のファイルのみをアップデートするので、RPMやdebなどパッケージ全体がダウンロードされる他のフォーマットよりも効率的である。
Gentoo Linux
Gentoo Linux では原則として、ソフトウェアをソースコードからコンパイルしてインストールするようになっている。そのため、最適化された効率的で高速なシステムを構築可能である。しかし、コンパイルするために多くの時間と演算処理を要する。
インストールするソフトウェア自体は公式のものかミラーサイト からダウンロードするため、Gentoo Linuxにおけるパッケージの本体部分は、インストール手順が書かれたBash スクリプト である。
Mozilla Firefox やLibreOffice などはコンパイルに時間がかかるため、バイナリ パッケージも用意されている。Adobe Flash やGoogle Chrome などのプロプライエタリソフトウェア も、公式に配布されているバイナリファイルをダウンロードしてインストールすることが可能なようになっている。
Gentoo Linuxのパッケージ管理システムは当初はPortage のみであったが、現在では規格として標準化されているため、承認されたパッケージ管理システムが複数あり、そのいずれかを使用することになる。
Portage
Gentoo Linuxのデフォルトのパッケージ管理システムである。プログラミング言語にはスクリプト言語 であるPython を採用して書かれている。FreeBSDのportsに着想を得て開発された。Gentoo Linuxの他にも、FreeBSDやmacOSにも移植されている。
Paludis
Gentoo Linuxから派生したディストリビューションであるExherbo Linuxのパッケージ管理システムであり、Gentoo Linuxでも使用可能になっている。プログラミング言語には主にC++ が用いられている。
pkgcore
Portageと互換性が高くこれに代替しうる、より効率的なパッケージ管理システムを目指してつくられた。主にPythonで書かれている。
openSUSE
YaST
rpm 形式パッケージを対象としたSuSE Linux で開発されたツール。YaSTは単なるパッケージ管理ツールではなく、統合的なシステム管理ツールである。
ZYpp
充足可能性問題 の解決に焦点を当てて開発されたパッケージ管理システム。
Slackware
pkgtool
Slackware 標準のパッケージ管理ツール。APTやYumと比較して極めてシンプルなツールであり、バージョン管理は行えない。
slackpkg
Slackwareで使用できるパッケージ管理ツール。標準ではインストールされない。Slackware標準パッケージしか扱えないものの、インストールすればAPTやYumのようなバージョン管理をSlackwareで実現することができる。
sbopkg
Slackware用リポジトリ、SlackBuilds.org用のパッケージ管理ツール。上記のとおり、slackpkgではサードパーティー パッケージを扱えないため、独自に提供されている。
Arch Linux
pacman
Arch Linux 向けに開発されたパッケージ管理ツール。コンパイル済みバイナリとパッケージ情報を含んだ独自の.pkg.tar.zstフォーマットを用いる。プログラミング言語はC が用いられている。
nix
Debian、openSUSE 、Fedora等多数のディストリビューションに対応した環境非依存型パッケージ管理ツール。既存環境の依存関係に関わりなくサードパーティー製ソフトウェアをインストールできるうえ、旧来のパッケージ管理ツールでは実現できなかった同一ソフトウェアの複数バージョン共存が実現できる。
Snap
カノニカル による、サンドボックス 技術を利用したディストリビューション非依存なパッケージ管理ツールおよびシステム。クラウドやIoTでも利用でき、複数バージョンの共存やAppArmor を使ったアクセス制限も可能。Ubuntu で標準で利用できるが他の多くのディストリビューションで利用できる。
Flatpak
GNOME 発の技術で、freedesktop.org のプロジェクトとして開発されている、サンドボックス技術を利用したディストリビューション非依存なパッケージ管理ツールおよびシステム。上記2種と同様に複数バージョンの共存が可能。Snapと違いデスクトップアプリケーション専用で、主要ディストリビューションで利用可。
FreeBSD
ports（英語版 ）
原則的にソースをコンパイルしてインストールするようになっている。このため、PCごとに命令 レベルで最適化された、処理効率として無駄の少ない環境を構築できる。ただし、インストールに長時間かかる。バイナリで用意されたパッケージをpkg(8)によりインストールすることもできる。ソースをコンパイルしたものとバイナリでインストールしたものとは単一のデータベースで統一管理されるようになっているため、それぞれのパッケージの性格に応じてソースからのコンパイルとバイナリインストールとを選択することが可能である。詳細はFreeBSD およびFreeBSD Ports（英語版 ） を参照。
NetBSD
pkgsrc
原則的にソースをコンパイルしてインストールするようになっている。このため、PCごとに最適化された、無駄の少ない環境を構築できる。ただし、インストールに長時間かかる。また、OS/CPU には依存せず、NetBSD 以外にもLinuxやmacOS、Solarisなどでも使える[ 25]
macOS
macOS には、MacPorts 、Fink 、Homebrew などがある。
Windows
Windowsパッケージマネージャー
マイクロソフトが開発しているWindows公式のパッケージ管理ツール。Windows 10以降およびWindows Server 2025以降に標準搭載されている。フリーかつオープンソースである。winget の名で知られる。
Chocolatey
Windows向けのパッケージ管理ツール。.NET 向けパッケージ管理システムNuGet のパッケージインフラを利用している。
Scoop
Windows向けのパッケージ管理ツール。
Mingw-w64
Windows上で動作するUnix系 アプリのディストリビューション。pacman を使用している。
Cygwin
Windows上で動作するUnix系 アプリのディストリビューション。
PackageManagement
かつてマイクロソフトが開発していたパッケージ管理ツール。PowerShell 5.0に組み込まれており、様々なリポジトリが存在した。
プログラミング言語においては、プログラムのソースコードを管理するために、パッケージ管理システムが使われる。その性質から多くがソースコード形式で管理・配布されているが、.NETやJavaなどはコンパイル済みで配布している。
^ APTにおいては、apt updateがパッケージのアップデートを行うコマンドではない。 ^ [パッケージ名]の箇所は省略可能。次項も同様。
^ “What is a package manager?（パッケージマネージャーとは何ですか？） ” (英語). Debian . 2022年2月27日閲覧。 ^ “Debian パッケージ管理システムの基礎 ”. Debian . p. 7. 2022年2月27日閲覧。 ^ “Software Distribution ”. Dell KACE. 2015年10月3日時点のオリジナル よりアーカイブ。2012年7月11日閲覧。 ^ “The history of *nix package management ” (2017年8月14日). 2021年10月24日時点のオリジナルよりアーカイブ 。2021年10月12日閲覧。 ^ “A review of InfoMagic's December 1994 Release ”. 2021年10月29日時点のオリジナルよりアーカイブ 。2021年10月12日閲覧。 ^ “The Timeline of Perl and its Culture ”. 2013年1月11日時点のオリジナルよりアーカイブ 。2021年10月29日閲覧。 ^ Ludovic Courtès, Functional Package Management with Guix Archived 15 May 2020 at the Wayback Machine ., June 2013, Madrid, European Lisp Symposium 2013 ^ Tucker, Chris (2007-03-15). “OPIUM: Optimal Package Install/Uninstall Manager” . 29th International Conference on Software Engineering (ICSE'07) doi :10.1109/ICSE.2007.59 . ISBN 978-0-7695-2828-1 . オリジナル の2011-06-14時点におけるアーカイブ。. http://cseweb.ucsd.edu/~lerner/papers/opium.pdf 2011年9月14日閲覧。 ^ “Linux repository classification schemes ”. braintickle.blogspot.com (2006年1月13日). 2007年10月11日時点のオリジナルよりアーカイブ 。2008年3月1日閲覧。 ^ “CentOS yum pinning rpms ”. centos.org. 2007年11月2日時点のオリジナルよりアーカイブ。2008年3月1日閲覧。 ^ a b “pacman(8) Manual Page ”. archlinux.org . 2019年8月31日時点のオリジナルよりアーカイブ 。2008年3月1日閲覧。
^ “How to keep specific versions of packages installed (complex) ”. debian.org. 2019年11月14日時点のオリジナル よりアーカイブ。2008年3月1日閲覧。 ^ “Apt pinning to blacklist a package ”. 2011年7月22日時点のオリジナル よりアーカイブ。2010年8月19日閲覧。 ^ “第8章 Debian パッケージ管理ツール ”. Debian . 2022年2月17日閲覧。 ^ “Debian リファレンスカード ” (PDF). Debian . 2022年2月17日閲覧。 ^ “YUM/DNF を使用したパッケージ管理 ”. レッドハット . 2022年2月17日閲覧。 “Red Hat Enterprise Linux 8” ^ “Managing software with the DNF tool ” (英語). レッドハット . 2022年2月17日閲覧。 “Red Hat Enterprise Linux 9-beta” ^ “brew(1) – The Missing Package Manager for macOS (or Linux) ” (英語). Homebrew ^ “nix-env ” (英語). NixOS . 2022年2月27日閲覧。 ^ “pacman(8) ” (英語). Arch Linux ^ “Zypper package manager ” (英語). SUSE . 2022年2月17日閲覧。 ^ “SDB:Zypper manual ” (英語). openSUSEプロジェクト ^ “Pacman/Rosetta – ArchWiki ” (英語). wiki.archlinux.org . 2016年11月20日時点のオリジナルよりアーカイブ 。2017年9月17日閲覧。 ^ 4.4. pkg によるバイナリ package の管理 ^ Part I. pkgsrc 利用者向けの手引き ^ “Maven Repository: Repositories ”. mvnrepository.com . 2025年12月19日閲覧。 ^ “Maven Repository: Central ”. mvnrepository.com . 2025年12月19日閲覧。 ^ a b “2024 Software Supply Chain Report | Scale of Open Source ”. sonatype.com . 2025年12月19日閲覧。
^ “PowerShell ギャラリー - PowerShell | Microsoft Learn ”. 2025年12月19日閲覧。 ^ Alex Crichton (2014年11月20日). “Cargo: Rust's community crate host ”. 2018年1月28日閲覧。
dpkg
RPM
組み込みシステム
ディストリビューション非依存
その他（バイナリ）
その他（ソース）
フロントエンド
関連項目
