パッケージ管理システム

はじめに

第5章はじめに

このビデオでは、この章で説明するコンテンツの簡単な概要を示します。


学習目標
この章の終わりまでに、次のことができるようになります。

ソフトウェア パッケージ管理システムが必要な理由を説明できます。
バイナリ パッケージとソース パッケージの両方の機能を理解できます。
主な利用可能なパッケージ管理システムを列挙できます。
2つのレベルのユーティリティが必要な理由を理解できます。それは、最小限のパッケージだけを扱うレベルと、パッケージ間の依存関係を扱うレベルです。
ソフトウェアの内容とインストール方法を正確に制御でき、独自のパッケージをどのように作成するかを説明できます。
ソース管理システム、特にgitの役割を理解できます。


パッケージ管理システム

ソフトウェア パッケージの概念
パッケージ管理システムは、システム管理者がソフトウェア パッケージのインストール、アップグレード、構成、および削除を、既知で汎用的な方法で自動化できるツールを提供します。それらのパッケージ管理システムは以下を行います。

関連するソフトウェア ファイルを1つのパッケージ（アーカイブ）に収集して圧縮します。これには、1つ以上の他のパッケージを最初にインストールする必要がある場合があります。
簡単なソフトウェアのインストールまたは削除を許可します。
内部データベースを介してファイルの整合性を検証できます。
パッケージの出所を証明できます。
アップグレードが楽にできます。
論理的な特徴でパッケージをグループ化します。
パッケージ間の依存関係を管理します。

特定のパッケージには、実行可能ファイル、データ ファイル、ドキュメント、インストール スクリプト、および構成ファイルが含まれる場合があります。また、バージョン番号、チェックサム、ベンダー情報、依存関係、説明などのメタデータ属性も含まれます。

すべての情報は、インストール時に内部データベースにローカルに保存されます。これにより、バージョンと更新情報が簡単に照会できます。


なぜパッケージを使用するのか？
ソフトウェア パッケージ管理システムは、LinuxがエンタープライズIT環境にもたらした最大の進歩の1つだと言われています。システム管理者は、自動化された汎用的で信頼性の高い方法でファイルとメタ データの記録を把握することにより、パッケージ管理システムを使用して、個々のシステムを手動で操作することなく数千のシステムにインストール プロセスを拡張できます。含まれる機能は以下のとおりです。

自動化：手動でのインストールやアップグレードを行う必要はありません。
スケーラビリティ：1～10,000システムにパッケージをインストールします。
再現性と予測可能性。
セキュリティと監査。


パッケージの種類
パッケージにはいくつかの種類があります。

クリックして各ボックスを展開し、利用可能なさまざまなパッケージの種類について学習します。

パッケージの種類

バイナリ パッケージ
バイナリ パッケージには、実行可能ファイルやライブラリなど、デプロイの準備ができているファイルが含まれています。これらはアーキテクチャに依存しており、マシンの種類ごとにコンパイルされている必要があります。

ソース パッケージ
ソース パッケージは、バイナリ パッケージの生成に使用されます。（たとえば、RPMベースのシステムでのrpmbuild --rebuild使用など）ソース パッケージからバイナリ パッケージを常に再構築できる必要があります。1つのソース パッケージを複数のアーキテクチャに使用できます。

バイナリ パッケージは、大抵の場合、システム管理者が対処する必要があるパッケージです。

32ビット プログラムを実行できる64ビット システムでは、特定のプログラムに対して2つのバイナリ パッケージがインストールされている可能性があります。片方の名前にはx86_64またはamd64が、もう片方の名前にはi386またはi686が含まれます。

ソース パッケージは、バイナリ パッケージの作成に使用されたソース コードと変更の追跡に役立ちます。通常、デフォルトではシステムにインストールされませんが、ベンダーからいつでも取得できます。

ソース パッケージからバイナリ パッケージを再構築することは、常に可能でなければなりません。たとえば、RPMベースのシステムでは、以下を実行してp7zipバイナリ パッケージを再構築できます。

# rpmbuild --rebuild -rb p7zip-16.02-16.el8.src.rpm

結果は/root/rpmbuildに置かれます。

# root/rpmbuild>find . -name "*rpm"

./RPMS/x86_64/p7zip-plugins-16.02-16.el8.x86_64.rpm
./RPMS/x86_64/p7zip-debugsource-16.02-16.el8.x86_64.rpm
./RPMS/x86_64/p7zip-plugins-debuginfo-16.02-16.el8.x86_64.rpm
./RPMS/x86_64/p7zip-16.02-16.el8.x86_64.rpm
./RPMS/noarch/p7zip-doc-16.02-16.el8.noarch.rpm

結果が置かれる場所はLinuxディストリビューションとバージョンに依存しています。


利用可能なパッケージ管理システム
2つの非常に一般的なパッケージ管理システムがあります。クリックして各カードを反転し、詳細をご覧ください。

RPM（Red Hat Package Manager）
このシステムは、Red Hat Enterprise Linux、CentOS、Scientific Linux、CentOSなどのRed Hatから派生したすべてのディストリビューション、およびSUSEとその関連コミュニティopenSUSEのディストリビューションで使用されています。

dpkg (Debian Package)
このシステムは、Debian、Ubuntu、Linux MintなどDebianから派生したすべてのディストリビューションで使用されています。

他にも、Gentooが使用するportage/emerge、Archが使用するpacman、および組み込みLinuxシステムとAndroidが使用する特殊なパッケージ管理システムなどがあります。

もう1つの古いシステムとして、実際の管理や削除の戦略なしにパッケージをtarballとして提供する方法があります。このアプローチは、最も古いLinuxディストリビューションの1つであるSlackwareでまだ使われています。

しかし、ほとんどの場合はRPMまたはdpkgのいずれかを使いますので、このコースではこれらを学んでいきます。


パッケージング ツールのレベルと種類
クリックして各ボックスを展開し、2つのレベルのパッケージング システムについて学習します。

パッケージ ツールのレベル

低レベルのユーティリティ
これは、単一のパッケージまたはパッケージのリストをインストールするか削除するだけのものであり、各パッケージには個別に具体的な名前が付けられています。依存関係は完全には処理されず、次の警告のみが行われます。

別のパッケージをインストールする必要がある場合、最初のインストールは失敗します。
パッケージが別のパッケージで必要である場合、削除は失敗します。
rpmとdpkgユーティリティは、それらを使用するパッケージング システムに対してこの役割を果たします。

高レベルのユーティリティ
これは依存関係の問題を解決します。

ソフトウェアをインストールする前に別のパッケージまたはパッケージのグループをインストールする必要がある場合、その依存関係を処理します。
インストールされている別のパッケージがパッケージの削除を妨げる場合、管理者は影響を受けるソフトウェアをすべて中止するか削除するかを選択できます。
yum、dnf、zypper、PackageKitユーティリティはrpmシステムの依存関係を解決し、apt、apt-cacheおよびその他のユーティリティはdpkgシステムの依存関係を解決します。

このコースでは、パッケージング システムでのコマンド ライン インターフェイスについてのみ説明します。各Linux ディストリビューションで使用されるグラフィカルなフロントエンドは便利ですが、ここではどのインターフェイスにも縛られず、柔軟性を高めたいと考えています。


パッケージ ソース 
すべてのディストリビューションには、システム ユーティリティがソフトウェアを取得し新しいバージョンに更新するための、1つ以上のパッケージ リポジトリがあります。ディストリビューションの仕事は、リポジトリ内のすべてのパッケージが相互に適切に動作することを確認することです。

また、外部リポジトリはいつでも、ディストリビューションの標準サポート リストに追加することができます。これらはディストリビューションと密接に関連していることもあり、追加しても重要な問題が発生することはほとんどありません。例として、バージョン依存のリポジトリEPEL（Extra Packages for Enterprise Linux）セットがあります。このソースはFedoraでありメンテナ達もRed Hatと親密なため、RHELに適合するように作られています。

ただし、一部の外部リポジトリには、あまり構築も保守もされていないものがあります。たとえば、メイン リポジトリでパッケージが更新されても、外部パッケージの依存パッケージが更新されない可能性があります。


ソフトウェア パッケージの作成
独自のカスタム ソフトウェア パッケージを構築すると、独自のソフトウェアを簡単に配布およびインストールできます。Linuxのほとんどすべてのバージョンに、これを行うためのメカニズムがあります。

独自のパッケージを作成すると、ソフトウェアの内容とインストール方法を正確に制御できます。パッケージを作成できれば、新しいソフトウェアのインストールや古いソフトウェアの削除に必要な全タスクを行うスクリプトを実行できます。例えば以下です。

必要なシンボリックリンクの作成
必要に応じたディレクトリの作成
パーミッション設定
スクリプト化できるものすべて

.rpmまたは.debパッケージを構築する方法についてはここでは説明しません。これは、管理者ではなく開発者に必要な知識だからです。


リビジョン管理システム
ソフトウェア プロジェクトでは、プロジェクト サイズが大きくなったり貢献する開発者の数が増えたりするにつれ、管理がより複雑になります。

更新を整理し連携を促進するために、ソース管理にはさまざまなスキームが利用できます。このようなプログラムの標準機能には、変更の正確な履歴やログの保持、以前のリリースへのバックアップ、複数の開発者からの競合する可能性のある更新の調整などが含まれます。

ソース管理システム（または一般的に呼ばれているリビジョン管理システム）は、共同開発を調整する役割を果たします。

プロプライエタリとオープンの両方で利用可能な製品に、不自由することはありません。GPLライセンスの下でリリースされた製品の要約リストには以下が含まれています。

Revision Control System (RCS)
Concurrent Versions System (CVS)
Apache Subversion
git
GNU Arch
Monotone
Mercurial.

ここでは、Linuxカーネル開発コミュニティから生まれ、広く使用されている製品であるgitのみに焦点を当てます。gitはオープンソース プロジェクトで、非常に短期間に使用が広がり、クローズド ソース環境でもよく使用されています。


Linuxカーネルとgitの誕生
Linuxカーネル開発システムには、文字どおり何千人もの開発者が関与し、世界中に広く配布されるという点で特別なニーズがあります。さらに、それはすべてGPLライセンスの下で公開されています。

Linuxには長い間、実質的なソース リビジョン管理システムはありませんでした。そこで、主要なカーネル開発者は、使用制限付きライセンスを付与した商用プロジェクトのBitKeeperをLinuxカーネル開発に使用しました。

しかし、2005年春のライセンス制限に関する公開論争の結果、Linuxカーネルの開発にBitKeeperを無料で使用できなくなりました。

そこで求められたのがgitの開発です。開発者はLinus Torvaldsでした。gitのソースコードは/pub/software/scm/gitのインデックスから入手でき、完全なドキュメントもオンラインで入手できます。


gitの仕組み
技術的にみて、gitは普通の意味でのソース管理システムではなく、動作する基本単位はファイルではありません。オブジェクト データベースとディレクトリ キャッシュという、2つの重要なデータ構造を持っています。

オブジェクト データベースには、3種類のオブジェクトが含まれています。

blob（ブロブ）：ファイルの内容を含むバイナリ データのかたまり。
tree（ツリー）：ファイル名と属性を含むブロブの集合。ディレクトリ構造を提供。
commit（コミット）：ツリーのスナップショットを記述するチェンジセット。

ディレクトリ キャッシュは、ディレクトリ ツリーの状態をファイルに保存します。

ファイルをベースにしたシステムから管理システムを解放することにより、多くのファイルを含むチェンジセットを適切に処理できるようになりました。

gitは早いペースで開発されており、gitのグラフィカル インターフェイスも迅速に構築されています。たとえば、gitリポジトリのウェブ ページを参照してください。特定の変更とソースのツリーを簡単に参照できます。GitHubは現在、文字どおり何百万ものgitリポジトリを、公開／非公開にかかわらずホストしています。gitを有効に使用する方法に関しては、見やすい記事、書籍、オンライン チュートリアルなどが多数あります。


デモ：パッケージ管理システム

このビデオでは、パッケージ管理システムの簡単な概要を説明しています。


演習

課題 5.1: git によるバージョン コントロール

🚩
以下のPDFドキュメントに埋め込まれた外部URLにアクセスする場合は、常に右クリックして新しいタブまたはウィンドウで開いてください。直接クリックしてURLを開こうとすると、コース ウィンドウ／タブが閉じます。

Exercise 5.1: Version Control with git

Making sure git is installed
Your system may already have git installed.  Doingwhich gitshould show you if it is already present.  If not, whileyou may obtain the source and compile and install it, it is usually easier to install the appropriate pre-compiled binary packages. Exact package names may vary, but one of the following should work depending on your distribution:
$ sudo yum install git*      # RHEL 7 / CentOS 7
$ sudo apt install git*      # Debian /Ubuntu
$ sudo zypper install git*   # openSUSE
$ sudo dnf install git*      # Fedora / RHEL 8 / CentOS 8
according to your particular distribution.

Let’s get a feel for howgit worksand how easy it easy to use. For now we will just make our own local project.

1.  First we create a working directory and then initializegitto work with it:
$ mkdir git-test
$ cd git-test
$ git init

2.  Initializing the project creates a .git directory which will contain all the version control information; the main directoriesincluded in the project remain untouched. The initial contents of this directory look like:
$ ls -l .git
total 40
drwxrwxr-x 2 coop coop 4096 Dec 30 13:59 branches/
-rw-rw-r-- 1 coop coop   92 Dec 30 13:59 config
-rw-rw-r-- 1 coop coop   58 Dec 30 13:59 description
-rw-rw-r-- 1 coop coop   23 Dec 30 13:59 HEAD
drwxrwxr-x 2 coop coop 4096 Dec 30 13:59 hooks/
drwxrwxr-x 2 coop coop 4096 Dec 30 13:59 info/
drwxrwxr-x 4 coop coop 4096 Dec 30 13:59 objects/
drwxrwxr-x 4 coop coop 4096 Dec 30 13:59 refs/
Later we will describe the contents of this directory and its subdirectories; for the most part they start out empty.

3.  Next we create a file and add it to the project:
$ echo some junk > somejunkfile
$ git add somejunkfile

4.  We can see the current status of our project with:
$ git statu
sOn branch master
Initial commit
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: somejunkfile
Notice it is telling us that our file isstagedbut not yet committed.

5.  Let’s tellgitwho is responsible for this repository:
$ git config user.name "Another Genius"
$ git config user.email "b_genius@linux.com"
This must be done for each new project unless you have it predefined in a global configuration file.

6.  Now let’s modify the file, and then see the history of differences:
$ echo another line >> somejunkfile
$ git diff
diff --git a/somejunkfile b/somejunkfile
index 9638122..6023331 100644
--- a/somejunkfile
+++ b/somejunkfile
@@ -1 +1,2 @@
some junk
+another line

7.  To actually commit the changes to the repository we do:
$  git commit -m "My initial commit"
Created initial commit eafad66: My initial commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 somejunkfile
If you do not specify an identifying message to accompany the commit with the-moption you will jump into an editor to put some content in.  You must do this or the commit will be rejected.  The editor chosen will be what is set in your EDITOR environment variable, which can be superseded with setting GIT_EDITOR.

8.  You can see your history with:
$ git log
commit eafad66304ebbcd6acfe69843d246de3d8f6b9cc
Author: A Genius <a_genius@linux.com>
Date:   Wed Dec 30 11:07:19 2009 -0600
My initial commit
and you can see the information got in there. You will note the long hexadecimal string which is thecommit number; it is a 160-bit, 40-digit unique identifier.git cares about these beasts, not file names.

9.  You are now free to modify the already exiting file and add new files with git add.  But they are staged until you do another git commit

10.  Now that was not so bad. But we have only scratched the surface.


知識チェック

「第5章 - パッケージ管理システム」を完遂しました。おめでとうございます。このクイズに答えて、これまでに学んだ概念の理解度をチェックしてください。

クイズ開始

問題 5.1
Red Hat Enterprise Linux、SUSE、CentOS、Fedoraはどのパッケージ システムを使用していますか？

A. dpkg
B. rpm

問題 5.2
gitはLinuxカーネル コミュニティで広く使用されています。その理由を選んでください。

A. github.comによって発明され、カーネル開発者によって採用されました
B. 最初はLinus Torvaldsによって作成されました
C. CVSとsubversionから作られました
D. プロプライエタリなクローズド ソース製品に使用するには、料金の支払いが必要です


