Debian JP Project

(for vocal browsers: toc, main)

Google
WWW 全体 www.debian.or.jp 検索
[ トップ | ダウンロード | コミュニティ | イベント | Project について ]

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]

Debian ポリシーマニュアル
Chapter 8 - 共有ライブラリ

共有ライブラリを含むパッケージの場合、その共有ライブラリがつねに使用可能となるように多少の注意を払って作成しなければなりません。 とりわけ、C ライブラリ (現在は libc6 です) などのシステム運用に関わる重要な共有ライブラリのときは特にこのことは重要です。

この節では公開される共有ライブラリのみを扱います。 つまり、既定でダイナミックリンカが探索するディレクトリに置かれるか、他の独立したパッケージから普通にリンクされることを意図した共有ライブラリを扱います。 特定のパッケージの内部で使うための共有ライブラリや、動的モジュールとしてロードされるだけのライブラリはこの節では扱わず、以下の要求事項の対象とはなりません。

共有ライブラリはダイナミックセクションに格納された SONAME アトリビュートで識別されます。 バイナリが共有ライブラリにリンクされている場合、共有ライブラリの SONAME がバイナリの NEEDED セクションに記録され、ダイナミックリンカはその情報を使って当該ライブラリを実行時にロードしなければならないことを認識します。 共有ライブラリの名前の全体 (これには通常 SONAME には必要ではない追加のバージョン情報が含まれます) は、従って直接参照されることはありません。代わりに、共有ライブラリは 共有ライブラリの実際の名前 (の全体) を指すシンボリックリンクとしてシステムに配置された SONAME を使ってロードされます。 シンボリックリンクはパッケージ側で提供しなければいけません。 これを行う方法については、ランタイム共有ライブラリ, Section 8.1 を参照ください [59]。

共有ライブラリに対してバイナリや他の共有ライブラリをリンクする時点では、 その共有ライブラリの SONAME はまだ分かっていません。 この場合、共有ライブラリは対応するライブラリ名に .so を付けた名称のファイルの探索により決定されます。 このようなファイルは、ファイルシステム上では、共有ライブラリを指すシンボリックリンクとして存在します。

共有ライブラリを含むパッケージは、通常複数のバイナリパッケージに分割されます。 SONAME シンボリックリンクは、共有ライブラリのランタイムパッケージによりインストールされます。 また、生の .so シンボリックリンクは、バイナリや共有ライブラリとリンクする際にのみ用いるため、開発用パッケージによりインストールされます。 但し、一般的ではない共有ライブラリや他のプログラムから動的モジュールとしてロードされる共有ライブラリなどは例外になります。

この節では、共有ライブラリを複数のパッケージに分割するための (適切な) 手法と、共有ライブラリとバイナリパッケージとの依存関係が Debian でどのように処理されるか、を主として記載します。さらに ライブラリ, Section 10.2 に共有ライブラリに収録されるファイルに関する追加の規則が記載されていますので、そちらを合わせて読んでください。

8.1 ランタイム共有ライブラリ

ランタイム共有ライブラリのパッケージは、収録された共有オブジェクトの SONAME が変更されるたびに、パッケージ名称を変更する必要があります。 これにより、共有ライブラリの複数のバージョンを同時にインストールできるため、共有ライブラリの古いバージョンに依存したバイナリを直ぐに動かなくすることなしに新バージョンのインストールが可能です。 通常は、共有ライブラリのランタイムと、その SONAME シンボリックリンクは、 librarynamesoversion という名称のパッケージに収録すべきです。ここで、soversion は、共有ライブラリの SONAME 中のバージョン番号です。 または、libraryname に soversion を直接付加すると混乱する場合 (例えば、 libraryname 自体が数字で終わっている場合など) には、 libraryname-soversion を代わりに用いるべきです。

soversion を調べるには、ELF SONAME アトリビュートに格納されているライブラリの SONAME を見て下さい。これは通常 name.so.major-version のような形式 (例えば libz.so.1) です。バージョン部は、.so. に続く部分で、上記の例では 1 です。soname は name-major-version.so の形式の場合もあり (例えば libdb-5.1.so)、この場合のライブラリ名は libdb で、バージョンは 5.1 です。

一つのソースツリーから複数の共有ライブラリをビルドする場合には、すべての SONAME 名を常に一括して変えるようにすることで、複数の共有ライブラリを一つのパッケージにまとめられます。 注意点としては、これは一般的な状況ではなく、SONAME が同期して変更されない場合には、まとめられた共有ライブラリのアップグレードが、旧バージョンのライブラリとのファイル名の競合のため不必要に複雑になります。 自信の無い場合には、共有ライブラリパッケージを分割して、各バイナリパッケージに一つの共有ライブラリが収録されるようにしてください。

共有ライブラリの旧版とリンクしたバイナリが動かなくなるような ABI 変更が行われる場合には、ライブラリの SONAME と、それに対応した共有ライブラリを収録したパッケージ名は毎回変更すべきです。 これは、共有ライブラリからインターフェースが削除された場合、またはインターフェースの特性の変更があった場合 (例えば、引数の数や引数のタイプが変更された場合など) SONAME を通常変更すべきだということです。 この約束事は、パッケージの旧バージョンからの綺麗なアップグレードに不可欠で、さらに関連パッケージを同期してアップグレードせずに、旧 ABI から新 ABI に綺麗に移行する処理にも不可欠になります。

インターフェースの削除や変更なしに単に追加が行われたという場合には、 SONAME 名とバイナリパッケージ名は変更する必要はありませんし、変更すべきでもありません。 これは、このような変更は旧共有ライブラリにリンクしていたバイナリを壊すことがないためです。 新しいインターフェースを用いるバイナリでの、新しい共有ライブラリとの正しい依存関係に対するバージョン付けは、 シンボル または shlibs system を使って管理されます。

パッケージは、共有ライブラリを普通の名前でインストールすべきです。 例えば、パッケージ libgdbm1 は libgdbm.so.3.0.0 を /usr/lib/libgdbm.so.3.0.0 へインストールすべきです。 このファイルを prerm や postrm スクリプトから名前を変更したり、再リンクしたりすべきではありません。 dpkg が、実行中のプログラムに影響がないように、注意してファイル名の変更などの作業を実行しますし、 これと競合するような処理はおそらく問題を起こすでしょう。

共有ライブラリには実行属性をつけないでください。 ダイナミックリンカはこの属性を必要としませんし、共有ライブラリを実行しようとしても通常コアダンプになるだけです。

ランタイムライブラリパッケージは、SONAME に対応した ldconfig の作成する共有ライブラリ用のシンボリックリンクを含むべきです。 例えば、libgdbmg3 パッケージは、 /usr/lib/libgdbm.so.3 から libgdbm.so.3.0.0 を含むべきです。これが必要なのは、dpkg がライブラリをインストールしてから postinst で ldconfig が実行されるまでの間にダイナミックリンカ (例えば、ld.so や ld-linux.so.*) がそのライブラリを見つけることができるようにするため [60] です。

8.1.1 ldconfig

ダイナミックリンカの標準のディレクトリ (現在は /usr/lib と /lib です)、または /etc/ld.so.conf に列挙されたディレクトリ [61] にライブラリをインストールするパッケージは、 共有ライブラリシステムをアップデートするために ldconfig を使わなければいけません。

パッケージが postinst スクリプト中で ldconfig を呼ぶのは、以下の場合に限られます。

[62]

8.2 ランタイムサポートファイル

パッケージに、ライブラリの共有オブジェクトに合わせては変更されないファイルを含む場合、それを共有ライブラリパッケージに収録してはいけません。 これを行うと、複数バージョンの共有ライブラリをファイル名の衝突なしにインストールすることができなくなり、アップグレードや移行が不必要に難しくなります。

サポートファイルとランタイムサポートプログラム (ユーザが手動で実行する必要がないが、パッケージ動作には必要なもの) は、バイナリなら /usr/lib のサブディレクトリ以下に置くことを推奨します。 /usr/lib/package-name 以下が望ましい場所です。 プログラムやファイルがアーキテクチャ非依存ならば、推奨の格納場所は /usr/share のサブディレクトリ (/usr/share/package-name が望ましい) になります。以下の package-name の名前付けの規則により、 共有オブジェクトバージョンが変更された場合、ファイル名も変更されることが保証されています。

共有ライブラリを使うが、ライブラリの動作には必要のないランタイムサポートプログラム、または共有ライブラリのバージョンによらず共通して使用されるファイルは、 独立したパッケージにすることを推奨します。このパッケージは通常 libraryname-tools という名前にします。 パッケージ名に soversion が含まれていないことに注意してください。

ファイルとサポートプログラムで、ライブラリを使うプログラムのコンパイル時にのみ有用なものは、ライブラリの開発用パッケージに含めてください [63]。

8.3 スタティックライブラリ

スタティックライブラリ (libraryname.a) は、通常共有ライブラリと併せて提供されています。 これは、開発用パッケージ (下記参照) に収録されています。

ある種の場合では、スタティックリンク版のみのライブラリを提供することも許されます。 そのような場合には以下のものがあります。

8.4 開発用ファイル

共有ライブラリに関連した開発用のファイルがある場合には、ソースパッケージでは librarynamesoversion-dev という名前のバイナリ開発用パッケージを作成して収録するか、 または一度に一つの開発用バージョンのみをサポートしたい場合は libraryname-dev という名前のパッケージを作成して収録する必要があります。 この開発用のパッケージをインストールすることにより、対象共有ライブラリを使ってプログラムをコンパイルするのに必要な全ての開発用ファイルがインストールされなければいけません[64]。

複数の開発用ライブラリが存在する場合、開発用のパッケージは一度に一バージョンのみインストールされることを保証するため、恐らく dpkg の競合 (Conflict) メカニズム (競合するバイナリパッケージ - Conflicts, Section 7.4 参照) を使う必要があるでしょう。 異なった開発用のパッケージといえども同じヘッダファイルを持つことが多いですから、二種以上を展開しようとするとファイル名衝突が起こるためです。

開発用パッケージには、対応する共有ライブラリに対するバージョン番号なしのシンボリックリンクを含めるべきです。 例えば、libgdbmg1-dev パッケージには、 /usr/lib/libgdbm.so から libgdbm.so.3.0.0 へのシンボリックリンクを含めるべきです。 このシンボリックリンクは、リンカ (ld) がパッケージをコンパイルする際に必要になります。 リンカは動的コンパイル時に libgdbm.so しか見ないためです。

パッケージが GMAT で用いる Ada ライブラリ情報 (*.ali) ファイルを含む場合、 このファイルは読み出し専用 (mode 0444) でインストールし、GNAT がこれを再コンパイルしないようにしなければいけません。 これは ファイル属性と所有者, Section 10.9 で記載の通常のファイルモード指定に対する例外規定です。

8.5 同一のライブラリのパッケージ間の依存関係

通常、開発用バージョンは、コンパイルとリンクを正しく行うため、ランタイムライブラリに対して正確な依存関係を持たせるべきです。 ${binary:Version} による変数置換がこの目的には便利です [65]。

8.6 ライブラリと他のパッケージとの依存関係の扱い

パッケージが共有ライブラリとリンクしたバイナリやライブラリを含む場合には、 パッケージをシステムにインストールする際に、必要なすべてのライブラリも共にインストールされていることを保証する必要があります。 この依存関係は、バイナリのソースコードに何の変更がなくともバイナリまたはライブラリのリンクの際に元にした共有ライブラリのバージョンによって変化するため (例えばシンボルのバージョン変更、マクロが関数に変更された、またはその逆、 さらにバイナリパッケージがコンパイル時に新しいライブラリインターフェースが提供されており、利用できると判断したなど) バイナリパッケージのビルド時に追加される必要があります。 この依存関係を構築するために、共有ライブラリは symbols ファイルか、shlibs ファイルのいずれかを提供しなければなりません。 これらのパッケージの依存関係として提供される情報は、ライブラリの提供するインターフェースが存在することを保証するために必要です。 共有ライブラリにリンクを行うバイナリまたはライブラリを収録するパッケージは、これらのファイルを用いてビルド時に必要な依存関係を判断しなければいけません。 共有ライブラリを用いるその他のパッケージ (例えば dlopen() を使うもの) も、ビルド時にこれらのファイルを使って適切な依存関係を同様に計算すべきです。

この２つのメカニズムは、提供機能の詳細レベルでは異なります。symbols ファイルは、ライブラリからエクスポートされる各シンボルと、そのシンボルを用いるバイナリが最低限必要とする当該パッケージのバージョンを記述します。 このバージョンとは、普通はそのシンボルが導入されたパッケージのバージョンを指します。 この情報は、特定のパッケージで用いるシンボルの詳細な分析と正確な依存関係の構築を可能としますが、その一方パッケージメンテナは共有ライブラリについてのより多くの情報を把握して置かなければいけません。

それに対して shlibs ファイルには、ライブラリ ABI に何らかの変更が最後にあった時点のみが記述されています。 このファイルには、各々のシンボルではなく、ライブラリ丸ごとでの情報のみが提供されているのです。 パッケージが共有ライブラリを用いてビルドされる場合には shlibs ファイルのみが用いられ、生成された依存関係は ABI 変更が行われた最後の時点でのバージョンか、それより新しいものを要求するものとなります。 このことにより、もしパッケージの用いているシンボルに変更がない場合には、symbols ファイルによる方法に比べ、不必要に制限の強い依存関係が生成されることになります。 また一方、古い版の共有ライブラリを持つシステムでのパッケージの利用が不必要に制限され、アップグレードの際に不必要に複雑な処理を強いられるでしょう。

また、shlibs ファイルはライブラリの SONAME の限られた範囲のみをサポートしているため、一般的ではない用途の一部では shlibs ファイルを用いるのは困難です[66]。

このため、ほとんどの共有ライブラリパッケージでは、より正確な依存関係を提供する symbols の方を薦めます。 ほとんどの C ライブラリでは、symbols ファイルで必要となる追加情報を維持するのはそれほど難しくはありません。 ただし、C++ ライブラリで網羅的なシンボル情報を維持するのは大変な作業なので、 C++ ライブラリの場合はほとんどの場合には shlibs のほうがより適切です。udeb と関連付けられたライブラリでは、shlibs を提供しなければいけません。これは udeb インフラストラクチャでは symbols ファイルを用いていないためです。

8.6.1 共有ライブラリでの依存関係の作成

共有ライブラリやコンパイル済みのバイナリを含むパッケージをビルドする際には、 各共有ライブラリとコンパイルされるバイナリに対して dpkg-shlibdeps を実行して、使っているライブラリと、その使用に伴ってそのパッケージで必要になる依存関係を判断できるようにしなければいけません [67]。 これをおこなうため、ソースパッケージの debian/rules に dpkg-shlibdeps への呼び出しを置いてください。 また、パッケージ内のコンパイル済みのバイナリ、ライブラリ、ローダブルモジュールを全て列挙してください[68]。 dpkg-shlibdeps は、共有ライブラリがインストールした symbols や shlibs ファイルを用いて依存関係情報を構築します。 そして、パッケージは作成された依存関係情報を置くための代替変数を下記のように提供しなければいけません。

もし、Debian インストーラで用いる udeb を作成しているならば、 dpkg-shlibdeps に -tudeb オプションを加えて udeb タイプの依存関係記述行をもちいるべきであることを指定する必要があるでしょう [69]。 shlibs ファイル内に udeb タイプの依存関係指定行がない場合、 dpkg-shlibdeps は通常の依存関係が指定されたものとして処理します。

dpkg-shlibdeps は依存関係情報を、既定では debian/substvars ファイルに格納し、その情報は dpkg-gencontrol で用いられます。 このため、作業しているソースパッケージからビルドされる、コンパイル済みバイナリ、ライブラリ、ローダブルモジュールを含む全てのパッケージのコントロールファイル中の Depends フィールドに、${shlibs:Depends} 変数を置く必要があるでしょう。また、生成されるバイナリパッケージが複数ある場合、 コンパイル済みライブラリまたはバイナリの各々に対して dpkg-shlibdeps を呼びださなければいけません。 例えば、dpkg ユーティリティに対して -T を用い、各バイナリパッケージに対して異なった substvars ファイルを指定することもできます [70]

dpkg-shlibdeps の詳しい説明は、 dpkg-shlibdeps(1) を参照ください。

ここで、バイナリはこのライブラリを 直接的に 使っているとは、バイナリ foo がライブラリ libbar に明示的にリンクされている場合 (すなわち、リンクの段階で -lbar フラグを使って、ライブラリが ELF NEEDED アトリビュート付きでリストされている場合) のことです。 libbar が必要とするその他のライブラリは foo に 間接的に リンクされており、ダイナミックリンカは libbar をロードする際に自動的にそれらのライブラリをロードします。 間接的に使われているライブラリへの依存関係は自動的にダイナミックリンカによりロードされるため、 パッケージが依存関係を指定すべきなのは直接リンクしているライブラリだけです。 dpkg-shlibdeps がこの論理を自動的に処理しますが、自動処理結果を何らかの理由で上書きしたい場合にはパッケージメンテナがこの直接・間接の区別を意識する必要があります [71]。

8.6.2 共有ライブラリの ABI の変更

共有ライブラリを symbols または shlibs ファイルを使って維持管理するためには、共有ライブラリの外部に提供する ABI とその何らかの変更の有無を意識する必要があります。symbols ファイルと shlibs ファイルのいずれもが共有ライブラリの ABI の全ての変更を記録しますが、symbols は公開されたシンボルに対してのみ記録するのに対し、shlibs ファイルはライブラリ全体での最後の変更についてのみ記録するという違いがあります。

ABI の変更は、後方互換性を維持したものとそうでないものの二種類に分けられます。 ABI の変更が後方互換性を維持しているとは、以前のバージョンの共有ライブラリにリンクしている通常のプログラムが、新しいバージョンの共有ライブラリで引き続き動作できることを意味します[72]。 共有ライブラリに新しいシンボルを加えることは後方互換性を持った変更です。 共有ライブラリからシンボルを削除することは後方互換性を持ちません。 シンボルの挙動を変更することによる後方互換性の有無は、変更の内容によります。 例えば、関数で以前に使っていなかった新しい enum 定数を受け付けるような変更は通常は後方互換性を持ちますが、 ライブラリ関数に渡す構造体のメンバを変更する場合は、旧バージョンのデータ構造を受け付けるような特別の対処が行われていない限り、一般的には非互換です。

後方互換性を持たない ABI 変更では、通常ライブラリの SONAME の変更、すなわち共有ライブラリパッケージ名の変更が必要になり、 それにともなって新しいバージョンの共有ライブラリを用いることができるようにするため、共有ライブラリを利用しているすべてのパッケージの再ビルドが強制されます。 この処理の詳細については ランタイム共有ライブラリ, Section 8.1 を参照ください。 この節での以降の部分では後方互換性を持つ変更について説明します。

後方互換性を持つ変更では、symbols ファイル中にシンボルファイルの minimal-version (最小バージョン) の更新または記録を行うか、shlibs ファイル中の dependencies フィールドの更新が必要になります。 この２つのフォーマットでこの処理をどのように行うかの詳細は、各々 symbols ファイルフォーマット, Section 8.6.3.2 と shlibs ファイルフォーマット, Section 8.6.4.2 を参照ください。 以下は両方のファイルで適用される一般的な規則です。

簡単な場合は、公開シンボルの追加です。 該当のシンボルの追加されたバージョン番号を symbols ファイルに追加するか、shlibs ファイルでの依存するバージョンを更新してください。 一方公開シンボルの挙動が変化した場合の、依存するバージョンの更新については特段の配慮を行うべきです。 このような変更の有無を自動的に判定する手段が無いため、このような処理は抜けやすいものですが、 この場合にバージョンの更新が行われないことによってバイナリパッケージに弱すぎる依存関係が提供され、実行時にセキュリティ上の脆弱性となる方法でプログラムが落ちる結果となる場合があります。 パッケージメンテナが、シンボルの挙動の変更があるかもしれないが確かではないと考える場合は、 変更しないよりバージョンを更新するほうが安全です。 これにより不必要に厳しい依存関係となる可能性はありますが、パッケージの依存関係を満たすパッケージが正しく動作することは保証できます。

依存するバージョンの変更が必要となる典型的例は、関数がどのような処理を行うかを指示する引数として enum 値または構造体を取る場合です。例えば 

     	      enum library_op { OP_FOO, OP_BAR };
     	      int library_do_operation(enum library_op);

もし新しい処理 OP_BAZ が追加された場合、 (symbols ファイルの) library_do_operation の minimal-version、または (shlibs ファイルの) 共有ライブラリの「依存するバージョン」の指定は、OP_BAZ が導入されたバージョンに増加させなければいけません。 さもなければ、ライブラリの新バージョンを用いてビルドされた (コンパイル時にライブラリが OP_BAZ がサポートされていることを検出した) バイナリが OP_BAZ をサポートしていないライブラリ環境でインストールされ、この関数に OP_BAZ を渡そうとして実行時に落ちることになるでしょう。

symbols または shlibs ファイルで指定された依存するバージョンは、通常はパッケージの Debian レビジョンを含むべきではありません。 これは、ライブラリの挙動は上流の特定のバージョンで通常修正され、Debian パッケージはそれと同じ挙動となるからです。まれには特定の Debian レビジョンでライブラリの挙動が変更されることがあり、その場合にはバージョン末尾に ~ を追加して Debian レビジョンを含めることを推奨します。 これにより共有ライブラリのバックポート時に、依存関係を満足させるようにするための通常のバックポートバージョン付けのやり方が使えるためです。

8.6.3 symbols システム

以下の節では、まず様々な symbols ファイルを置く場所を説明し、次に symbols ファイルフォーマットの説明、最後に共有ライブラリを持つパッケージでどのようにして symbols を作成するかを説明します。

8.6.3.1 現在のシステムに存在する symbols ファイル

共有ライブラリの symbols ファイルは、通常は共有ライブラリパッケージの制御ファイルとして提供されます。 ただし、情報が正しくなかったり欠けていた場合に上書きする手段がいくつか有り、まずそちらをチェックします。 以下のリストは、dpkg-shlibdeps が読み取る順を示したものであり、最初に見つかった必要な情報を提供するものが使われます。

ソースパッケージに debian/shlibs.local が含まれている場合は注意してください。このファイルは symbols を上書きします。このような上書きが symbols ファイルが存在する場合にも shlibs が使われる唯一の場合です。 詳しくは システムに存在する shlibs ファイル, Section 8.6.4.1 と shlibs システム, Section 8.6.4 を参照ください。

8.6.3.2 symbols ファイルフォーマット

以下の文書は、バイナリパッケージに収録される symbols コントロールファイルの書式を記載したものです。 これらのファイルは、ソースパッケージ中のテンプレートとなる symbols から dpkg-gensymbols によってビルドされます。テンプレートファイルは更に詳細指定可能な書式を持っており、管理する dpkg-gensymbols が symbols ファイル管理に伴う面倒な作業の一部 (C++ のシンボルの管理や、特定アーキテクチャで存在しないようなオプションのシンボルの管理など) を行えるようになっています。 共有ライブラリパッケージの symbols ファイルを書く場合は、ここで述べた詳細指定可能な書式の内容について dpkg-gensymbols(1) を参照ください。

symbols は一つないし複数のエントリで、各エントリはその symbols に対応するパッケージに収録された共有ライブラリの各々に対応します。 各エントリのフォーマットは以下の通りです。 

     		library-soname main-dependency-template
     		[| alternative-dependency-template]
     		[...]
     		[* field-name: field-value]
     		[...]
     		symbol minimal-version[ id-of-dependency-template ]

このフォーマットの説明では、例として zlib1g パッケージを用いましょう。 この文書記載時点では、このパッケージは共有ライブラリ /usr/lib/libz.so.1.2.3.4 をインストールします。 まず記載必須の行について説明し、そのあとでオプションの行を説明します。

library-soname には共有ライブラリの ELF SONAME アトリビュートの正確な値が記載されていなければいけません。ここでの例では、これは libz.so.1[74] です。

main-dependency-template は、 バイナリパッケージコントロールファイルの依存関係フィールドと同様の書式ですが、文字列 #MINVER# は (>= バージョン) のようなバージョンの制限条件で置き換えるか、特にバージョン無指定で十分と考えられる場合は何も指定しません。 ここでのバージョンの制限条件は、共有ライブラリから参照されるシンボルと、そのシンボルが導入されたバージョンに基づいて決められます (以下参照)。 ほとんどすべての場合、main-dependency-template は package #MINVER# という記述となります。ここで package は該当共有ライブラリを含むバイナリパッケージの名前です。 これにより、共有ライブラリパッケージに対する単純で、恐らく妥当なバージョン依存関係を指定できます。 特別の場合、例えば複数のパッケージが同じ共有ライブラリ ABI を提供しているような場合には、 依存関係のテンプレートはもっと複雑なものになります。

ここでの例では、zlib1g の symbols の最初の行は 

     		libz.so.1 zlib1g #MINVER#

となるでしょう。

共有ライブラリからエクスポートされる公開シンボルの各々に対して、対応する symbol 行の指定が必要です。これは、空白一文字でインデントされます。 symbol 行はエクスポートされたシンボル (C++ では、マングルされたシンボルです) に続いて @ とシンボルのバージョン、またはシンボルバージョンがない場合は文字列 Base が置かれます。minimal-version は、そのシンボルの挙動が最後に変更された (追加または関数の仕様の変更、例えば 引数の追加削除や型の変更、戻り型の変更など)、 または呼び出し元に見える形で動作が最後に変更された、共有ライブラリのバージョンです。 id-of-dependency-template はオプションのフィールドで、 alternative-dependency-template を参照します。 詳しい説明は以下を参照ください。

例えば、libz.so.1 には compress と compressBound シンボルが含まれています。compress にはシンボルバージョンの指定がなく、上流で最後に挙動が変更されたのはバージョン 1:1.1.4 の際です。compressBound にはシンボルバージョン ZLIB_1.2.0 が指定されており、それ以降の挙動の変更はありません。 したがって、ここでの symbols には以下の行が含まれます。 

     		compress@Base 1:1.1.4
     		compressBound@ZLIB_1.2.0 1:1.2.0

compress だけを用いるパッケージは、ここから zlib1g (>= 1:1.1.4) という依存関係を得ますが、 compressBound を用いるパッケージの依存関係は zlib1g (>= 1:1.2.0) になります。

一つないしは複数の alternative-dependency-template 行を指定可能です。 この行は共有ライブラリの一部のシンボルが他のシンボルと異なったテンプレートを使うべきであるばあいに指定されます。 代替依存関係テンプレートは、シンボル行に id-of-dependency-template 行が含まれる場合にのみ使われます。最初の代替依存関係テンプレートには番号 1 が、以下順に番号 2、3 と続きます [75]。

最後に、ライブラリに対応するエントリには、一つないし複数のメタデータフィールドを含めることができます。 現時点では、サポートされている フィールド名 (field-name) は Build-Depends-Package だけで、このフィールドの値は、このパッケージを使うパッケージがビルド時の依存関係を宣言すべき ライブラリ開発用パッケージ名 を列挙します。 このフィールドが存在する場合、このフィールドの値を dpkg-shlibdeps が利用し 結果として生成されるバイナリパッケージの共有ライブラリへの依存関係が、 共有ライブラリ開発用パッケージに対するソースパッケージの依存関係より少なくとも同等か厳しい物になるよう保証します [76]。 ここでの例では、zlib1g の symbols には以下の行が含まれます。 

     		* Build-Depends-Package: zlib1g-dev

また、deb-symbols(5) も参照ください。

8.6.3.3 symbols ファイルを用意する

作成したパッケージに共有ライブラリが含まれる場合、上記フォーマットに従った symbols コントロールファイルをパッケージに含めるよう用意すべきです。 また、symbols コントロールファイルか、shlibs コントロールファイルのいずれかは含めなければいけません。

通常は、この容易はソースパッケージに symbols ファイルを debian/package.symbols という名前か、あるいは debian/symbols という名称で作成することによって行われます。 シンボル情報がアーキテクチャによって異なる場合には、上記の名称に .arch が付け加えられます。 このファイルは、dpkg-gensymbols(1) で文書化された拡張書式を利用可能です。このファイルの作成後、 パッケージビルド処理の一環として dpkg-gensymbols を呼ぶことにより、ステージング領域内のバイナリと共有ライブラリ、およびこのソースパッケージの symbols ファイルから、パッケージのステージング領域に symbols が作成されます[77]。

symbols ファイルを提供するパッケージは、そのパッケージの) 共有ライブラリを用いるパッケージが正しい依存関係を得られるよう、そのファイルを最新にしていなければなりません。 つまり、symbols ファイルは新しい公開シンボルが追加された場合には更新され、 シンボルの挙動やシグナチャが後方互換性を保つやり方で変更された場合には minimal-version を更新し (共有ライブラリの ABI の変更, Section 8.6.2 参照) ライブラリの SONAME が変更された場合には、library-soname と main-dependency-template、加えて恐らく minimal-version フィールドの全エントリを更新します。 ライブラリからのシンボルの削除に伴って symbols ファイルからパブリックシンボルを削除する場合には、通常ライブラリの SONAME の変更が必要になります。SONAME についての詳細は、ランタイム共有ライブラリ, Section 8.1 を参照ください。

8.6.4 shlibs システム

shlibs システムは 共有ライブラリの依存関係制限を行うための symbols システムのより単純な代替です。 C++ ライブラリなどの場合で、個々のシンボルの追跡が困難な場合に適しています。 また、symbols システムより古くから用いられているため、古いパッケージでよく見られます。 また、symbols をサポートしていない udeb で必要となります。

以下の節では、まず各 shlibs を探すべき場所について記載し、次に dpkg-shlibdeps の使い方について、最後に shlibs ファイルフォーマットと、その作成方法について説明していきます。

8.6.4.1 システムに存在する shlibs ファイル

shlibs を探すべき場所は幾つかあります。以下は dpkg-shlibdeps から読まれる順に、その場所を列挙したものです。 最初に見つかった必要な情報を提供するものが使われます。

共有ライブラリで symbols ファイルが提供されている場合、 dpkg-shlibdeps は debian/shlibs.local を例外として、それ以外は常に shlibs より symbols を優先して用います。debian/shlibs.local は、全ての他の shlibs ファイルと symbols ファイルの内容を上書きします。

8.6.4.2 shlibs ファイルフォーマット

各 shlibs は同じフォーマットを使います。# で始まる行はコメントとして扱われ、無視されます。 それぞれの行はつぎのものから構成されます。 

     		[type: ]library-name soname-version dependencies ...

zlib1g パッケージを例に取り説明していきます。 このパッケージは (これを書いている時点では) 共有ライブラリ /usr/lib/libz.so.1.2.3.4 をインストールします。

type はオプションとなる要素であり、その行が有効なパッケージのタイプを示します。 現在使われている唯一のタイプは、udeb です。 タイプの後には、コロンと空白が必要です。

library-name は、共有ライブラリの名前です。 この場合には、libz です (これは共有ライブラリ soname のファイル名部分と一致していなければいけません。以下参照のこと)。

soname-version はライブラリの ELF SONAME アトリビュートのバージョンの部分で、推奨共有ライブラリのパッケージ名の soversion 要素の判定と同じ規則に従います。 詳細は ランタイム共有ライブラリ, Section 8.1 を参照ください。

dependencies は、バイナリパッケージのコントロールファイル中の依存関係フィールドと同じ書式です。 ここには、そのパッケージに含まれるライブラリを用いるようにビルドしたバイナリが動作するために、どのパッケージが必要になるかに関する詳細を記述しておくべきです。 書式の詳細については 関係性フィールドの書式, Section 7.1 を、依存バージョンの管理方法の詳細については 共有ライブラリの ABI の変更, Section 8.6.2 を参照ください。

ここの例では、zlib1g パッケージで、少なくとも 1.3 以降のマイナーバージョン番号を持つ最初のバージョンは 1:1.2.3.3.dfsg-1 ですので、このライブラリの shlibs にはこう書きます。 

     		libz 1 zlib1g (>= 1:1.2.3.3.dfsg)

このバージョンの制限は、ライブラリの現在のバージョンを用いてビルドしたバイナリが、このファイルで指定した依存関係を満たす任意の共有ライブラリで動作できるよう十分に新しいものでなければいけません。

zlib1g も共有ライブラリを含む udeb を提供するため、更に二行目が付加されています。 

     		udeb: libz 1 zlib1g-udeb (>= 1:1.2.3.3.dfsg)

8.6.4.3 shlibs ファイルを提供する

共有ライブラリバイナリパッケージに対して shlibs を提供するには、以下のフォーマットで shlibs を作成して、ビルド時に該当パッケージの DEBIAN ディレクトリに置いてください。 このファイルがパッケージのコントロールファイルとしてパッケージに収録されます[78]。

dpkg-shlibdeps はソースパッケージから作成するすべてのバイナリパッケージに対して DEBIAN/shlibs ファイルを読むため、すべての DEBIAN/shlibs は、dpkg-shlibdeps をどのバイナリパッケージに対して実行するより前にインストールしておくべきです。

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]

Debian ポリシーマニュアル

バージョン 3.9.5.0, 2014-07-03

The Debian Policy Mailing List

このページに関するご感想・ご質問は webadmin+at+debian.or.jp までお送りください。

Copyright © Debian JP Project / ライセンス条項を見る。

powered by Debian Valid HTML 4.01! Valid CSS!