Loading article…
パッケージマネージャーまたはパッケージ管理システムは、コンピュータプログラムのインストール、アップグレード、構成、削除のプロセスを一貫した方法で自動化するソフトウェアツールのコレクションです。[1]
パッケージ マネージャーは、パッケージ、ソフトウェアの配布、およびアーカイブ ファイル内のデータを処理します。パッケージには、ソフトウェアの名前、目的の説明、バージョン番号、ベンダー、チェックサム(暗号化ハッシュ関数が望ましい)、ソフトウェアが適切に実行されるために必要な依存関係のリストなどのメタデータが含まれます。インストール時に、メタデータはローカル パッケージ データベースに保存されます。パッケージ マネージャーは通常、ソフトウェアの不一致や前提条件の不足を防ぐために、ソフトウェアの依存関係とバージョン情報のデータベースを維持します。パッケージ マネージャーは、ソフトウェア リポジトリ、バイナリ リポジトリ マネージャー、およびアプリ ストアと密接に連携します。
パッケージマネージャは、手動でのインストールや更新の必要性を排除するように設計されています。これは、オペレーティングシステムが通常数百、あるいは数万の個別のソフトウェアパッケージで構成されている大企業にとって特に便利です。[2]
歴史
初期のパッケージ マネージャーは、IBM AIXの SMIT (およびそのバックエンド installp) でした。SMITは1989 年に AIX 3.0 で導入されました。[引用が必要]
1994年頃の初期のパッケージマネージャには依存関係の自動解決機能はありませんでしたが[3]、実行中のシステムへのソフトウェアの追加と削除のプロセスを大幅に簡素化できました[4] 。
1995年頃、CPANに始まり、パッケージマネージャはリポジトリからパッケージをダウンロードし、その依存関係を自動的に解決して必要に応じてインストールする作業を開始し、システムからのソフトウェアのインストール、アンインストール、更新がはるかに簡単になりました。[5]
機能
ソフトウェアパッケージは、コンピュータプログラムとその展開に必要なメタデータを含むアーカイブファイルです。コンピュータプログラムは、最初にコンパイルおよびビルドする必要があるソースコードである場合があります。 [6]パッケージメタデータには、パッケージの説明、パッケージのバージョン、依存関係（事前にインストールする必要がある他のパッケージ）が含まれます。
パッケージ マネージャーは、ユーザーのコマンドに応じてソフトウェア パッケージを検索、インストール、保守、またはアンインストールするタスクを担当します。パッケージ管理システムの一般的な機能は次のとおりです。
- ファイルアーカイバを使用してパッケージアーカイブを抽出する
- チェックサムとデジタル証明書を検証することで、パッケージの整合性と信頼性を確保する
- ソフトウェアリポジトリまたはアプリストアから既存のソフトウェアを検索、ダウンロード、インストール、または更新する
- ユーザーの混乱を減らすためにパッケージを機能別にグループ化する
- 依存関係を管理して、パッケージに必要なすべてのパッケージがインストールされるようにし、「依存関係地獄」を回避します。
共有ライブラリの課題
静的ライブラリリンクではなく動的ライブラリリンクに依存するコンピュータ システムでは、パッケージやアプリケーション間でマシン命令の実行可能ライブラリを共有します。これらのシステムでは、異なるバージョンのライブラリを必要とする異なるパッケージ間の競合関係により、俗に「依存関係地獄」と呼ばれる問題が発生します。Microsoft Windowsシステムでは、動的にリンクされたライブラリを使用する場合、これは「 DLL 地獄」とも呼ばれます。 [7]
現代のパッケージ マネージャーは、複数のバージョンのライブラリ ( OPENSTEPのFrameworkシステムなど)、あらゆる種類の依存関係 ( Gentoo Portageのスロットなど)、さらには異なるコンパイラ バージョンでコンパイルされたパッケージ (安定したABIが存在しないGlasgow Haskell Compilerによってビルドされた動的ライブラリなど) の並列インストールを許可することで、これらの問題をほぼ解決しています。これにより、他のパッケージがリンクされたバージョンやインストールされたバージョンを指定できるようになります。
ローカルにコンパイルされたパッケージのフロントエンド
システム管理者は、パッケージ管理ソフトウェア以外のツールを使用してソフトウェアをインストールおよび保守する場合があります。たとえば、ローカル管理者がパッケージ化されていないソースコードをダウンロードし、コンパイルしてインストールする場合があります。これにより、ローカルシステムの状態がパッケージマネージャーのデータベースの状態と同期されなくなる可能性があります。ローカル管理者は、一部の依存関係を手動で管理したり、変更をパッケージマネージャーに統合したりするなど、追加の対策を講じる必要があります。
ローカルでコンパイルされたパッケージがパッケージ管理に統合されていることを保証するツールがあります。.deb および.rpmファイルに基づくディストリビューションや Slackware Linux の場合はCheckInstallがあり、Gentoo LinuxなどのレシピベースのシステムやArch Linuxなどのハイブリッド システムの場合は、最初にレシピを記述して、パッケージがローカル パッケージ データベースに適合していることを確認できます。[引用が必要]
構成のメンテナンス
ソフトウェアのアップグレードで特に厄介なのは、設定ファイルのアップグレードです。少なくとも Unix システムでは、パッケージ マネージャーはファイル アーカイブ ユーティリティの拡張機能として始まったため、通常は設定ファイルにルールを適用するのではなく、設定ファイルを上書きするか保持するかのどちらかしかできません。これには例外があり、通常はカーネル設定に当てはまります (カーネル設定が壊れていると、再起動後にコンピューターが使用できなくなります)。設定ファイルの形式が変わると、たとえば古い設定ファイルで無効にすべき新しいオプションが明示的に無効になっていない場合など、問題が発生する可能性があります。Debianのdpkgなど、一部のパッケージ マネージャーでは、インストール中に設定を行うことができます。他の状況では、たとえば多数のコンピューターへのヘッドレスインストールなど、パッケージをデフォルト設定でインストールし、その後この設定を上書きすることが望ましい場合があります。このような事前構成済みのインストールも、dpkg によってサポートされています。
リポジトリ
ユーザーが自分のシステムにインストールを許可するソフトウェアの種類をより細かく制御できるようにするため（また、場合によっては配布者側の法的または利便性上の理由により）、ソフトウェアは多くの場合、複数のソフトウェアリポジトリからダウンロードされます。[8]
アップグレード抑制
ユーザーがパッケージ管理ソフトウェアを操作してアップグレードを行う場合、通常、実行するアクションのリスト (通常はアップグレードするパッケージのリストで、場合によっては古いバージョン番号と新しいバージョン番号も表示されます) がユーザーに提示され、ユーザーがアップグレードを一括で受け入れるか、アップグレードするパッケージを個別に選択できるようになります。多くのパッケージ マネージャーは、特定のパッケージをアップグレードしないように設定したり、ソフトウェアのパッケージ作成者が定義したように、以前のバージョンに重大な脆弱性や不安定性が見つかった場合にのみアップグレードするように設定したりできます。このプロセスは、バージョン ピンニングと呼ばれることもあります。
例えば：
- yumはexclude=openoffice*という構文でこれをサポートしています[9]
- pacman with IgnorePkg= openoffice [10] (どちらの場合もopenofficeのアップグレードを抑制する)
- dpkgとdselectはパッケージ選択のホールドフラグを通じてこれを部分的にサポートしています。
- APTは複雑な「ピン留め」メカニズムを通じてホールドフラグを拡張します[11]（ユーザーはパッケージをブラックリストに登録することもできます[12]）
- aptitudeには「hold」と「forbid」のフラグがある
- portageはpackage.mask設定ファイルを通じてこれをサポートしています
カスケードパッケージ削除
より高度なパッケージ管理機能の中には、「カスケードパッケージ削除」[10]と呼ばれる機能があり、ターゲットパッケージに依存するすべてのパッケージと、ターゲットパッケージのみが依存するすべてのパッケージも削除されます。
コマンドの比較
コマンドはパッケージ マネージャーごとに固有ですが、ほとんどのパッケージ マネージャーが同様の機能を提供するため、大部分は翻訳可能です。
Arch Linux Pacman/Rosetta wikiでは詳細な概要が提供されています。[16]
有病率
dpkgのようなパッケージマネージャは1994年にすでに存在していました。[17]
バイナリ パッケージ向けのLinux ディストリビューションは、ソフトウェアの管理と保守の主な手段としてパッケージ管理システムに大きく依存しています。Android (Linux ベース)、iOS ( Unix ベース)、Windows Phoneなどのモバイル オペレーティング システムは、それぞれのベンダーのアプリ ストアにほぼ全面的に依存しているため、専用のパッケージ管理システムを使用しています。
-
-
Aptitude にはTUIも搭載されています。 -
Synaptic、多くの Linux パッケージ マネージャー用の GUI
-
pacman、Archベースのディストリビューション用のCLIユーティリティ -
Octopi、Pacman パッケージ マネージャー用のQt GUI -
Pamac、Pacman パッケージ マネージャー用のGTK+ GUI -
-
-
インストーラーとの比較
パッケージ マネージャーは「インストール マネージャー」と呼ばれることが多く、パッケージ マネージャーとインストーラーが混同されることがあります。違いは次のとおりです。
ビルド自動化ユーティリティとの比較
ほとんどのソフトウェア構成管理システムでは、ソフトウェアのビルドとソフトウェアの展開を別々の独立したステップとして扱います。ビルド自動化ユーティリティは通常、コンピューター上にすでに存在する人間が判読可能なソース コードファイルを取得し、同じコンピューターまたはリモート コンピューター上でバイナリ実行可能パッケージに変換するプロセスを自動化します。その後、通常は別のコンピューターで実行されるパッケージ マネージャーが、事前にビルドされたバイナリ実行可能パッケージをインターネット経由でダウンロードし、インストールします。
ただし、両方の種類のツールには多くの共通点があります。
- たとえば、バイナリ コンポーネント間の依存関係を処理するためにパッケージ マネージャーで使用される依存関係グラフの トポロジカル ソートは、ソース コンポーネント間の依存関係を処理するためにビルド マネージャーでも使用されます。
- たとえば、多くのmakefile は実行可能ファイルのビルドだけでなく、 を使用したインストールもサポートしています
make install。 - たとえば、ソースベースのディストリビューション( Portage、Sorcery、Homebrewなど) のすべてのパッケージ マネージャーは、人間が読めるソース コードをバイナリ実行可能ファイルに変換してインストールすることをサポートしています。
MaakやAAPなどのいくつかのツールは、ビルドとデプロイメントの両方を処理するように設計されており、ビルド自動化ユーティリティとしてもパッケージマネージャーとしても、あるいはその両方としても使用できます。[18]
アプリストアとの比較
アプリストアは、すべてのレベルのプログラムをインストールする機能を持たない、アプリケーションレベルのパッケージマネージャーとも考えられます[19] [20]。従来のパッケージマネージャーとは異なり、アプリストアはソフトウェア自体の支払いを可能にするように設計されており（ソフトウェア開発ではなく）、依存関係や依存関係の解決のないモノリシックなパッケージのみを提供する場合があります。 [21] [20]通常、アプリストアは、パワーや出現よりも簡素化に重点を置いているため、管理機能が極端に制限されており、商用オペレーティングシステムやロックダウンされた「スマート」デバイスで一般的です。
パッケージマネージャーには、人間がレビューしたコードしか含まれていないこともよくあります。Google PlayやAppleのApp Storeなど、多くのアプリストアでは、主に自動化されたツールのみを使用してアプリをスクリーニングしています。マルウェアは、ソフトウェアが自動的にテストされていることを検知し、悪意のある活動を遅らせることで、これらのテストを通過できます。[22] [23] [24]ただし、例外もあります。たとえば、 npmパッケージデータベースは、コードの公開後のレビューに完全に依存しています。[25] [26]一方、Debianパッケージデータベースでは、パッケージがメインの安定データベースに追加される前に、人間による徹底的なレビュープロセスが行われます。XZ Utilsバックドアは、バックドアを挿入するために何年もの信頼構築を利用しましたが、それでもテストデータベースで検出されました。
一般的なパッケージマネージャーとフォーマット
ユニバーサルパッケージマネージャー
バイナリリポジトリマネージャーとも呼ばれるこのソフトウェアツールは、ソフトウェア開発プロセスで使用および生成されるバイナリファイル、成果物、パッケージのダウンロードと保存を最適化するように設計されたソフトウェアツールです。[27]これらのパッケージマネージャーは、企業がすべてのパッケージタイプを扱う方法を標準化することを目的としています。これにより、ユーザーはすべての成果物タイプにわたってセキュリティとコンプライアンスのメトリックを適用できるようになります。ユニバーサルパッケージマネージャーは、 DevOpsツールチェーンの中心にあると言われています。[28]
パッケージ形式
各パッケージ マネージャーは、管理できるパッケージの形式とメタデータに依存します。つまり、パッケージ マネージャーには、依存関係などの適切なメタデータとともに、特定のパッケージ マネージャー用にバンドルされるファイル グループが必要です。多くの場合、コア ユーティリティ セットがこれらのパッケージの基本的なインストールを管理し、複数のパッケージ マネージャーがこれらのユーティリティを使用して追加機能を提供します。
たとえば、yum はバックエンドとしてrpmに依存しています。yum は、システムのネットワークを維持するための簡単な構成などの機能を追加することで、バックエンドの機能を拡張します。別の例として、Synaptic Package Manager は、Advanced Packaging Tool (apt)ライブラリを使用してグラフィカル ユーザー インターフェイスを提供しますが、コア機能については dpkgに依存しています。
Alien は、さまざまなLinux パッケージ形式を変換するプログラムであり、Linux Standard Base (LSB) 準拠の.rpmパッケージ、.deb、Stampede (.slp)、Solaris (.pkg)、およびSlackware ( .tgz、.txz、.tbz、.tlz) パッケージ間の変換をサポートしています。
モバイル オペレーティング システムでは、Google Play はAndroid アプリケーション パッケージ(APK) パッケージ形式を使用し、 Microsoft Store はAPPXおよびXAP形式を使用します(Google Play と Microsoft Store には、どちらも同名のパッケージ マネージャーがあります)。
フリーでオープンソースのソフトウェアシステム
フリーおよびオープンソースソフトウェアの性質上、類似した互換性のあるライセンスのパッケージは、多くのオペレーティングシステムで使用できます。これらのパッケージは、構成可能で内部的に複雑なパッケージングシステムを使用して組み合わせて配布することができ、多くのソフトウェアの組み合わせを処理し、バージョン固有の依存関係と競合を管理します。フリーおよびオープンソースソフトウェアの一部のパッケージングシステムは、それ自体もフリーおよびオープンソースソフトウェアとしてリリースされています。Mac OS XやWindowsなどのプロプライエタリオペレーティングシステムのパッケージ管理と、Linuxなどのフリーおよびオープンソースソフトウェアのパッケージ管理の一般的な違いの1つは、フリーおよびオープンソースソフトウェアシステムでは、同じメカニズムを使用してサードパーティのパッケージもインストールおよびアップグレードできるのに対し、Mac OS XとWindowsのパッケージマネージャーは、それぞれAppleとMicrosoftが提供するソフトウェアのみをアップグレードします（Windowsの一部のサードパーティドライバーを除く）。サードパーティソフトウェアを継続的にアップグレードする機能は通常、パッケージ管理の構成ファイルに対応するリポジトリの URLを追加することによって追加されます。
アプリケーションレベルのパッケージマネージャー
システムレベルのアプリケーション マネージャーの他に、機能が制限されたオペレーティング システム用や、開発者が最新のライブラリを必要とするプログラミング言語用のアドオン パッケージ マネージャーもいくつかあります。
システムレベルのパッケージマネージャとは異なり、アプリケーションレベルのパッケージマネージャはソフトウェアシステムの小さな部分に焦点を当てています。通常、アプリケーションレベルのパッケージマネージャは、c:\cygwinや/opt/swなど、システムレベルのパッケージマネージャによって管理されていないディレクトリツリー内に存在します。 [29]ただし、プログラミングライブラリを扱うパッケージマネージャの場合はそうではない可能性があり、両方のパッケージマネージャがファイルを「所有」していると主張してアップグレードを中断する可能性があるため、競合が発生する可能性があります。
データ依存性管理
2016年、ライプツィヒ大学のコンピュータ科学者であるエドガード・マルクスは、データ管理を扱うシステムを指すためにデータ依存性管理[30]という用語を作り出した。データ依存性管理システムは、クラウド、パソコン、またはスマートデバイス（エッジ）上のデータの展開と管理を容易にするように設計されています。データ依存性管理フレームワークは、データの構想、ライセンス、およびその依存関係を記述するために使用できます。データ依存性管理の概念は、JavaScriptのnpm、 Rubyのgem、 .NETのNuGetなどのソフトウェアパッケージ依存性管理ツールに由来しています。その理論的根拠は、データ駆動型アプリケーションの機械学習モデルなど、データに対するソフトウェアの依存性をユーザーが管理できるようにすることです。これらは、データパッケージを公開、検索、およびインストールするのに役立ちます。データ依存性管理フレームワークの典型的な例としては、Hugging Face、KBox、[31]などがあります。
インパクト
イアン・マードックは、パッケージ管理は「 Linuxが業界にもたらした最大の進歩」であり、オペレーティングシステムとアプリケーションの境界を曖昧にし、「新しいイノベーションを市場に投入し、OSを進化させることが容易になる」とコメントした。[32]
パッケージマネージャー開発者向けのカンファレンスであるPackagingConも開催されています。これはパッケージ管理に対するさまざまなアプローチを理解することを目的として2021年に設立されました。[33]
参照
参考文献
- ^ 「パッケージマネージャーとは何か?」。2017年10月17日時点のオリジナルよりアーカイブ。 2018年12月19日閲覧。
- ^ 「ソフトウェア配布」。Dell KACE。2015年10月3日時点のオリジナルよりアーカイブ。 2012年7月11日閲覧。
- ^ “The history of *nix package management”. 2017年8月14日. 2021年10月24日時点のオリジナルよりアーカイブ。 2021年10月12日閲覧。
- ^ 「InfoMagic の 1994 年 12 月リリースのレビュー」。2021 年 10 月 29 日時点のオリジナルよりアーカイブ。2021年10 月 12 日閲覧。
- ^ 「Perlとその文化のタイムライン」。2013年1月11日時点のオリジナルよりアーカイブ。2021年10月29日閲覧。
- ^ Ludovic Courtès、Guix による機能的パッケージ管理、2020 年 5 月 15 日に Wayback Machineにアーカイブ、2013 年 6 月、マドリード、European Lisp Symposium 2013
- ^ 「Linux リポジトリ分類スキーム」。 braintickle.blogspot.com。 2006 年 1 月 13 日。 2007 年 10 月 11 日時点のオリジナルよりアーカイブ。 2008 年3 月 1 日に閲覧。
- ^ 「CentOS yum pinning rpms」。centos.org。2007年11月2日時点のオリジナルよりアーカイブ。2008年3月1日閲覧。
{{cite web}}: CS1 メンテナンス: 不適切 URL (リンク) - ^ ab "pacman(8) マニュアルページ". archlinux.org . 2019年8月31日時点のオリジナルよりアーカイブ。 2008年3月1日閲覧。
- ^ 「特定のバージョンのパッケージをインストールしたままにする方法 (複雑)」。debian.org。2019年11月14日時点のオリジナルよりアーカイブ。2008年3月1日閲覧。
- ^ 「Apt pinning to blacklist a package」。2011年7月22日時点のオリジナルよりアーカイブ。 2010年8月19日閲覧。
- ^ "documentation/sles11". en.opensuse.org . 2022年12月1日時点のオリジナルよりアーカイブ。2017年8月16日閲覧。
- ^ 「XBPS パッケージ マネージャー - Void Linux ハンドブック」。docs.voidlinux.org。2023年 1 月 23 日時点のオリジナルよりアーカイブ。2022 年12 月 19 日閲覧。
- ^ “swupd-client/swupd.1.rst at master · clearlinux/swupd-client · GitHub”. github.com . 2022年12月7日時点のオリジナルよりアーカイブ。 2022年6月22日閲覧。
- ^ “Pacman/Rosetta – ArchWiki”. wiki.archlinux.org . 2016年11月20日時点のオリジナルよりアーカイブ。 2017年9月17日閲覧。
- ^ 「dpkg バージョン 0.93.15 ソースコード」。2015年4月2日時点のオリジナルよりアーカイブ。2018年12月19日閲覧。
- ^ Eelco Dolstra、「ソフトウェア構築とソフトウェア展開の統合」Wayback Machineに 2019 年 9 月 21 日にアーカイブ。
- ^ 「Brew は、あなたが知らなかった macOS アプリ ストアの代替品です」。www.msn.com。2024年5 月 25 日閲覧。
- ^ ab King, Bertel (2017年3月17日). 「Linuxアプリストアの比較：あなたにぴったりなのはどれ？」MUO . 2024年5月25日閲覧。
- ^ 「パッケージ マネージャーとは何ですか?」www.debian.org。
- ^ バレット、ブライアン。「18 種類のマルウェア アプリが Apple の App Store に潜入した経緯」。Wired。
- ^ Whittaker, Zack (2019年10月24日). 「数百万人がGoogle Playからアドウェアに感染したAndroidアプリを数十個ダウンロード」TechCrunch。
- ^ ニューマン、リリー・ヘイ。「Google Play 以外で Android アプリを絶対にダウンロードしないでください」。Wired。
- ^ Ojamaa, Andres; Duuna, Karl (2012)。「Node.js プラットフォームのセキュリティの評価」。2012国際インターネット技術およびセキュアトランザクション会議。IEEE。ISBN 978-1-4673-5325-0. 2016年7月22日閲覧。
- ^ 「npm 行動規範: 許容されるパッケージコンテンツ」 。2017年5 月 9 日閲覧。
- ^ Waters, John K. (2015 年 9 月 8 日)。「JFrog が「ユニバーサル」アーティファクト リポジトリをリリース」。ADT Mag。アプリケーション開発トレンド マガジン。2016 年 3 月 2 日時点のオリジナルよりアーカイブ。2016年2 月 19 日閲覧。
- ^ Decoster, Xavier (2013 年 8 月 18 日). 「NuGet エコシステムの概要」. CodeProject.com . 2020 年 7 月 5 日時点のオリジナルよりアーカイブ。 2020 年2 月 6 日閲覧。
- ^ “Fink – Home”. finkproject.org . 2021年8月18日時点のオリジナルよりアーカイブ。2021年9月2日閲覧。
- ^ 「データ依存性管理」. github.com . 2023年7月13日閲覧。
- ^ "KBox". IEEE :125–132.2017年1月 .doi : 10.1109/ICSC.2017.77.S2CID14980310 . 2023年7月13日閲覧。
- ^ 「パッケージ管理がどのようにすべてを変えたか」 ianmurdock.com。 2009年2月23日時点のオリジナルよりアーカイブ。2008年3月1日閲覧。
- ^ “PackagingCon 2021 – パッケージマネージャー開発者とパッケージ作成者のためのカンファレンス”. Packaging-con.org . 2021年9月2日時点のオリジナルよりアーカイブ。2021年9月2日閲覧。
外部リンク
- Distrowatch のパッケージ管理チートシート
- ArchLinux Rosetta Stone – パッケージ マネージャーのコマンド ライン比較
- upkg ユニバーサル パッケージ マネージャーは、すべての Linux フレーバーに同じ構文を提供するラッパーです。