Linux/UNIX バイナリパッケージ形式の比較

原文 (注意: 原文はこの翻訳よりも新しくなっています。)
元々の日本語訳

このページは deb, rpm, tgz, slp, pkg のパッケージ形式の比較で、それぞれ、 Debian, Red Hat (とその他), Slackware, Stampede, Solaris で使われています。(pkgはSVr4パッケージ形式です。Solarisで使われます)私は パッケージのビルドや利用について、 Alien というパッケージ変換ツールを用い、いくつかの実験を行いました。

私は Debianの開発者で、deb 形式が好きなのですが、公平な比較をし記録しました。もし、この比較に偏見や間違い、もしくはパッケージ形式の重要な特徴を忘れているのを見付けたら メールで教えてくれれば訂正できます。何人かの人がすでにそうしてくれてます。また、データが十分でないところには '?' マークで示してあります。

この比較はパッケージ形式だけで、パッケージの管理やインストールなどを行うツール(dpkg, rpm やその他)の比較ではありません。

パッケージ形式の比較表

機能debrpmtgzslppkg
セキュリティ、認証や確実性
パッケージに対するPGP署名*1×××
照合××
パーミッション, オーナーなど
標準的なLinuxツールでの利用
fileコマンドでの確認××
標準的なツールでの展開×*2×
メタデータへのアクセス×N/A××
標準的ツールでの作成×××
メタデータ
名前×
バージョン×
説明
依存関係×
推奨××××
提案××××
競合×
仮想パッケージと提供×??×
バージョンによる依存と競合×??
複合的な依存関係*3×××
ファイルによる依存××××
著作権情報×*4×
グループ化××
優先度×××
特殊ファイル
設定ファイル×
ドキュメントファイル×××
ゴーストファイル××××
パッケージプログラム
バイナリプログラムの許可×??×
インストール前処理×*5×
インストール後処理
削除前処理×*6×
削除後処理×
確認プログラム××××
トリガー××××
拡張性
ハードコードされた制限がない*7××
新メタデータ*8N/A××
新セクション××××
フォーマットバージョン××

どのような比較か

セキュリティ、認証や確実性

このセクションは パッケージが誰によって作られたかの確実性、そして、システムにインストールされたパッケージについて そのインストール後、どのようにファイルが変更されたかをチェックすることができるかどうか を比較します。

  • パッケージに対するPGP署名
    パッケージにPGP署名を埋め込み、そしてだれが作ったものなのか確認できる
  • 照合
    パッケージに含まれている全てのファイルについて照合できる
  • パーミッション, オーナーなど
    パッケージに含まれるファイルの情報として、正しい権限、サイズ、オーナー、グループ メジャー・マイナー番号(デバイスファイルの)があるか

標準的なLinuxツールでの利用

パッケージ管理ツールを使わないで、パッケージの中身を見ることができるかどうかは重要なことで、このセクションでは それぞれのパッケージがLinuxシステムにある標準的なツールで処理できるかどうかを比較します。 *9

  • fileコマンドでの確認
    パッケージ形式を file コマンドで確認できるか?
  • 標準的なツールでの展開
    難解な操作を必要とせず、標準的なツールでパッケージを展開できるか。 (難解かどうかという条件を追加したのは、ここでの展開できるというのは、たとえば、vi で プログラムを書き、そして cc でコンパイルしてパッケージの展開をする とか、 20行ほどのシェルスクリプトを書けばパッケージを展開できる という意味ではないからです。展開は、すばやく完了できて、その操作を覚えるのは簡単でなくてはなりません。)
  • メタデータへのアクセス
    パッケージ含まれているメタデータ(パッケージ名、詳細、バージョンなど)が整理されていて、それらへのアクセスが標準的なツールで難なくできるか
  • 標準的ツールでの作成
    パッケージを 難なく 標準的なツールで作成できるか

メタデータ

メタデータは パッケージが含んでいる、そのパッケージについての情報の項目で、パッケージ名や詳細、バージョンなども入れます。

  • 名前
    パッケージのメタデータに名前を持っていますか。
  • バージョン
    パッケージのメタデータにバージョン番号を持っていますか。
  • 説明
    パッケージのメタデータに説明用の場所がありますか。
  • 依存関係
    依存関係は、そのパッケージが正しく動作するために別のパッケージのインストールが必要とされるかどうか の情報です
  • 推奨
    パッケージの正しい動作のために、別のパッケージのインストールを推奨できるかどうか
  • 提案
    提案とは、パッケージがよりよく動作するために、別のパッケージのインストールを 提案するということで、これをユーザーは FYIとして知ることができる
  • 競合
    競合は、別のすでにインストールされているパッケージがあるとインストールできない関係で、その一般的な理由として、その二つのパッケージが同じファイルを含んでいるなどです。
  • 仮想パッケージと提供
    これは、たとえば 「ウェッブブラウザ」、「メール配送システム」 のような仮想パッケージを 提供できるかどうかで、他のパッケージはこれら仮想パッケージに依存することができる。
  • バージョンによる依存と競合
    パッケージの依存関係を 特定のバージョンによって設定できるかどうかで、さらに、 < や > を用い、バージョンを指定できるか。
  • 複合的な依存関係
    これは、パッケージが 他のパッケージや、また3つ以上のパッケージに依存関係をもてるかどうかです。
  • ファイル依存
    これは パッケージに依存するのではなく、他のパッケージが含んでいる、たとえば /bin/sh などに依存できるかどうかです。 *10
  • 著作権情報
    パッケージのメタデータが 基本的な著作権情報を含むかどうかこれは 自動的な著作権の整理に役に立ちます。
  • グルーピング
    パッケージが グループを定義できるかどうか (たとえば ウェブブラウザ、ライブイラリなどの)で そのグループは パッケージリストの閲覧などに利用する。これは、大きいパッケージのグループの処理を楽にする。
  • 優先度
    パッケージに優先度を設定できるかで、それはシステムにおいてどのくらい重要かどうかを示す。たとえば、高い優先度のパッケージは注意深く設定を見るべきであるが、優先度の低いものは設定を省略でき、 UNIXシステムを単純にインストールできるようパッケージシステムが知ることができるでしょう。

特殊ファイル

この属性は ファイルがどういう目的のものなのかを分別し、特殊な用途で処理することができるかどうかです。

  • 設定ファイル
    設定ファイル属性がサポートされているか。これら設定ファイルは ユーザーが必要に応じて編集するが、新しいバージョンのパッケージがインストールされる時、変更された設定ファイルを残したり、また、上書きする場合バックアップをとるなどの管理ができるようにします。 (もうすこしこまかくしたほうがいいだろうか?)
  • ドキュメントファイル
    ドキュメントファイルを特殊ファイルと設定できるか。これは ユーザーがヘルプやドキュメントの検索に役に立つ。
  • ゴーストファイル
    ゴーストファイルは 実際のインストールではパッケージはファイルを提供しないが、パッケージが含むファイルとして設定する。これはログファイルの管理などに役に立つ。

パッケージプログラム

パッケージがインストール、アンインストールなどされるときに、実行されるパッケージに含まれるプログラムです。

  • バイナリプログラムの許可
    スクリプトもしくは コンパイルされたバイナリプログラムを利用できるか
  • インストール前処理
    パッケージをシステムにインストールする時に、インストールする前にパッケージマネージャにより実行されるプログラム
  • インストール後処理
    パッケージをシステムにインストールする時に、インストールした後にパッケージマネージャにより実行されるプログラム
  • 削除前処理
    パッケージをシステムから削除する時に、その前にパッケージマネージャにより実行されるプログラム
  • 削除後処理
    パッケージをシステムから削除する時に、削除後にパッケージマネージャにより実行されるプログラム
  • 確認プログラム
    パッケージマネージャにより実行される、インストールされた状態のパッケージの確認プログラム
  • トリガー
    これは、パッケージ状態の変更の種類によって、プログラムをどう実行させるかを設定できるかどうかです。

拡張性

将来の必要性により、パッケージ形式がどのようによくなりえるか。これは 非常に重要です。このセクションでのおおくは、わずかな値の比較でしかない。なぜなら、拡張性の高いパッケージフォーマットであれば新しいパッケージプログラム、メタデータ項目、その他は簡単に追加できるからである。

  • ハードコードされた制限がない
    パッケージフォーマットにハードコードされた制限がありませんか?それは将来のニーズに応じた拡張の妨げになるでしょう。たとえば、パッケージ名またはバージョンのサイズは無制限ですか?
  • 新メタデータ
    パッケージ形式の変更なしに、メタデータに新しい項目 (テキスト、バイナリデータ、など)を簡単に追加できるか
  • 新セクション
    パッケージ形式の変更なしに、新しいセクションを追加できるか。たとえば パッケージ形式の 「PGPサインをつける」などの拡張や「異なる最適化、異なるアーキテクチャのためにコンパイルされた2番目のデータセット」を持たせたり。これはフォーマットがどれくらい柔軟かという最終的なテストです。それは思いがけない新しい必要条件に対処するように設計されていますか?
  • フォーマットバージョン
    これはパッケージを見てどのバージョンのパッケージ形式を利用しているかを知る方法です。極端な話、全てのパッケージ形式を捨てて再設計しても、古いツールが、取り扱うことの出来ないパッケージ形式のパッケージであることを読みとることができるというような意味です。

Todo.

  • パッケージの再配置
  • メタデータにおける、アーキテクチャ名、アーキテクチャ非依存パッケージのサポート
  • 同じパッケージの複数バージョンのインストール可否 (これは本当にパッケージ形式の問題なのか?)
  • info available to package programs -- The programs may find various information useful to make decisions while they are running. Of course, all of them can look at what's currently on the filesystem, run other programs and look at the output, etc. This lists other information that may be useful. (old package version, etc)

Copyright 1998, 1999 by Joey Hess under the terms of the GNU GPL, either version 2 or at your option, any later version.



*1 もっとも、まだ広く使用されていません。
*2 bunzip2 が Linuxの標準ツールであり、パッケージが gzip圧縮の代わりに利用するのは当然であると思う
*3 RPM は たぶん リストされたパッケージに依存し OR はサポートされていないだろう。いずれにせよ、OR は バーチャルパッケージと提供を利用すれば実現できるのでこれは、完全ではないが、パッケージ間の推奨を調整すれば、まぁ "○"とできるだろう。
*4 著作権情報はDebian パッケージにも含まれているが、それは簡単にとりだせる形式ではない
*5 Suse Linuxの場合はサポートされている
*6 Suse Linuxの場合はサポートされている
*7 技術的に rpm は パッケージ名についてハードコード制限が着いてくる. しかし、それはどのファイルにおいても利用されることはないだろう。
(訳注 テキトー Technically, the rpm "lead" contains hard-coded limits on the package name, but the lead is no longer really used by anything except file.)

*8 便利にするために、rpmプログラムを変更し実装する、あなたの新規のメタデータの一部に付けられたタグ番号を必要とする。
(訳注 テキトー To be useful, you need to get a tag number assigned to your new piece of metadata, which implies modifying the rpm program.)

*9 なぜLinuxのツールであってUNIXのツールではないのか。それは、gzip などは全てのUNIXにおける標準ツールではないからである
*10 何人かの人達はファイル依存は むかつく、いやな機能であると考えている

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2006-06-24 (土) 19:13:35 (4046d)