logo

Linuxパッケージマネージャー

導入

パッケージ管理システムまたはパッケージ マネージャー ソフトウェアツールのグループです。コンピュータのオペレーティング システム用のコンピュータ プログラムのインストール プロセス、アップグレード プロセス、構成プロセス、および削除プロセスを効率的な方法で自動化します。あ パッケージマネージャー パッケージ、アーカイブ ファイル内のデータ、およびソフトウェア配布を操作します。

パッケージには次のようなメタデータが含まれます。 ソフトウェアの名前、その目的の説明、チェックサム (できれば暗号化ハッシュ関数)、d 依存関係リスト、ベンダー、 そして バージョンナンバー ソフトウェアを適切に実行するために不可欠です。

  • メタデータは、インストール時にローカル パッケージのデータベース内に保存されます。
  • 通常、パッケージ マネージャーは、前提条件の欠落やソフトウェアの不一致を防ぐために、バージョン情報とソフトウェアの依存関係のデータベースを管理します。
  • これらは、アプリ ストア、バイナリ リポジトリ マネージャー、およびソフトウェア リポジトリと緊密に連携して動作します。
  • パッケージ マネージャーは、手動による更新やインストールの必要性を排除するために開発されました。
  • 特に、通常、OS が数百以上の異なるソフトウェア パッケージを組み合わせている大規模な組織にとっては役立ちます。

パッケージマネージャーの機能

ソフトウェア パッケージは次のように定義できます。 アーカイブファイル 開発のためにコンピュータープログラムと重要なメタデータを組み合わせます。システム プログラムは、最初にビルドしてコンパイルする必要があるソース コード内にある可能性があります。

パッケージのメタデータには、パッケージのバージョン、パッケージの説明、依存関係 (事前にインストールする必要があるパッケージ) が含まれます。多くのパッケージ マネージャーは、ユーザーのコマンドの下でソフトウェア パッケージのインストール、アンインストール、保守、または検索のアクションを実行できるように所有されています。

パッケージ管理システム いくつかの典型的なものが含まれています 機能 それについては以下で説明します。

  • パッケージ アーカイブを抽出するためのファイル アーカイバを処理します。
  • デジタル証明書とチェックサムをそれぞれ認証することで、パッケージの信頼性と完全性を保証します。
  • アプリ ストアまたはソフトウェア リポジトリを介して、既存のソフトウェアを更新、インストール、ダウンロード、または検索します。
  • ユーザーの混乱を軽減するための機能を使用してパッケージを結合します。
  • パッケージが必要なすべてのパッケージとともにインストールされていることを確認するための依存関係を維持します。だから、無視して、 「依存地獄」。
Linuxパッケージマネージャー

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

システム管理者 パッケージ管理ソフトウェア以外のツールを使用してソフトウェアをインストールおよび管理する場合があります。 例えば、 ローカル管理者は、ソース コード (パッケージ化されていない) をダウンロードし、コンパイルして、インストールする場合があります。

これにより、ローカル システムの状態がパッケージ マネージャーの状態のデータベースとともに同期から外れてしまう可能性があります。ローカル管理者は、変更をパッケージ マネージャーに手動で統合したり、いくつかの依存関係を管理したりするなど、追加の措置を講じる必要があります。

Androidで隠されたものを見つける方法

パッケージを確実にコンパイルするためのツールがいくつかあります。 (ローカルで) パッケージ管理を使用して開発されています。

チェックインストール に利用可能です .rpm または .deb ファイルベースのディストリビューション そして スラックウェア Linux 同じように。のために ハイブリッド のようなシステム Arch Linux そして レシピベースのシステム のように Gentoo Linux、 最初にレシピを指定して、パッケージがローカル パッケージ データベースに適合するかどうかを確認することができます。

分散ライブラリの課題

静的ライブラリ リンクではなく動的ライブラリ リンクに依存するさまざまなコンピュータ システムは、機械語命令のライブラリ (実行可能ファイル) をアプリケーションおよびパッケージ全体に分散します。

これらのタイプのシステムでは、ライブラリを必要とする個別のパッケージ間の一般的な関係により、と呼ばれるチャレンジでバージョンが生成されます。 「依存地獄」。

としても知られています 「DLL地獄」 Microsoft Windows でリンクされたライブラリを動的に処理する場合。これらのシステムでは、パッケージを適切に管理することが重要です。

から オープンステップ 、フレームワーク システムは、複数のライブラリ バージョンを同時にインストールできるようにし、多くのソフトウェア パッケージがどのバージョンにリンクされているかを説明できるようにすることで、この問題を解決しようとしました。

構成のメンテナンス

構成ファイルのアップグレードは、ソフトウェアのアップグレードの場合に特に問題になります。少なくとも Unix では、パッケージ マネージャーはファイル アーカイブ ユーティリティの拡張機能として誕生したためです。

通常、構成ファイルに対してルールを使用するのではなく、構成ファイルを保持または上書きするだけです。構成ファイルの形式が変更されると、いくつかの問題が発生する可能性があります。たとえば、古い構成ファイルが新しいオプションを明示的に無効にしていない場合は、そのオプションを表示する必要があります。 Debian の dpkg などのいくつかのパッケージ マネージャーでは、インストール時に構成が可能です。他の場合には、デフォルト構成を使用してパッケージをインストールし、多数のシステムへのインストール (ヘッドレス) で構成を上書きすることが望ましい場合もあります。このタイプのインストール (事前構成) は、dpkg 経由でもサポートされます。

アップグレードの抑制

ユーザーがアップグレードを行うためにパッケージ管理ソフトウェアに協力する場合、実行するアクション リスト (通常はアップグレードするパッケージ リストと、場合によっては新旧のバージョン番号を提供する) をユーザーに提供するのが伝統的です。

これにより、ユーザーはアップグレード用に 1 つのパッケージを選択することも、一括でアップグレードすることもできます。さまざまなパッケージ マネージャーは、ソフトウェア パッケージの指定に従って、多くのパッケージを決してアップグレードしないように、または古い標準で重大な不安定性や脆弱性が検出された場合にのみパッケージをアップグレードするように構成できます。このプロセスはバージョン固定と呼ばれることもあります。

例えば:

yum はそれをサポートしています 除外=オープンオフィス* 構文

構文を使用したパックマン 無視=オープンオフィス (どちらの場合も、openoffice のアップグレードを抑制するため)

dselect と dpkg は、パッケージ選択内のholdフラグによって部分的にこれをサポートします。

適性がある 「禁止する」 そして '所有' フラグ。

portage は設定ファイルによってこれをサポートします。つまり、 パッケージ.マスク。

APT はフラグを拡張します。つまり、 所有 コンプレックスによって 「ピン留め」 メソッド (ユーザーはパッケージをブラックリストに登録することもできます)。

リポジトリ

システムへのインストールを許可するソフトウェアの種類をユーザーがさらに制御できるようにするために (ディストリビュータ側の利便性や法的理由により)、ソフトウェアは多くのソフトウェア リポジトリを使用してダウンロードされることがあります。

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

より開発されたパッケージ管理の側面のいくつかにより、 'カスケードパッケージの削除', ここで、宛先パッケージに依存するすべてのパッケージと、宛先パッケージが依存するすべてのパッケージも削除されます。

コマンドの比較

ただし、コマンドはすべての特定のパッケージ マネージャーに対して一意です。ほとんどのパッケージ マネージャーが同じ機能を利用できるため、これらのコマンドはかなりの程度まで変換可能です。

パッケージマネージャーの普及率

dpkg などのパッケージ マネージャーは、1994 年には利用可能になりました。バイナリ パッケージを中心とした Linux のさまざまなディストリビューションは、ソフトウェアの保守と管理の主な手段としてパッケージ管理システムに大きく依存しています。

Windows Phone、iOS (Unix 系)、Android (Linux ベース) などの多くのモバイル オペレーティング システムは、ベンダーのそれぞれの App Store にほぼ依存しています。したがって、彼らはパッケージ管理システム (専用) を使用します。

インストーラーとの比較

多くの場合、パッケージ マネージャーは 「インストールマネージャー」。 インストーラーとパッケージマネージャーの間で混乱が生じる可能性があります。主な違いのいくつかを以下に示します。

基準 パッケージマネージャー インストーラ
同梱品 通常、OS すべてのコンピュータプログラム
インストール情報の場所 インストール用の中央データベース 完全に設置者の裁量に任されています。アプリのフォルダー内のファイル、またはオペレーティング システムのフォルダーとファイル内のファイルにすることができます。彼らは、インストール情報を公開せずに、アンインストーラのリストに自分自身を登録する可能性があります。
保守範囲 場合によってはシステム上のすべてのパッケージ 梱包された商品そのもの
開発者 単一のパッケージ マネージャー ベンダー 複数のインストーラー ベンダー
パッケージの形式 認識されているいくつかの形式 アプリの数と同じ数の形式を使用できます
パッケージ形式の互換性 パッケージマネージャーが使用する限り利用できます。ユーザーがパッケージ マネージャーをアップグレードしないか、新しいパッケージ マネージャーのバージョンがそれをサポートし続けるかのいずれかです。 インストーラーがアーカイブ形式を使用している場合、インストーラーは常にそのアーカイブ形式と互換性があります。ただし、他のコンピューターと同様に、インストーラーもソフトウェアの腐敗の影響を受ける可能性があります。

自動化ユーティリティとの比較

ほとんどすべてのソフトウェア構成管理システムは、ソフトウェアの展開とソフトウェアの構築を別々のものとして表します。通常、ビルド自動化ユーティリティは、システム上にすでに人間が読める形式のソース コード ファイルを取得し、それらを同様のシステム上で実行可能パッケージ (バイナリ) に変換する手順を高速化します。

通常、後で他のいくつかのシステム上で実行されるパッケージ マネージャーが、それらの実行可能パッケージ (ビルド済みバイナリ) をインターネット上にダウンロードし、インストールします。

ただし、どちらのタイプのツールにも、以下に示すいくつかの共通要素が含まれています。

  • 依存関係グラフのトポロジー的並べ替えは、多くのバイナリ コンポーネント間の依存関係を処理するためにパッケージ マネージャー内で適用されます。
  • また、多くのソース コンポーネント間の依存関係を処理するために、ビルド マネージャーの内部にも適用されます。
  • 実行可能ファイルのビルドだけでなく、さまざまな Makefile がサポートを提供します。
  • また、make install を使用した のインストールもサポートされています。
  • すべてのパッケージ マネージャーは、ソース コード (人間が読める形式) をバイナリ実行可能ファイルに変換し、それを Homebrew、Sorcery、Portage などのソースベースのディストリビューション用にインストールすることをサポートしています。

いくつかのツールのような アー・アー・ピー そして 作る 導入と構築の両方を管理するために開発されています。これらは、パッケージ マネージャー、ビルド自動化ユーティリティ、またはその両方として使用することもできます。

基本的なパッケージマネージャーとその形式

ユニバーサルパッケージマネージャー

とも呼ばれます バイナリリポジトリマネージャー。 このパッケージ マネージャーは、ストレージを最適化し、ソフトウェア開発プロセス内で生成および使用されるバイナリ ファイル、パッケージ、アーティファクトをダウンロードするために作成されたソフトウェア ツールです。

ユニバーサルパッケージマネージャー ユーザーがあらゆる種類のパッケージを扱うファッションの標準化に焦点を当てています。これらは、各タイプのアーティファクトに関するコンプライアンスおよびセキュリティのメトリクスを使用する機能をユーザーに提供します。彼らは、次の作業の真っ最中であると割り当てられています。 DevOps ツールチェーン。

Linuxパッケージマネージャー

オープンソースおよびフリー ソフトウェア システム

互換性のあるライセンスおよび同様のライセンスに基づくパッケージは、オープンソースおよびフリー ソフトウェアの動作により、いくつかのオペレーティング システムで使用するために存在しています。

これらのパッケージは、内部的に複雑で構成可能なパッケージング システムを使用して配布および結合して、バージョン固有のいくつかの競合、依存関係、およびソフトウェアの並べ替えを管理できます。

また、オープンソースおよびフリー ソフトウェアのいくつかのパッケージング システムは、それ自体がオープンソースおよびフリー ソフトウェアとして公開されています。

Windows や Mac OS X などのオペレーティング システムでのパッケージ管理と、Linux などのオープンソースおよびフリー ソフトウェアでのパッケージ管理の違いの 1 つは、オープンソースおよびフリー ソフトウェア システムでは、同様のメカニズムでサードパーティのパッケージをアップグレードしてインストールできることです。 。一方、Windows と Mac OS X の多くのパッケージ マネージャーは、それぞれ Microsoft と Apple から提供されたソフトウェアをアップグレードします。

サードパーティ ソフトウェアを継続的にアップグレードする機能は、対応するリポジトリ URL をパッケージ管理の構成ファイルに含めることによって追加されます。

パッケージ形式

すべてのパッケージ マネージャーは、管理できるパッケージのメタデータと形式に依存します。パッケージ マネージャーでは、依存関係などの適切なメタデータを使用して、ファイル グループを特定のパッケージ マネージャー用にグループ化する必要があります。

Javaの部分文字列

多くの場合、ユーティリティのコア コレクションがこれらのパッケージを通じて一般的なインストールを管理し、複数のパッケージ マネージャーがこれらのユーティリティを適用して追加機能を提供します。

例:

  1. yum はバックエンドとして rpm に依存します。 Yum は、システム ネットワークを維持するための簡単な構成などの側面を追加することにより、バックエンド機能を開発します。
  2. synaptic パッケージ マネージャーは、dpkg に依存する Advanced Packaging Tool のライブラリを適用することで GUI を提供します。

エイリアン 異なる Linux パッケージ形式間で変換するプログラムとして定義できます。間の変換をサポートしています。 スラックウェア (.tgz、.tlz、.tbz、.txz) パッケージ、 Solaris (.pkg)、Stampede (.slp)、.deb、.rpm パッケージ、 そして Linux標準ベース (LSB)準拠。

いくつかのモバイル OS では、 グーグルプレイ のパッケージ形式を利用します。 Android アプリケーション パッケージ (要するに APK )一方、 Windows ストア の形式を使用します XAP そして 付録。 両方 Windows ストア そして グーグルプレイ 同名のパッケージマネージャーが含まれています。

アプリケーションレベルのパッケージマネージャー

プログラミング言語用の OS 用のパッケージ マネージャー (アドオン) がいくつかあり、開発者が最新のライブラリを必要とする機能が制限されています。アプリケーション レベルのパッケージ マネージャーは、システム レベルのパッケージ マネージャーとは対照的に、ソフトウェア システムの小さな部分に集中します。

通常、これらはディレクトリ ツリー内に存在します。のようなシステムレベルのパッケージマネージャーによって編成されていません。 /usr/local/fink または c:cygwin. ただし、これはプログラミング ライブラリを操作するパッケージ マネージャーの条件ではない可能性があり、両方のパッケージ マネージャーがアップグレードを中断して要求する可能性があるため、競合が発生する可能性があります。 '自分の' ファイル。