システム奮闘記:その16

RPMコマンドの使い方



Tweet

(2003年4月3日に掲載)
(2006年10月2日に掲載)
はじめに

  RPMとは「RedHat Package Manager」の略。
  RedHat系Linuxの、パッケージをインストール、アンインストールをしたり、
RPMを使ってインストールしたソフトの管理などをするツールだ。

  さて、単なるRPMの使い方を書いたのでは

  どこが奮闘記やねん!

 全然、おもろないぞ!

  と言われそうだし、単なるRPMの使い方の説明だけなら、
他の方で立派なホームページを作っておられるので、
わざわざ二番煎じで、下手なホームページを作る必要はない。

  敢えて、私が書く理由。
  それは、私がRPMの使い方を知らなかったため

  ソフトのバージョンアップができませんでした!!

  そうなのです。
  サーバーソフトなどのセキュリティーホールが報告されても
RPMの使い方がわからず更新できなかったのです ← 自慢にならんぞ!

  そこで、いつものパターン、失敗談を一挙公開しまーす!!
  題して「RPMの使い方」の巻きのはじまり、はじまり  (^^)


RPMコマンドでインストール

さて、RPMとの出会いは、2000年に社内にLinuxを導入した時だった。 それまでは、Linux(UNIX)でのソフトのインストールは  XXXX.tar.gz型式  のファイルを展開し、READMEやINSTALLなどのファイルに書かれている 手順を読んで、それに従って make するものと思っていた。 実際、学生時代、大学にあったUNIXに、テトリスをインストールして 遊んだ経験がある。 そのため・・・  RPMって何やねん?  だった。 2000年のLinuxサーバーの立ち上げ時にRPMと出会った。 サーバー本には、サーバーソフトのインストールの部分に、 RPMのファイルを使って、インストールする記述があった。 余裕があれば、RPMの事も調べるのだが、この時は、七転八倒の状態で とにかくサーバーの稼働が第一だったので、RPMが何を知る余裕などなかった。 そのため、ソフトのインストールでRPMという方法が書いてあったが、 どういうソフトとか、使い方などか知ろうとせず、本のままコマンドを打って、 それで終わりにしていた (^^;;

カーネルのバージョンアップ

ずーと、それで何も問題なく過ごしていたが、ある日、事態が変わった。 kernel-2.2.18以下のバージョンに セキュリティーホールがある というニュースが流れた時だった。 うちは、Kernel-2.2.16を使っていたため、対応せねばならない。 そこで、カーネルをkernel-2.2.19に、バージョンアップをすることにした。 以前、カーネルをkernel-2.2.14からkernel-2.2.16にバージョンアップする際、 大学時代の後輩H君に簡単なマニュアルを送ってくれたことがある。 その通りに従って、
rpmコマンドを使ってみる
[root@linux]# rpm -ihv kernel-2.2.19-X.Y.Z

 だが・・・

 エラーが出た (TT)

  rpmコマンドの使い方を知らない私。
 エラーの内容を見ただけでは何の事だか・・・

 さっぱりわからへん

  エラーの内容は出したい所ですが、再現しようと思った時には、
手元になく、再現できないため、エラー内容は割愛させていただきます m(--)m

  しばらく放置されることになった ← システム管理者失格だぞ!

RPMのバージョンアップをしてみる

ある日、ふと rpmのバージョンが低いのが原因かもと思った。 そこでバージョンを4に上げることにした。 実は、その時、使っているバージョンが何かは知らなかったが、 最新バージョンをインストールすれば、ええやろという単純な発想を持っていた (^^;; 現在、使っているバージョンも知らずに、最新のバージョンアップする発想。 我ながら、トンデモナイと思った。 結果的には、この時のrpmはバージョン3を使っていたので、4に上げるのは正解だった。 さて、rpm-4.0.2 をインストールしようとした。しかし・・・ なんで、エラーが出るねん (TT) エラーの内容は、次の通りだった。
エラーの内容
[root@server]# rpm -Uhv rpm-4.0.2-6x.i386.rpm
エラー: 依存性の欠如:
        libdb-3.1.soは rpm-4.0.2-6x に必要とされています

  上のエラーを見れば、ライブラリ依存の問題で、db3ライブラリが
入っていないという意味なのだが、そんな知識はあるわけないので、

  内容を見てもチンプンカンプン (TT)

  調べるのも面倒くさい上、その頃、事務の仕事に忙殺されていたため、
そして、再び放置されることになった  ← 兼任の管理者の辛い所。

再度、カーネルのバージョンアップ

カーネルのバージョンアップも、RPMのバージョンアップも断念して、 半永久的に放置されるかに思えた。 だが、2003年1月、重い腰を上げることにした。 理由は、インターネットの回線をISDNからADSLへ切り替えするのに、 どうせならカーネルのバージョンも安全な物にしようと思ったからだった。 比較的時間的な余裕もあったので、この際だからバージョンアップしようと考えた。 折角だからバージョンを、もっと上の kernel-2.2.22にしようと考えた。 さて、後輩H君が作成してくれたマニュアル通りにインストールしようとすると
エラーの内容
[root@server]# rpm -ivh kernel-2.2.22-6.2.2.i386.rpm
エラー: 依存性の欠如:
        mount < 2.10r kernel-2.2.22-6.2.2 と競合します
        nfs-utils < 0.3.1 kernel-2.2.22-6.2.2 と競合します

  チンプンカンプンなので、ネットでバージョンアップの方法を調べる事にした。
  google先生は便利。いくつか見つかった。

  そこには、kernel-2.2.19へのバージョンアップ方法が書かれていた。
  内容を読むと、kernel-2.2.19以降にバージョンアップする際、
次のパッケージをアップデートする必要があると書かれていた。

必要なパッケージ
mount-2.10r-0.6.x.i386.rpm
nfs-utils-0.3.1-0.6.x.1.i386.rpm

  さて、2つのパッケージをインストールと行きたいが、手元にない。
そこで、google先生を活用して探すことにしたが・・・

  なんで、見つからへんねん (TT)

  よく考えると、使っているOSは RedHat6.2。
  だったら、RedHatのホームページからダウンロードすれば、ええやんと思った。
なんで、こんな簡単なことに気づかないのだろう???

  さて、RedHatのホームページでダウンロードの欄を見て探すことにした。

  しかし、見つからへん (TT)

  なんで、私がシステム関係の事をやるとトラブルに巻き込まれるのか。
日頃の行ないが相当悪いのかなぁと思ってしまう・・・。

  しかし、私は関西人。どんな事でも逆手にとってネタにするのは得意分野!

 RPMネタでシステム奮闘記が書けるやん!

 と思った。
  そういえば、手元にkernel-2.2.19が見つからないから、
じゃぁ、kernel-2.2.19をダウンロードして、エラーの吐く内容を
再現してみようと思い、kernel-2.2.19のページを見てみた。

  文章の中には、2つのパッケージの事も書かれていて、
その上、ダウンロードも、できるようになっていた。おー! なんという事だ。
  ネタ探しという横道それた事をやったお陰で見つかったとは・・・。
  私は奮闘記を書くべき運命なのだと思ってしまう (^^;;

  ただ、kernel-2.2.19をダウンロードしようとしても、
見つからないというエラーが出て、ダウンロードできなかったのが残念 (^^;;

  さて、ようやく2つのパッケージをダウンロードできたので、
早速、インストールしてみることにした。

  なんで、エラーが出るねん (TT)

  エラーの内容は、次の通りだった。

エラーの内容
[root@server]# rpm -ihv mount-2.10r-0.6.x.i386.rpm    
エラー: 依存性の欠如:
        rpmlib(PayloadFilesHavePrefix) <= 4.0-1は 
        mount-2.10r-0.6.x に必要とされています
[root@server]# rpm -ihv nfs-utils-0.3.1-0.6.x.1.i386.rpm
エラー: 依存性の欠如:
        rpmlib(PayloadFilesHavePrefix) <= 4.0-1は 
        nfs-utils-0.3.1-0.6.x.1 に必要とされています

  全く、どうして私はエラーに好かれているのか、困ったもんだと思うが、
エラーの内容を見てみるとrpmlib(PayloadFilesHavePrefix) <= 4.0-1と書かれているため、
もしかして、RPMに関する事かなぁと思った。

  そこで、google先生を使って調べてみる事にした。
私の予想通り、RPMの問題だった。

  元々、RedHat6.Xには、RPMのバージョンは3になっている。
  RedHat7.X以降は、バージョンが4になっている。
  最近、配布されるRPMパッケージは、バージョン4が前提で配布されている。
  そのため、RPM4にバージョンアップする必要がある。

  というわけで、RPMの4へのバージョンアップしようと考えるが、
バージョンしようとしても、次のエラーが出てしまう。

       依存性の欠如: libdb-3.1.soは rpm-4.0.2-6x に必要とされています

  幸い、アップデートの方法は、そのホームページに書かれていた。
  まず、次の3つのパッケージをアップデートする必要があった。


RPMのバージョンアップに必要なパッケージ
db3-3.1.17-4.6x.i386.rpm
db3-devel-3.1.17-4.6x.i386.rpm
db3-utils-3.1.17-4.6x.i386.rpm

  さて、ホームページに書かれている手順通りアップデートにした。

アップデートの手順
rpm -Uvh db3-3.1.17-4.6x.i386.rpm
rpm -Uvh db3-devel-3.1.17-4.6x.i386.rpm
rpm -Uvh db3-utils-3.1.17-4.6x.i386.rpm

  結果は、うまくアップデートできた  V(^o^)V
  一度、うまくいくと、ドミノ倒しのように、うまくいく!

  次に、rpm-4.0.2-6x.i386.rpmのアップデートをした。見事、成功!
  そして、RPM4でなかったため、アップデートが失敗した2つのパッケージ
mount-2.10r-0.6.x.i386.rpmnfs-utils-0.3.1-0.6.x.1.i386.rpmの
アップデートも成功した。

  ようやく、kernel-2.2.22のバージョンアップ。

  もちろん成功!  V(^^)V

  これで全てうまくいった事だし、めでたし、めでたし。

  これにて一件落着  システム奮闘記・その16 「完」

  といきたいが、ちょっと待てよと思った。
タイトルにもある通り「RPMの使い方」なのに、今までの話の流れは
kernelのバージョンアップに話題になっている。
  そういえば、rpmコマンドを使う時の、オプションの意味などを
全然理解していない。その前に知らない・・・  (--;;
  ということで、google先生を使って探してみることにした。

RPMのオプション
オプション結果
-ihvインストール
-Uhvパッケージのアップデート
-eパッケージの削除
-qインストールされているパッケージのバージョン情報
[root@myhome]# rpm -q kterm
kterm-6.2.0-14

オプションに「i」を追加すると詳細情報がでる
-qlそのパッケージに属するファイルの出力
[root@myhome]# rpm -ql kterm
/etc/X11/wmconfig/kterm
/usr/X11R6/bin/kterm
/usr/X11R6/lib/X11/app-defaults/KTerm
/usr/X11R6/lib/X11/ja_JP.eucJP/app-defaults/KTerm
/usr/X11R6/man/ja_JP.eucJP/man1/kterm.1x.gz
/usr/X11R6/man/man1/kterm.1x.gz
/usr/doc/kterm-6.2.0
/usr/doc/kterm-6.2.0/DEMO.kt.uu
/usr/doc/kterm-6.2.0/DEMO.xbm
/usr/doc/kterm-6.2.0/README.kt
/usr/doc/kterm-6.2.0/kterm.termcap
/usr/doc/kterm-6.2.0/kterm.terminfo
--helpへルプ
--versionRPMのバージョン情報

  これ以外にもオプションはあり、ソフトの削除、現在、インストールされている
ソフトよりも、バージョンの低いソフトのインストールなどがある。
  でも、それは他の人が制作された立派なホームページにお任せします (^^)

  上の表を見ると「なるほど」と思った。
  オプションで私は-ihv-Uhvの違いを知らなかった。
  ソフトのアップデートの時、kernelは-ihvで、他は-Uhvになっていたので、謎だった。

  db3をインストールした時、これはバージョンアップなので、-Uhvを使った。
  そのため、rpm -Uhv db3-3.1.17-4.6x.i386.rpmとなる。

  kernelのバージョンアップの場合。実は、-ihvを使う。
理由は、古いkernelと共存させる仕組みになっているので、上書きするのでなく、
別のバージョンを追加するという感じになる。
  /etc/lilo.confのファイルに書き加えて、例え、新しいバージョンが
起動時などにカーネルパニックになっても、旧バージョンで動くようにできる。
  安全のための処置。そのため、 rpm -ihv kernel-2.2.22-6.2.2.i386.rpmとなる。

  実際、カーネルのあるディレクトリー /boot を見ると

/boot での ls コマンド入力結果
[root@myhome /boot]# ls
vmlinuz-2.2.16-22

  カーネルはvmlinuz-(バージョン)という形で保存される。
そのため、違うバージョンのカーネルと共存させる事は可能になる。
  カーネルの場合、バージョンアップなのに、rpmコマンドではインストールの
オプションを使う理由は、ここにある!

(注意)
  カーネルの違うバージョンの共有ですが、同じ Kernel-2.2系や
kernel-2.4系同士の場合であって、kernel-2.2.22とkernel-2.4.20とが
共存できるかと言えば、わっかりませ〜んと答えます (^^;;
  こんな事を書くと「まともに検証しろ!」と言われそうですが、
そういう突っ込みには、こう答えます。
「環境が貧相なので、誰か私のために、サーバーを買ってください (^^)」

(参考までに)
2003年の、SoftwareDesign4月号のP154にカーネルのバージョンアップが
書かれています。リスト1を図を見ると /etc/lilo.confの設定で、
kernel-2.2.16とkernel-2.4.20とを共存させる設定になっている。
検証はしていないが、本に書かれているため、多分、可能だと思う (^^;

(2006/10/2追加)

実際に、2.4系と2.6系の共存は可能です。

もし、カーネルのバージョン変更に伴い、システムコールの仕様に
変更がある場合には、不具合が生じる事も考えられますが、
その心配もなさそうですから。

  ちょっと余談になるけど、新しくインストールするソフトは-ihv。
  でも、-Uhvを使っても問題はないみたい。
(一応、私が使っているマシンでは大丈夫だった)


  さて、kernelのバージョンアップに、そんなに遠回りせにゃアカンのかと考える。

  最初、kernelのバージョンアップの際、こんなエラーが出ていた。

エラーの内容
[root@server]# rpm -ivh kernel-2.2.22-6.2.2.i386.rpm
エラー: 依存性の欠如:
        mount < 2.10r kernel-2.2.22-6.2.2 と競合します
        nfs-utils < 0.3.1 kernel-2.2.22-6.2.2 と競合します

  エラーの内容は、なんとなく、 mount や nfsに問題がある事は、わかる。
しかし、うちの会社でNFSは構築していないため、必要はない。
  なのに、なんでエラーが出るのか疑問だった。

  そこで、RedHatのホームページのkernel-2.2.19の記述を見てみた。

記述内容
NFS バージョン3がサポートされたことにより、以前のバージョンにくらべて
性能が向上しました。この新しい NFS を利用するには
nfs-utils, mount 両パッケージのアップデートも必要となります。

  なるほど、だから次のパッケージの更新も必要なんだと思った。

このパッケージの更新も必要だと思った。
mount-2.10r-0.6.x.i386.rpm
nfs-utils-0.3.1-0.6.x.1.i386.rpm
             
  更新の要があったのかとと思った。

 が、しかし、ちょいと待てよ!

  NFSのバージョン3がサポートされるようになったと書いているのに、
なんで、パッケージを追加せねばならないのか?
  カーネルの中に組み込まれているはずではないのか?
  ここは、キチンと謎解きしないと・・・

 ちゃんと調べんかい!

 と言われそうだが、とても調べられるだけの知識や技術はないので

 忍法「先送りの術」

 を使って逃げます。

 いずれカーネルを触れるぐらいの知識が身につけば、触れたいと思います。

  
  rpmのバージョンアップの時、db3-3.1.17-4.6x.i386.rpmのアップデートがあった。
  ふと思った。このパッケージ、何のための物なの???

  db3とは何か?  気になるのらー!!

  ということで調べてみると、バークレーデータベースというライブラリーだった。
  これだけだと「だから何やねん! 具体的に説明せんかい!」となる。

  db3は、Linux(UNIX)のC言語のライブラリーの1つで、プログラムの中に、
データを格納するデータベースが必要な時に使う。
  プログラムの最初に#include <db.h>を入れる。
  こんな事を書くと「どんなデータベースやねん!」とか「特徴は何やねん」と
聞かれそうなので、私は、こう答えます。

   わかっていたら、最初から、こんな事、書きませ〜ん(^^)
   違いが説明できたら、今頃、技術者になってま〜す(^^)

  忍法「ごまかしの術」で、うまく逃げた私。

  でも、ちょっとは勉強したという事で、格好つけたいので、
忍法「受け売りの術」を使って説明しまーす!
  db1は、2分探索やハッシュが使える単純なデータベース。
  ここでバージョンアップしたdb3だと、ロック機能などがあるという。
  db3はPostgreSQLやMySQLのような大掛かりなデータベースでないため、
ちょっとした事に便利みたい。
  もっともらしく書いたけど、実際には、db3を使ってプログラム経験がないため
これ以上、説明なんて書くと、忍法「受け売りの術」が完璧に見抜かれ、
私の無知が露呈されるので、この辺で説明にして。

忍法「受け売りの術」・その2 (2006/10/2追加)
dbですが、C言語で作る簡易データベースファイルの作成・更新等の
ライブラリです。
キー探索という単純なデータ検索ぐらいで、SQL文は使えませんが、
PostgreSQLやMySQLのような大掛かりなデータベースを導入しなくても、
データ管理ができる点が利点です。

詳しくは「Linuxプログラミング」(葛西重夫 訳:ソフトバンク)を
ご覧ください。

  まぁ、詳しい話は、もっと私が精進して、活用した時に説明するとして、
どうやら、rpmは、データベース(db)を使うことがわかる。
  ここは私の推測ですが、rpmでインストールしたソフトなどは
rpmで管理できるようになっている。インストールしたソフトのデータを
格納するために、データベースが使われていると考えられる。

  実際、RPMはソフトの管理まで行なっている。
 (ただし、rpmコマンドを使ってインストールした、ソフトだけですが・・・)

RPMのコマンドを入力した結果
[root@server]# rpm -qi apache
Name        : apache                       Relocations: (not relocateable)
Group       : システム環境/デーモン         Source RPM: apache-1.3.12-2.src.rpm
apache は、強力かつ高機能で効率の良い、フリーの Web サーバです。また、
apache はインターネット上でも最も広く用いられている Web サーバです。
Web サーバが必要な場合は、apache パッケージをインストールしてください。

  rpm -qi (該当ソフト名)のコマンドを使うと、
rpmでインストールした該当ソフトの情報が出てくる。
  これらのデータを扱うのにdb3のデータベースを使っていると思う。

注意!
  上の枠内の内容を見て「Apacheのバージョンが古い! あぶないぞ!」という
突っ込みはしないでくださいね (^^)
  その理由は、Apacheのインストールやバージョンアップはrpmでしていないからです。
  apache-1.3.x.tar.gz形式のファイルを展開してコンパイルしてインストールしています。
  理由は、そっちの方が私にとって管理しやすいため (^^)
  Linuxのインストール時に、apacheも入れているため、rpmではOSインストール時の
バージョンが記録されるが、tar.gz形式でインストールしなおした場合、記録されない。
  そのため、Linuxのインストール時に、同時にインストールされるApacheのバージョン
が記録されたままになる。

  さて、rpmのバージョンを4に上げる際、次のエラーが出ていた。

      依存性の欠如: libdb-3.1.soは rpm-4.0.2-6x に必要とされています

 最初、「なんでlibdb-3.1.soと、db3とが関係あるんかいな?」と思っていた。
 よく見ると「libdb-3.1.so」なので、納得できた。
 ここで、ようやくエラーの内容が意味が、わかった。

      rpm-4.0.2-6xにバージョンアップするには、db3が必要という意味だった!


  RPMの使い方を覚えるのは楽じゃないなぁと思っていたら、
ふと、また疑問が出てきた。

  
  さきほど、バークレーのデータベースのライブラリーをインストールした時、
ライブラリーの本体(db3-3.1.17-4.6x.i386.rpm)以外にも次のパッケージを
アップデートしていた。

            db3-devel-3.1.17-4.6x.i386.rpm
            db3-utils-3.1.17-4.6x.i386.rpm

  なぜ、本体とは別にアップデートする必要があるのか?
  develutilsには、一体、どんな意味があるのか疑問に思う。

  調べてみると、あまり納得のいかない答えしか得られなかった。
  db3-devel-3.1.17-4.6x.i386.rpmは、db3の開発のためのへッダーファイルなど。
  db3-utils-3.1.17-4.6x.i386.rpmは、db3のライブラリーのツール。

  どうも腑に落ちない・・・。

  そういえば、カーネルのアップデートでも同じことが言える
  カーネルの場合も、こんだけオプションみたいなパッケージがある。

カーネル関係のパッケージ
kernel-2.2.22-6.2.2.i386.rpm
kernel-BOOT-2.2.22-6.2.2.i386.rpm
kernel-doc-2.2.22-6.2.2.i386.rpm
kernel-headers-2.2.22-6.2.2.i386.rpm
kernel-ibcs-2.2.22-6.2.2.i386.rpm
kernel-pcmcia-cs-2.2.22-6.2.2.i386.rpm
kernel-smp-2.2.22-6.2.2.i386.rpm
kernel-source-2.2.22-6.2.2.i386.rpm
kernel-utils-2.2.22-6.2.2.i386.rpm

  色々あるが、しかし、これを全部入れる必要がない。
  後輩H君の資料だとkernelが必要で、kernel-headersは多分必要、
カーネルを触りたい時はkernel-sourceは必要と書いてあった。

  さて、こういう時にRPMコマンドが威力を発揮する。
  習った事のおさらいで、rpm -q -i (パッケージ名)を使って、
パッケージの情報を見てみることにする。

  kernel-2.2.22-6.2.2.i386.rpmはカーネルの本体。
  kernel-headers-2.2.22-6.2.2.i386.rpmはLinux用のC言語のへッダーなどが入っていて、
カーネル再構築などで必要な構造体や変数がある。
  rpm -q -i (パッケージ名)を使うと、多少なりともパッケージの意味がわかる。

  これで見ると本体のkernel-2.2.22-6.2.2.i386.rpmは絶対に必要。
  カーネルの再構築など、手を加えたい場合はkernel-headers-2.2.22-6.2.2.i386.rpmが必要。
  カーネルのソースが必要な場合はkernel-source-2.2.22-6.2.2.i386.rpmは必要。

  ところで、なぜ、RPMの場合、一つにまとめないでバラバラにするのは、わからない。
  あと、カーネルの再構築には何が必要だとかの話も出てくる。
もちろん、調べないといけないが、どんどん話が脱線していくので、
カーネル再構築の話を取り上げる時にでも書きたいと思います (^^;;


(2006/10/2追加) さて、上の部分で「カーネルの再構築など、手を加えたい場合は kernel-headers-2.2.22-6.2.2.i386.rpmが必要。」 と書きました。 この部分で、2003年6月4日に、ソフトウェア工学の専門家で 中学の時の友人Y君から以下の指摘を受けた。
友人Y君からの指摘 (2003/6/4)
1) カーネルヘッダが必要な理由.
   × カーネルの再構築
   ○ システムが提供するデータ構造, 関数を扱うプログラムの
      コンパイル時に必要.

      例えば, ネットワーク関係とかで, 自分の計算機の
      IP アドレスやホスト名を調べるプログラムを書きたい
      ……と思ったとします.

      すると, カーネルヘッダで定義されたシステム提供の関数
      や構造体を使ってプログラムを書く事になるのですね.


      なお, apache 等のフリーソフトをコンパイルする時にも必要です.
      (これらのソフトは中でシステム関数やシステム構造体を
       大抵使っています.)

2) カーネルヘッダが別パッケージの理由
   ヘッダファイルの中身が変わると面倒な事があるから.
   改版によって, システム関数の引数が変わったり
   構造体のデータ構造が変わったりするのです.

   これが起こると, 昔コンパイル出来たプログラムが
   いきなりコンパイルできなくなったりするので,
   非常に困る事があるのです.

  「× カーネルの再構築」という文字を見て、私は以下のメールをY君に送った。

Y君への返事
>× カーネルの再構築

  知らなかった。思わずNOVAうさぎの表情。
  これについて、誰も指摘しなかったため、大丈夫だと
  安心していたがそうではなかったのだなぁ。

  当時、NOVAのCMでは、NOVAうざぎが「 (--;; 」の表情をしていたのだ。
  すると翌日、Y君から以下のメールがやってきた。

Y君からのメール
>  知らなかった。思わずNOVAうさぎの表情。
>  これについて、誰も指摘しなかったため、大丈夫だと
>   安心していたがそうではなかったのだなぁ。

カーネルの再構築にも必要なんですけどね….
それは嘘ではないです. だから×ではなくて△かも.

あと, ヘッダが別パッケージになっている理由, 昨日
いい加減に書いたけど, あれは納得して頂けました?


版が変わると関数の引数やデータ構造が変わる事がある.
これが困る.

 → 例えば, 古いカーネルでも動くプログラムを
    新しいカーネル上で作りたい……と思ったら,
    古いカーネルのヘッダファイルを見て作らないと行けない.
    ……という事ね.

    カーネルのヘッダだけが欲しいと言う需要もあるのです.


    色々バージョンのヘッダを見て, 新しいデータ構造を使う
    ソースと古いデータ構造を使うソース双方を作っておいて,
    ユーザがコンパイル時に使える方を選択してコンパイルするの.

    (最近のフリーソフトは make の前に Configure とかやるでしょう?
     あれでどの関数, データ構造が使えるのかを調べているのです.)

  しかし、この時点ではメールの内容が理解できない私。
  なので、この指摘を盛り込んだ編集ができなかった (--;;


  だが、2006年になり、ようやくメールの内容を理解できた。
  ヘッダーファイルには、関数の引数の数や、引数の型を記述している。
  つまり関数の仕様を伝える役目がある。

  それ以外にも、ヘッダーファイルのは、データ構造を定義する役目もある。
  カーネルの場合なら、プロセスの状態を表すプロセスディスクリプタなど
ヘッダーファイルに記述しているのだ。

  もし、カーネルのバージョンが変更になり、関数やデータ構造の仕様も
変更になった場合、過去のバージョンとの整合性がとれなくなる。
  そこで、古いカーネルのシステムコールを使って動く
ソフトを作成するためには、古いバージョンのカーネルのヘッダーが
必要になってくる。

  Y君のメールの内容を3年後に理解できたので、良かった、良かった (^^)


RPMファイルの種類について (2006/10/1) RPMファイルには、プログラムやライブラリ本体だけでなく ヘッダーなどがまとめたファイルなどがあります。 今回の話の中に出てきました db3ライブラリについてですが、 ライブラリ本体のRPMファイルは db3-3.1.17-4.6x.i386.rpm です。 このライブラリを活用するソフトをRPMで入れる場合には、 全く問題はありません。 しかし、db3のライブラリに依存するソフトやライブラリを作成し コンパイルを行う場合、db3ライブラリが提供する関数の仕様や データ構造が見えません。 なぜなら、db3に関するヘッダーファイルがインストールされていないためです。 そこで、関数の仕様やデータ構造を記述したヘッダーファイルを始め db3ライブラリを活用するプログラム開発に必要な物を入れたファイルは db3-devel-3.1.17-4.6x.i386.rpm です。 「devel」とは、development(開発)の略で、ソフト開発の時に 関数やデータ構造が必要な事から、ヘッダーファイルには 「devel」をつけています。 RedHat7.2で、PHP4.0をインストールする場合でしたら、本体は php-4.0.6-15.i386.rpm のファイル名ですが、これですと PostgreSQLなどにアクセスしたりする事ができません。 RPMを作成する時に、ライブラリに依存しないようにしているためです。 そこで、PostgreSQLにアクセスできる、つまりPostgreSQLへの アクセス関数を使えるようにするパッチ(?)みたいなファイル php-pgsql-4.0.6-15.i386.rpm をインストールします。 LDAPを使いたい場合は、php-ldap-4.0.6-15.i386.rpm もインストールします。 このように、他のライブラリを活用して、その機能を使う場合には 本体以外にも、パッチみたいなファイルが配布されている事もあります。
まとめ RPMとは、パッケージのインストールやアップデートをするだけでなく、 パッケージのバージョン管理から、パッケージの情報管理まで行なう便利なツール。 使いこなせたら便利だが、不便な時もある。 パッケージを入れた際、設定ファイルのディレクトリーの場所の問題がある。 Apacheの場合、tar.gz形式の物をコンパイルをかけてインストールすると、 /usr/local/apacheにインストールされる。 もちろん、コンパイル作業の際に、変更も可能! しかし、RPMだと、/etc/http/に設定ファイルが格納される。 そのため、混乱することもある。私は混乱したため、Apacheのインストールは 絶対にRPMは使わない。 でも、RPMは道具としては便利なので、自分が使いたいと思った時に 使うのが一番だと思います。

次章:「Microsoftネットワーク入門(NetBIOS over TCP/IP)」を読む
前章:「システム時間と時間が狂う問題」を読む
目次:システム奮闘記に戻る

Tweet