このエントリーを含むはてなブックマークはてなブックマーク - Debianへの畏敬: 厳格なパッケージ管理、譲らないこだわり このエントリをつぶやくこのWebページのtweets Googleブックマークに追加 Bookmark this on Delicious
  • 今回のエントリは、私u-bonの私見で書いています。試案的なカンジです。
  • 記載事項には、憶測、誤解、認識不足で記述してしまっている部分があろうかと思います。
  • その点を、識者の皆様から、ご指摘いただければと、切に願っております。

■”厳格”という素晴らしさ

元々、Debianをベースとして開発されているUbuntu。
その定評ある使いやすさは、2008年で発足以来15周年を迎えたDebianの開発に携わってきた、皆さんによる貢献の積み重ねが”源泉”と言っても過言ではないでしょう。

優れた技術者の皆さんが、ボランティアとして集い、自らの理想をDebian憲章として掲げ、”清流”の中で研ぎ澄まされ、開発されたフリーなOSは、激流を経ながらも、”Ubuntu”という名のダムの建設により、その流れはやがて穏やかな中流に流れ込み、その豊かな川そばに集い始める人々に、豊かな恵みをもたらす”大河”として、新たな文明を育みつつあるのだろう・・・というのがハタから見ている私にとっての印象です。

Ubuntuの上流で産まれ、育まれたDebianの”Soul“を感じさせるのは、やはり、その「パッケージシステム」。

前のエントリでも書いたように、「依存関係」の崩壊はシステムの崩壊につながってしまいます。
このような崩壊の恐れがあるシステムでは、あれもこれも・・・と欲張った用途を求めてしまうような使用には向きません。それは、デスクトップ環境の場合にもっとも当てはまります。
自分で復旧させる知識とスキルを持ち合わせていようとも、解決のためには、膨大な時間と手間を強いられ、結局はクリーンインストールした方が早くなってしまいます。

実の所、これこそが、私がUbuntuに出会うまで、デスクトップPC環境として、Linuxベースのディストリビューションを採用しなかった本当の理由です。

他のディストリビューションを使い込んでいく中で、たくさんのアプリケーションをインストール、アンインストールを繰り替えしていくうちに、知らず知らずのうちに、この依存関係が崩壊していってしまうことがよくあります。
これはパッケージ管理システムに”寛容性”があるためと言えるのではないでしょうか?

ところが、Ubuntuが属するDebian系の場合には”厳格“です。いったん依存関係が崩れてしまうと、それを解決しない限り、パッケージ構成に変更を加える作業を受け付けなくなります。
まるで、”腐ったミカン“を即座に取り除くことを求められるようです。

そして同時に、Ubuntuの上流に位置するDebianプロジェクトでは、パッケージの競合、依存関係をバージョン毎に非常に厳格に管理されています。
これにより、”雲の上の世界“でも、サーバ上に格納されるパッケージの中には”腐ったミカン”が置かれないような体制が取られています。
一見頑固とも思えるこのポリシーは、問題を即座に発見し、影響を全体に及ぼさないという点で、かえってありがたいものです。

■依存関係が崩れてしまった時の修復コマンド

何らかの原因で依存関係が崩れてしまった時には、以下のように「-f」(fix=修理)オプションを用いたコマンドで修復を試みます。

sudo apt-get -f install

では、どんな時に「依存関係」は崩壊してしまうのでしょう?起こりがちなのは、次のような場合ではないでしょうか?
(他の例があれば、ぜひ、ご指摘ください。)

・依存関係を無視してパッケージのインストールを行った場合

dpkg、apt-get共に、「–force」オプションで、依存関係を無視してアプリケーションのインストールができてしまいます。
また、後述のように、ソースをコンパイルして導入した場合などがあります。

こうしたからといってすぐにシステム全体がイカれるわけではありませんが、積み重なるとジワリジワリとボディーブローのように効いてくる・・・と言ったカンジでしょうか。

・システムのアップデート中、アプリケーションのインストール中に作業を強制中断してしまった時

一番多いのがこれですね。
イケないのが、インストールが終わらない事にイラついて、いきなり電源をプチっと切ってしまう短気。
あとは、ノートPCでバッテリーで稼働中に、システムアップデートの際に、インストール行程でいきなりバッテリーが切れてしまった時・・・

さて、Debianのパッケージ管理については、下記のドキュメント「Debian リファレンス」に詳細が記されており、ここに記載されていることは、Ubuntuで流用することができます。

Debian リファレンス 第 6 章 – Debian パッケージ管理

“使いやすさ”が半年毎に進歩するUbuntu。
それは、Debianによって培われている”こだわり”と、それに裏打ちされた”技術”に支えされている
・・・という事を念頭におきながらドキュメントを読めば、理解がしやすいのではないかと思います。

■「apt」以外にもある、Debianのパッケージ管理ツール

今の所、「apt」だけでも、ほぼ十分使いこなせるかとは思いますが、この中の記述にある通り、Debianのパッケージ管理ツールには、「apt」以外にもいくつもあります。

synaptic – APT の Gtk GUI フロントエンドとしてお馴染み
apt-get – APT のコマンドラインフロントエンド
dpkg – Debian パッケージファイルインストーラ

aptitude – APT の先進的なコンソール版コマンドラインフロントエンド
dselect – メニュドリブンなパッケージマネージャ
tasksel – タスクインストーラ

■dpkg:Debianパッケージファイルインストーラ

「apt-get」コマンドが、Redhat系の「yum」に相当するコマンドだとすると、Redhat系の「rpm」に相当するDebian系のコマンド体系は「dpkg」となります。

使い方はこのドキュメントを参照していただくとして、知っておくと便利(と思われる)コマンドを記します。

・システムに導入済みのパッケージを一覧表示させる

dpkg -l

「-」はオプションを意味し、「l(小文字のエル)」は”list”の略。
システムにインストールされているパッケージを一覧で表示させるコマンドです。

表示項目があまりにも量が多いので、

dpkg -l | less

・・・とするといいでしょう。
「less」は結果を一画面毎に表示するコマンドです。矢印キーやスペースキーで表示のスクロールができます。
「|」(縦棒=パイプ)はコマンドのつなぎ役。左側で指示したコマンド結果にさらに続きで処理させる場合に用います。

・パッケージの設定に問題が生じた場合のコマンド

アップデートが失敗した際なので、以下のコマンドを試してみるように画面で案内が出る事があります。

sudo dpkg –configure -a

  • 現状のLPICレベル1の問題では、aptよりもこのdpkgの方が多く出ています。
  • ここでは解説しませんが、rpmコマンド同様に、コマンドオプションも含めて、習熟しておく必要があろうかと思います。

■APT の先進的なコンソール版コマンドラインフロントエンド:「aptitude」


APTのコマンドライン・フロントエンドとして、先進ユーザに用いられているのが「aptitude」。
「apt-get」、「synaptic」では手が届かない所まで補完するツールとなっています。

例えば「apt-get」でパッケージ導入した時に「依存関係」があるパッケージも一緒に導入されている場合、アンインストールを行った場合、不要となったパッケージが孤立ファイルとして残ってしまうことがあります。
aptitudeでは、このような依存関係でインストールされただけのパッケージについては、その依存関係がなくなると自動的にアンインストールするといったことも可能となっています。
また、単独で「deb」ファイルをdpkgコマンドで導入した際の情報も把握してくれます。

このように「apt-get」よりもさらに便利な「aptitude」は、apt-get の代わりのコマンドラインコマンドとしても使えます。
ただし、一度aptitude を使いはじめたら、他のパッケージをインストールする手段を用いずに使い続けないと、意味がありません。
パッケージのインストール、アンインストールの際にSynapticも併用するといった場合、上記のようなメリットは享受できなくなってしまいます。

詳細なドキュメントは、 file:///usr/share/doc/aptitude/README で参照できます。

■「新たな責任の時代」のOS

さて、オープンソースという開かれた環境の中で、この「依存関係」を保とうとする行為というものを、改めて考えてみると、その活動の大変さ・・・というものは、私のような「下流域に生息」するものにとっては、想像すら難しいものです。
「下流域」という多くの人々が日々の営みを過ごす領域で、創造的な活動を行ったり、ビジネスを営むための”耕具”は、”使いやすい”ものである事はもちろん重要ですが、”信頼できる”ものであることは、さらに重要な条件であると言えるでしょう。

さらに言うと、MS社 & それを取り巻く企業群のように、何から何まで面倒を見てくれるOS & アプリケーションの世界とは違って、オープンソースの場合には、信頼できる上流に「何を求めるか?ではなく、自分たちには何できるか?」を考えていく事が重要なんだなぁと、つくづく感じてしまいます。

「新たな責任の時代」という概念は、日常用いるデスクトップOSの世界にもすでに訪れつつあるように思えてならないのは私だけでしょうか?

Related posts:

  1. Ubuntu7.10β 64bit版のバグへの対処法1
  2. 6.10から7.04へのアップグレード、依存関係の修復
  3. medibuntuがUbuntu 7.10(Gutsy Gibbon)に対応
  4. medibuntuがUbuntu 7.10(Gutsy Gibbon)に対応
  5. オイラのマシンは今どーなってんだっけ?