docs/LFS-BOOK/chapter06/pkgmgt.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   2     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml">
   4   <head>
   5     <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8" />
   6     <title>
   7       6.3. パッケージ管理
   8     </title>
   9     <link rel="stylesheet" href="../stylesheets/lfs.css" type="text/css" />
  10     <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
  11     <link rel="stylesheet" href="../stylesheets/lfs-print.css" type=
  12     "text/css" media="print" />
  13   </head>
  14   <body class="lfs" id="lfs-6.8">
  15     <div class="navheader">
  16       <h4>
  17         Linux From Scratch - Version 6.8
  18       </h4>
  19       <h3>
  20         第6章 基本的なソフトウェアのインストール
  21       </h3>
  22       <ul>
  23         <li class="prev">
  24           <a accesskey="p" href="kernfs.html" title=
  25           "仮想カーネルファイルシステムの準備">前のページ</a>
  26           <p>
  27             仮想カーネルファイルシステムの準備
  28           </p>
  29         </li>
  30         <li class="next">
  31           <a accesskey="n" href="chroot.html" title="Chroot 環境への移行">次のページ</a>
  32           <p>
  33             Chroot 環境への移行
  34           </p>
  35         </li>
  36         <li class="up">
  37           <a accesskey="u" href="chapter06.html" title=
  38           "第6章 基本的なソフトウェアのインストール">上に戻る</a>
  39         </li>
  40         <li class="home">
  41           <a accesskey="h" href="../index.html" title=
  42           "Linux From Scratch - Version 6.8">ホーム</a>
  43         </li>
  44       </ul>
  45     </div>
  46     <div class="sect1" lang="ja" xml:lang="ja">
  47       <h1 class="sect1">
  48         <a id="ch-system-pkgmgt" name="ch-system-pkgmgt"></a>6.3. パッケージ管理
  49       </h1>
  50       <p>
  51         パッケージ管理についての説明を LFS ブックに加えて欲しいとの要望をよく頂きます。
  52         パッケージ管理ツールがあれば、インストールされるファイル類を管理し、パッケージの削除やアップグレードを容易に実現できます。
  53         パッケージ管理ツールでは、バイナリファイルやライブラリファイルだけでなく、設定ファイル類のインストールも取り扱います。
  54         パッケージ管理ツールをどうしたら・・・ いえいえ本節は特定のパッケージ管理ツールを説明するわけでなく、その利用を勧めるものでもありません。
  55         もっと広い意味で、管理手法にはどういったものがあり、どのように動作するかを説明します。
  56         あなたにとって最適なパッケージ管理がこの中にあるかもしれません。 あるいはそれらをいくつか組み合わせて実施することになるかもしれません。
  57         本節ではパッケージのアップグレードを行う際に発生する問題についても触れます。
  58       </p>
  59       <p>
  60         LFS や BLFS において、パッケージ管理ツールについて触れていない理由には以下のものがあります。
  61       </p>
  62       <div class="itemizedlist">
  63         <ul>
  64           <li>
  65             <p>
  66               本書の目的は Linux システムがいかに構築されているかを学ぶことです。 パッケージ管理はその目的からはずれてしまいます。
  67             </p>
  68           </li>
  69           <li>
  70             <p>
  71               パッケージ管理についてはいくつもの方法があり、それらには一長一短があります。
  72               ユーザーに対して満足のいくものを選び出すのは困難です。
  73             </p>
  74           </li>
  75         </ul>
  76       </div>
  77       <p>
  78         <a class="ulink" href=
  79         "http://www.linuxfromscratch.org/hints/list.html">ヒントプロジェクト (Hints
  80         Project)</a> ページに、パッケージ管理についての情報が示されています。 それらが望むものかどうか確認してみてください。
  81       </p>
  82       <div class="sect2" lang="ja" xml:lang="ja">
  83         <h2 class="sect2">
  84           6.3.1. アップグレードに関する問題
  85         </h2>
  86         <p>
  87           パッケージ管理ツールがあれば、各種ソフトウェアの最新版がリリースされた際に容易にアップグレードができます。 全般に LFS ブックや
  88           BLFS ブックに示されている作業手順に従えば、新しいバージョンへのアップグレードを行っていくことはできます。
  89           以下ではパッケージをアップグレードする際に注意すべき点、特に稼動中のシステムに対して実施するポイントについて説明します。
  90         </p>
  91         <div class="itemizedlist">
  92           <ul>
  93             <li>
  94               <p>
  95                 ツールチェーン (Glibc、GCC、Binutils)
  96                 のいずれかについて、マイナーバージョンをアップグレードする必要がある場合は、LFS を再構築するのが無難です。
  97                 この場合、すべてのパッケージの依存関係を考慮して順番に作り直せば実現できる<span class=
  98                 "emphasis"><em>はず</em></span> ですが、これはあまりお勧めしません。 例えば
  99                 glibc-2.2.x を glibc-2.3.x にアップグレードする必要がある場合は、再構築するのが無難です。
 100                 マイクロバージョンをアップグレードする場合は、もっと単純にそのパッケージをインストールし直すだけで動作すると思いますが、保証はありません。
 101                 例えば glibc-2.3.4 を glibc-2.3.5 にアップグレードする場合、普通は何も問題ないでしょう。
 102               </p>
 103             </li>
 104             <li>
 105               <p>
 106                 共有ライブラリを提供しているパッケージをアップデートする場合で、そのライブラリの名前が変更になった場合は、そのライブラリを動的にリンクしているすべてのパッケージは、新しいライブラリにリンクされるように再コンパイルを行う必要があります。
 107                 (パッケージのバージョンとライブラリ名との間には相関関係はありません。) 例えば foo-1.2.3
 108                 というパッケージが共有ライブラリ <code class="filename">libfoo.so.1</code>
 109                 をインストールするものであるとします。 そして今、新しいバージョン foo-1.2.4 にアップグレードし、共有ライブラリ
 110                 <code class="filename">libfoo.so.2</code> をインストールするとします。
 111                 この例では <code class="filename">libfoo.so.1</code>
 112                 を動的にリンクいるパッケージがあったとすると、それらはすべて <code class=
 113                 "filename">libfoo.so.2</code> に対してリンクするよう再コンパイルしなければなりません。
 114                 古いライブラリに依存しているパッケージすべてを再コンパイルするまでは、そのライブラリを削除するべきではありません。
 115               </p>
 116             </li>
 117           </ul>
 118         </div>
 119       </div>
 120       <div class="sect2" lang="ja" xml:lang="ja">
 121         <h2 class="sect2">
 122           6.3.2. パッケージ管理手法
 123         </h2>
 124         <p>
 125           以下に一般的なパッケージ管理手法について示します。
 126           パッケージ管理マネージャを用いる前に、様々な方法を検討し、特にそれぞれの欠点も確認してください。
 127         </p>
 128         <div class="sect3" lang="ja" xml:lang="ja">
 129           <h3 class="sect3">
 130             6.3.2.1. すべては頭の中で
 131           </h3>
 132           <p>
 133             そうです。 これもパッケージ管理のやり方の一つです。
 134             いろいろなパッケージに精通していて、どんなファイルがインストールされるか分かっている人もいます。
 135             そんな人はパッケージ管理ツールを必要としません。
 136             あるいはパッケージが更新された際に、システム全体を再構築しようと考えている人なら、やはりパッケージ管理ツールを必要としません。
 137           </p>
 138         </div>
 139         <div class="sect3" lang="ja" xml:lang="ja">
 140           <h3 class="sect3">
 141             6.3.2.2. 異なるディレクトリへのインストール
 142           </h3>
 143           <p>
 144             これは最も単純なパッケージ管理のやり方であり、パッケージ管理のためのツールを用いる必要はありません。
 145             個々のパッケージを個別のディレクトリにインストールする方法です。 例えば foo-1.1 というパッケージを
 146             <code class="filename">/usr/pkg/foo-1.1</code> ディレクトリにインストールし、この
 147             <code class="filename">/usr/pkg/foo-1.1</code> に対するシンボリックリンク
 148             <code class="filename">/usr/pkg/foo</code> を作成します。
 149             このパッケージの新しいバージョン foo-1.2 をインストールする際には <code class=
 150             "filename">/usr/pkg/foo-1.2</code>
 151             ディレクトリにインストールした上で、先ほどのシンボリックリンクをこのディレクトリを指し示すように置き換えます。
 152           </p>
 153           <p>
 154             <code class="envar">PATH</code>、 <code class=
 155             "envar">LD_LIBRARY_PATH</code>、 <code class=
 156             "envar">MANPATH</code>、 <code class="envar">INFOPATH</code>、
 157             <code class="envar">CPPFLAGS</code> といった環境変数に対しては <code class=
 158             "filename">/usr/pkg/foo</code> ディレクトリを加える必要があるかもしれません。
 159             もっともパッケージによっては、このやり方では管理できないものもあります。
 160           </p>
 161         </div>
 162         <div class="sect3" lang="ja" xml:lang="ja">
 163           <h3 class="sect3">
 164             6.3.2.3. シンボリックリンク方式による管理
 165           </h3>
 166           <p>
 167             これは一つ前に示したパッケージ管理テクニックの応用です。 各パッケージは同様にインストールします。
 168             ただし先ほどのようなシンボリックリンクを生成するのではなく <code class="filename">/usr</code>
 169             ディレクトリ階層の中に各ファイルのシンボリックリンクを生成します。 この方法であれば環境変数を追加設定する必要がなくなります。
 170             シンボリック・リンクを自動生成することもできますが、パッケージ管理ツールの中にはこの手法を使って構築されているものもあります。
 171             よく知られているものとして Stow、Epkg、Graft、Depot があります。
 172           </p>
 173           <p>
 174             インストール時には意図的な指示が必要です。 パッケージにとっては <code class=
 175             "filename">/usr</code> にインストールすることが指定されたものとなりますが、実際には
 176             <code class="filename">/usr/pkg</code> 配下にインストールされるわけです。
 177             このインストール方法は単純なものではありません。 例えば今 libfoo-1.1 というパッケージをインストールするものとします。
 178             以下のようなコマンドでは、このパッケージを正しくインストールできません。
 179           </p>
 180           <pre class="userinput">
 181 <kbd class="command">./configure --prefix=/usr/pkg/libfoo/1.1
 182 make
 183 make install</kbd>
 184 </pre>
 185           <p>
 186             インストール自体は動作しますが、このパッケージに依存している他のパッケージは、期待どおりには libfoo
 187             を正しくリンクしません。 例えば libfoo をリンクするパッケージをコンパイルする際には <code class=
 188             "filename">/usr/lib/libfoo.so.1</code> がリンクされると思うかもしれませんが、実際には
 189             <code class="filename">/usr/pkg/libfoo/1.1/lib/libfoo.so.1</code>
 190             がリンクされることになります。 正しくリンクするためには <code class="envar">DESTDIR</code>
 191             変数を使って、パッケージのインストールをうまく仕組む必要があります。 この方法は以下のようにして行います。
 192           </p>
 193           <pre class="userinput">
 194 <kbd class="command">./configure --prefix=/usr
 195 make
 196 make DESTDIR=/usr/pkg/libfoo/1.1 install</kbd>
 197 </pre>
 198           <p>
 199             多くのパッケージは、たいていはこの手法をサポートしていますが、そうでないものもあります。
 200             この手法を取り入れていないパッケージに対しては、手作業にてインストールすることが必要になります。
 201             またはそういった問題を抱えるパッケージであれば <code class="filename">/opt</code>
 202             ディレクトリにインストールする方が容易なことかもしれません。
 203           </p>
 204         </div>
 205         <div class="sect3" lang="ja" xml:lang="ja">
 206           <h3 class="sect3">
 207             6.3.2.4. タイムスタンプによる管理方法
 208           </h3>
 209           <p>
 210             この方法ではパッケージをインストールするにあたって、あるファイルにタイムスタンプが記されます。 インストールの直後に
 211             <span class="command"><strong>find</strong></span>
 212             コマンドを適当なオプション指定により用いることで、インストールされるすべてのファイルのログが生成されます。
 213             これはタイムスタンプファイルの生成の後に行われます。 この方法を用いたパッケージ管理ツールとして install-log
 214             があります。
 215           </p>
 216           <p>
 217             この方法はシンプルである利点がありますが、以下の二つの欠点があります。
 218             インストールの際に、いずれかのファイルのタイムスタンプが現在時刻でなかった場合、そういったファイルはパッケージ管理ツールが正しく制御できません。
 219             またこの方法は一つのパッケージだけが、その時にインストールされることを前提とします。
 220             例えば二つのパッケージが二つの異なる端末から同時にインストールされるような場合は、ログファイルが適切に生成されません。
 221           </p>
 222         </div>
 223         <div class="sect3" lang="ja" xml:lang="ja">
 224           <h3 class="sect3">
 225             6.3.2.5. インストールスクリプトの追跡管理
 226           </h3>
 227           <p>
 228             この方法はインストールスクリプトが実行するコマンドを記録するものです。 これには以下の二種類の手法があります。
 229           </p>
 230           <p>
 231             環境変数 <code class="envar">LD_PRELOAD</code>
 232             を使えば、インストール前にあらかじめロードされるライブラリを定めることができます。 パッケージのインストール中には
 233             <span class="command"><strong>cp</strong></span>、 <span class=
 234             "command"><strong>install</strong></span>、 <span class=
 235             "command"><strong>mv</strong></span>
 236             など様々な実行モジュールにそのライブラリをリンクさせ、ファイルシステムを変更するようなシステムコールを監視することで、そのライブラリがパッケージを追跡管理できるようになります。
 237             この方法を実現するためには、動的リンクする実行モジュールはすべて suid ビット、sgid ビットがオフでなければなりません。
 238             事前にライブラリをロードしておくと、インストール中に予期しない副作用が発生するかもしれません。
 239             したがって、ある程度のテスト確認を行って、パッケージ管理ツールが不具合を引き起こさないこと、しかるべきファイルの記録を取っておくことが必要とされます。
 240           </p>
 241           <p>
 242             二つめの方法は <span class="command"><strong>strace</strong></span>
 243             を用いるものです。 これはインストールスクリプトの実行中に発生するシステムコールを記録するものです。
 244           </p>
 245         </div>
 246         <div class="sect3" lang="ja" xml:lang="ja">
 247           <h3 class="sect3">
 248             6.3.2.6. パッケージのアーカイブを生成する方法
 249           </h3>
 250           <p>
 251             この方法では、シンボリックリンク方式によるパッケージ管理にて説明したのと同じように、パッケージが個別のディレクトリにインストールされます。
 252             インストールされた後には、インストールファイルを使ってアーカイブが生成されます。
 253             このアーカイブはこの後に、ローカルPCへのインストールに用いられ、他のPCのインストールに利用することもできます。
 254           </p>
 255           <p>
 256             商用ディストリビューションが採用しているパッケージ管理ツールは、ほとんどがこの方法によるものです。
 257             この方法に従ったパッケージ管理ツールの例に RPM があります。 (これは <a class="ulink" href=
 258             "http://www.linux-foundation.org/en/Specifications">Linux
 259             Standard Base Specification</a> が規定しています。) また pkg-utils、Debian の
 260             apt、Gentoo の Portage システムがあります。 このパッケージ管理手法を LFS システムに適用するヒント情報が
 261             <a class="ulink" href=
 262             "http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt">
 263             http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt</a>
 264             にあります。
 265           </p>
 266           <p>
 267             パッケージファイルにその依存パッケージ情報まで含めてアーカイブ生成することは、非常に複雑となり LFS の範疇を超えるものです。
 268           </p>
 269           <p>
 270             Slackware は、パッケージアーカイブに対して <span class=
 271             "command"><strong>tar</strong></span> ベースのシステムを利用しています。
 272             他のパッケージ管理ツールはパッケージの依存性を取り扱いますが、このシステムは意図的にこれを行っていません。 Slackware
 273             のパッケージ管理に関する詳細は <a class="ulink" href=
 274             "http://www.slackbook.org/html/package-management.html">http://www.slackbook.org/html/package-management.html</a>
 275             を参照してください。
 276           </p>
 277         </div>
 278         <div class="sect3" lang="ja" xml:lang="ja">
 279           <h3 class="sect3">
 280             6.3.2.7. ユーザー情報をベースとする管理方法
 281           </h3>
 282           <p>
 283             この手法は LFS に固有のものであり Matthias Benkmann により考案されました。 <a class=
 284             "ulink" href=
 285             "http://www.linuxfromscratch.org/hints/list.html">ヒントプロジェクト
 286             (Hints Project)</a> から入手することが出来ます。
 287             考え方としては、各パッケージを個々のユーザーが共有ディレクトリにインストールします。
 288             パッケージに属するファイル類は、ユーザーIDを確認することで容易に特定出来るようになります。
 289             この手法の特徴や短所については、複雑な話となるため本節では説明しません。 詳しくは <a class="ulink" href=
 290             "http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt">
 291             http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt</a>
 292             に示されているヒントを参照してください。
 293           </p>
 294         </div>
 295       </div>
 296       <div class="sect2" lang="ja" xml:lang="ja">
 297         <h2 class="sect2">
 298           6.3.3. 他システムへの LFS の配置
 299         </h2>
 300         <p>
 301           LFS システムの利点の一つとして、どのファイルもディスク上のどこに位置していても構わないことです。
 302           他のコンピュータに対してビルドした LFS の複製を作ろうとするなら、それが同等のアーキテクチャであれば容易に実現できます。 つまり
 303           <span class="command"><strong>tar</strong></span> コマンドを使って LFS
 304           のルートディレクトリを含むパーティション (LFS の基本的なビルドの場合、非圧縮で 250MB 程度)
 305           をまとめ、これをネットワーク転送か、あるいは CD-ROM を通じて新しいシステムにコピーし、伸張 (解凍) するだけです。
 306           この場合でも、設定ファイルはいくらか変更することが必要です。 変更が必要となる設定ファイルは以下のとおりです。
 307           <code class="filename">/etc/hosts</code>、 <code class=
 308           "filename">/etc/fstab</code>、 <code class=
 309           "filename">/etc/passwd</code>、 <code class=
 310           "filename">/etc/group</code>、 <code class=
 311           "filename">/etc/shadow</code>、 <code class=
 312           "filename">/etc/ld.so.conf</code>、 <code class=
 313           "filename">/etc/scsi_id.config</code>、 <code class=
 314           "filename">/etc/sysconfig/network</code>、 <code class=
 315           "filename">/etc/sysconfig/network-devices/ifconfig.eth0/ipv4</code>
 316         </p>
 317         <p>
 318           新しいシステムのハードウェアと元のカーネルに差異があるかもしれないため、カーネルを再ビルドする必要があるでしょう。
 319         </p>
 320         <p>
 321           最後に新システムを起動可能とするために <a class="xref" href="../chapter08/grub.html"
 322           title="8.4. GRUB を用いたブートプロセスの設定">8.4.「GRUB を用いたブートプロセスの設定」</a>
 323           を設定する必要があります。
 324         </p>
 325       </div>
 326     </div>
 327     <div class="navfooter">
 328       <ul>
 329         <li class="prev">
 330           <a accesskey="p" href="kernfs.html" title=
 331           "仮想カーネルファイルシステムの準備">前のページ</a>
 332           <p>
 333             仮想カーネルファイルシステムの準備
 334           </p>
 335         </li>
 336         <li class="next">
 337           <a accesskey="n" href="chroot.html" title="Chroot 環境への移行">次のページ</a>
 338           <p>
 339             Chroot 環境への移行
 340           </p>
 341         </li>
 342         <li class="up">
 343           <a accesskey="u" href="chapter06.html" title=
 344           "第6章 基本的なソフトウェアのインストール">上に戻る</a>
 345         </li>
 346         <li class="home">
 347           <a accesskey="h" href="../index.html" title=
 348           "Linux From Scratch - Version 6.8">ホーム</a>
 349         </li>
 350       </ul>
 351     </div>
 352   </body>
 353 </html>