パッケージ管理システム

共有ライブラリの課題

静的ライブラリリンクではなく動的ライブラリ（英語版）リンクに依存するコンピュータシステムでは、パッケージやアプリケーション間で実行可能ライブラリを共有する。これらのシステムでは、異なるバージョンのライブラリを必要とするパッケージ間の競合関係により、俗に「依存関係地獄」と呼ばれる問題が発生する。Microsoft Windowsシステムでは、動的にリンクされたライブラリを使用する場合、これは「DLL地獄」とも呼ばれる。

最新のパッケージ管理システムでは、複数のバージョンのライブラリ（OPENSTEPのFrameworkシステムなど）や、あらゆる種類の依存関係（Portageのスロットなど）、さらには異なるコンパイラバージョンでコンパイルされたパッケージ（安定したABIが存在しないGlasgow Haskell Compilerによって構築された動的ライブラリなど）の並列インストールを許可することで、これらの問題をほぼ解決し、他のパッケージがリンクされたバージョンやインストールされたバージョンを指定できるようにしている。

ローカルでコンパイルされたパッケージのフロントエンド

システムアドミニストレータは、パッケージ管理ソフトウェア以外のツールを使用してソフトウェアをインストールおよび保守する場合がある。たとえば、ローカル管理者がパッケージ化されていないソースコードをダウンロードし、コンパイルしてインストールする場合がある。これにより、ローカルシステムの状態がパッケージ管理システムのデータベースの状態と同期されなくなる可能性がある。ローカル管理者は、一部の依存関係を手動で管理したり、変更をパッケージ管理システムと統合したりするなど、追加の対策を講じる必要がある。

ローカルでコンパイルされたパッケージがパッケージ管理システムに統合されていることを確認するためのツールがある。.debファイルと.rpmファイルベースのディストリビューションやSlackwareにはCheckInstallがあり、Gentoo LinuxなどのレシピベースのシステムやArch Linuxなどのハイブリッドシステムでは、最初にレシピを記述して、パッケージがローカルパッケージデータベースに適合するようにすることができる^[要出典]。

設定のメンテナンス

ソフトウェアのアップグレードで特に厄介なのは、設定ファイルのアップグレードである。少なくともUnixシステムでは、パッケージ管理システムはファイルアーカイバの拡張機能として始まったため、通常は設定ファイルにルールを適用することはできず、設定ファイルを上書きするか保持するかしかできない。ただし、カーネル設定は例外である（カーネル設定が壊れていると、再起動後にコンピューターが使用できなくなる）。設定ファイルの形式が変わると問題が発生する可能性がある。たとえば、古い設定ファイルで無効にすべき新しいオプションが明示的に無効になっていない場合などである。Debianのdpkgなど、一部のパッケージ管理システムでは、インストール中に設定を行うことができる。他の状況では、たとえば多数のコンピュータへのヘッドレスインストールなど、パッケージをデフォルト設定でインストールしてからこの設定を上書きすることが望ましい場合がある。このような事前設定済みインストールも、dpkgによってサポートされている。

リポジトリ

ユーザが自分のシステムにインストールを許可するソフトウェアの種類をより細かく制御できるようにするため（また、ディストリビューター側の法的または利便性上の理由により）、ソフトウェアは多くの場合、複数のソフトウェアリポジトリからダウンロードされる。

アップグレードの抑制

ユーザーがパッケージ管理システムを操作してアップグレードを行う場合、通常、実行するアクションのリスト（通常はアップグレードするパッケージのリストで、場合によっては古いバージョン番号と新しいバージョン番号も表示される）がユーザーに提示され、ユーザーがアップグレードを一括で受け入れるか、アップグレードするパッケージを個別に選択できるようになる。多くのパッケージ管理システムは、特定のパッケージをアップグレードしないように設定したり、ソフトウェアのパッケージ作成者が定義したように、以前のバージョンに重大な脆弱性や不安定性が見つかった場合にのみアップグレードするように設定したりできる。このプロセスは、バージョンピンニング（version pinning）と呼ばれることもある。

例として、以下のようなものがある。

• yumは、構文 exclude=openoffice* でこれをサポートする。
• pacmanは、IgnorePkg=openoffice を使用する（どちらの場合も openoffice のアップグレードを抑制する）。
• dpkgとdselectは、パッケージ選択の hold フラグを通じてこれを部分的にサポートする。
• APTは、複雑なピン留めメカニズムを通じて hold フラグを拡張する（ユーザーはパッケージをブラックリストに登録することもできる）。
• aptitudeには、hold フラグと forbid フラグがある。
• portageは、package.mask 設定ファイルを通じてこれをサポートする。

カスケードパッケージ削除

より高度なパッケージ管理システムの中には「カスケードパッケージ削除（cascading package removal）」を提供するものもあり、対象とするパッケージに依存するすべてのパッケージと、対象パッケージのみが依存するすべてのパッケージが削除される。

コマンドの比較

コマンドはパッケージ管理システムごとに固有であるが、ほとんどのパッケージ管理システムが同様の機能を提供しているため、大部分は翻訳可能である。

Arch Linux wiki Pacman/Rosettaでは広範な概要が提供されている。

実行形式でないもの

以下のパッケージには、インストールされるデータ・依存関係のみが含まれており、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)として採用されている。

実行形式

ソフトウェアのアーカイブにインストール処理を行う仕組みを追加した形式。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の作成が行われる。ソースコードと、コンパイルのために必要なパッケージ（ビルド依存）は、パッケージ管理システムの機能を利用してダウンロードできる場合もある。

Debian系

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 を呼び出し処理する。

Red Hat系

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より標準として採用された。

rPath系

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などでも使える。

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に組み込まれており、様々なリポジトリが存在した。

注釈

1. ↑ APTにおいては、apt updateがパッケージのアップデートを行うコマンドではない。
2. ↑ [パッケージ名]の箇所は省略可能。次項も同様。

出典

1. ↑ “What is a package manager?（パッケージマネージャーとは何ですか？）” (英語). Debian. 2022年2月27日閲覧。
2. ↑ “Debian パッケージ管理システムの基礎”. Debian. p. 7. 2022年2月27日閲覧。
3. ↑ “Software Distribution”. Dell KACE. 2015年10月3日時点のオリジナルよりアーカイブ。2012年7月11日閲覧。
4. ↑ “The history of *nix package management” (2017年8月14日). 2021年10月24日時点のオリジナルよりアーカイブ。2021年10月12日閲覧。
5. ↑ “A review of InfoMagic's December 1994 Release”. 2021年10月29日時点のオリジナルよりアーカイブ。2021年10月12日閲覧。
6. ↑ “The Timeline of Perl and its Culture”. 2013年1月11日時点のオリジナルよりアーカイブ。2021年10月29日閲覧。
7. ↑ Ludovic Courtès, Functional Package Management with Guix Archived 15 May 2020 at the Wayback Machine., June 2013, Madrid, European Lisp Symposium 2013
8. ↑ Tucker, Chris (2007-03-15). “OPIUM: Optimal Package Install/Uninstall Manager”. 29th International Conference on Software Engineering (ICSE'07). UC San Diego. p. 1. 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日閲覧。 
9. ↑ “Linux repository classification schemes”. braintickle.blogspot.com (2006年1月13日). 2007年10月11日時点のオリジナルよりアーカイブ。2008年3月1日閲覧。
10. ↑ “CentOS yum pinning rpms”. centos.org. 2007年11月2日時点のオリジナルよりアーカイブ。2008年3月1日閲覧。
11. 1 2 “pacman(8) Manual Page”. archlinux.org. 2019年8月31日時点のオリジナルよりアーカイブ。2008年3月1日閲覧。
12. ↑ “How to keep specific versions of packages installed (complex)”. debian.org. 2019年11月14日時点のオリジナルよりアーカイブ。2008年3月1日閲覧。
13. ↑ “Apt pinning to blacklist a package”. 2011年7月22日時点のオリジナルよりアーカイブ。2010年8月19日閲覧。
14. ↑ “第8章 Debian パッケージ管理ツール”. Debian. 2022年2月17日閲覧。
15. ↑ “Debian リファレンスカード” (PDF). Debian. 2022年2月17日閲覧。
16. ↑ “YUM/DNF を使用したパッケージ管理”. レッドハット. 2022年2月17日閲覧。 “Red Hat Enterprise Linux 8”
17. ↑ “Managing software with the DNF tool” (英語). レッドハット. 2022年2月17日閲覧。 “Red Hat Enterprise Linux 9-beta”
18. ↑ “brew(1) – The Missing Package Manager for macOS (or Linux)” (英語). Homebrew. 2022年2月17日閲覧。
19. ↑ “nix-env” (英語). NixOS. 2022年2月27日閲覧。
20. ↑ “pacman(8)” (英語). Arch Linux. 2022年2月17日閲覧。
21. ↑ “Zypper package manager” (英語). SUSE. 2022年2月17日閲覧。
22. ↑ “SDB:Zypper manual” (英語). openSUSEプロジェクト. 2022年2月17日閲覧。
23. ↑ “Pacman/Rosetta – ArchWiki” (英語). wiki.archlinux.org. 2016年11月20日時点のオリジナルよりアーカイブ。2017年9月17日閲覧。
24. ↑ 4.4. pkg によるバイナリ package の管理
25. ↑ Part I. pkgsrc 利用者向けの手引き
26. ↑ “Maven Repository: Repositories”. mvnrepository.com. 2025年12月19日閲覧。
27. ↑ “Maven Repository: Central”. mvnrepository.com. 2025年12月19日閲覧。
28. 1 2 “2024 Software Supply Chain Report | Scale of Open Source”. sonatype.com. 2025年12月19日閲覧。
29. ↑ “PowerShell ギャラリー - PowerShell | Microsoft Learn”. 2025年12月19日閲覧。
30. ↑ Alex Crichton (2014年11月20日). “Cargo: Rust's community crate host”. 2018年1月28日閲覧。