Debian 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 を参照ください [50]。

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

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

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

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

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

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

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

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

パッケージは、共有ライブラリを普通の名前でインストールすべきです。例えば、パッケージ 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.*) がそのライブラリを見つけることができるようにするため [51] です。

8.1.1 `ldconfig`

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

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

postinst スクリプトが、最初の引数を configure として呼ばれた場合、スクリプトで ldconfig を呼ばなければいけません。 postinst スクリプトではそれ以外の際に ldconfig を呼んでもかまいません。
postrm スクリプトが、最初の引数を remove として呼ばれた場合、スクリプトで ldconfig を呼ばなければいけません。

[53]

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

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

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

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

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

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

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

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

その言語の共有ライブラリサポートがこなれておらず、不安定な場合。

ライブラリに対するインターフェースがまだ流動的だったり、開発途中の場合 (通常ライブラリのメジャーバージョン番号が 0 であるか、ABI がパッチレベル間で変更される場合)。

上流の作者の意図により、スタティックリンク版のみを提供するようになっている場合。

8.4 開発用ファイル

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

複数の開発用ライブラリが存在する場合、開発用のパッケージは一度に一バージョンのみインストールされることを保証するため、恐らく 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} による変数置換がこの目的には便利です [56]。

8.6 ライブラリと他のパッケージとの依存関係の扱い - `shlibs` システム

パッケージが共有ライブラリとリンクしたバイナリやライブラリを含む場合、パッケージをシステムにインストールする際に、必要なすべてのライブラリも共にインストールされるようにする必要があります。この要求から、shlibs システムが作られました。これは設計上は非常に簡単なものです。共有ライブラリを 提供する パッケージはすべて、そのライブラリの動作を保証するために必要なパッケージ依存関係の情報を提供しなければならず、また共有ライブラリを 使用する パッケージは、その共有ライブラリが必要とする依存関係を判断するためにこの情報を使います。共有ライブラリから必要な依存関係の情報への対応を保持するファイルは shlibs ファイルと呼ばれます。

共有ライブラリを含むパッケージをビルドする際には、他のパッケージが使えるよう shlibs を提供しなければいけません。また、共有ライブラリやコンパイルされたバイナリを含むパッケージでは、それらに対して dpkg-shlibdeps を実行して、それらが使っているライブラリと、その使用に伴ってそのパッケージで必要になる依存関係を判断できるようにしなければいけません [57]。

以下の節では、まず各 shlibs を探すべき場所について記載し、次に dpkg-shlibdeps の使い方について、最後に shlibs ファイルフォーマットと、あなたのパッケージが共有ライブラリを含む際にこのファイルをどう作るのかについて説明していきます。

8.6.1 システム中の `shlibs` ファイル

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

debian/shlibs.local

これはこのパッケージの情報を上書き変更するために使います。このファイルは通常は使うべきではありませんが、他のパッケージのバグを回避するための特別な場合や、インストールされているライブラリに対する shlibs の通常の宣言されている依存関係を使うことができないような特別の場合などに一時的に必要になる場合があります。

/etc/dpkg/shlibs.override

これはシステム全体の情報を上書きするために使います。このリストは通常空です。これはローカルのシステム管理者によって管理されます。

build ディレクトリ中の DEBIAN/shlibs ファイル

パッケージをビルドしようとする際、各 debian/shlibs ファイルは一時的に作成されたビルドディレクトリ中のコントロールファイル領域ににコピーされ、 shlibs という名が付けられます。これらのファイルは、そのパッケージに含まれる共有ライブラリの詳細情報を提供します [58]。

/var/lib/dpkg/info/*.shlibs

ここの shlibs ファイルはシステムにインストールされている全パッケージに対するもので、各パッケージのメンテナによって管理されています。

/etc/dpkg/shlibs.default

ここに列挙されているファイルは、正しい shlibs ファイルが提供されていないパッケージに対するものです。これは shlibs 設定が最初に導入されたときに使われましたが、現在は通常空です。これは dpkg のメンテナに管理されています。

8.6.2 `dpkg-shlibdeps` と `shlibs` の使い方

debian/rules ファイル中に dpkg-shlibdeps への呼び出し処理を置いてください。バイナリだけを含んだパッケージ (つまり、スクリプトを含まない) の場合、次のコマンドが使えます。

     dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/* \
       debian/tmp/usr/lib/*

それ以外の場合には、コンパイルされるバイナリとライブラリを明示的に列挙する [59] 必要があります。

このコマンドは debian/substvars ファイル中に依存関係の情報を挿入します。この情報は後で dpkg-gencontrol が使います。これが正しく処理されるよう、Depends フィールドに ${shlibs:Depends} 変数を置かなければならないでしょう。

複数のバイナリパッケージを生成する場合には、 dpkg-shlibdeps をコンパイルされたバイナリ及び共有ファイルを含むパッケージ毎に実行する必要があります。この場合、個別の substvars ファイルを指定するため dpkg ユーティリティの -T オプションを使う必要が出てくるでしょう。このオプションについての詳細は dpkg-shlibdeps(1) を見てください。

Debian Installer 中で使用するために udeb を作成する場合には、 dpkg-shlibdeps が udeb タイプに対する依存指定行を用いるように、 -tudeb オプション[60] を追加する指定を行なう必要があるでしょう。shlibs ファイル中に udeb タイプに対する依存関係の指定行がない場合、 dpkg-shlibdeps は標準の依存関係指定行を用います。

dpkg-shlibdeps について更に詳しく知りたい場合には、 dpkg-shlibdeps - 共有ライブラリの依存関係の算定, Section C.1.4 と dpkg-shlibdeps(1) をご覧ください。

8.6.3 `shlibs` ファイルフォーマット

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

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

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

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

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

soname-version はライブラリの .so ファイル名のバージョンの部分です。soname にはダイナミックリンカに認識されるライブラリ名と厳密に一致した名前を与えなければいけません。これは通常、name.so.major-version という形式で、ここでの例では libz.so.1 [61] です。バージョン部は .so. の後に来ている部分で、ここの例では 1 です。soname 部は libdb-4.8.so のように name-major-version.so とすることもでき、この場合はライブラリ名が libdb で、バージョン番号が 4.8 になります。

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

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

     libz 1 zlib1g (>= 1:1.1.3)

バージョン指定の依存関係は、古い共有ライブラリを新しいバイナリと共に使った場合、ダイナミックリンカが出す警告メッセージを避けるためのものです。

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

     udeb: libz 1 zlib1g-udeb (>= 1:1.1.3)

8.6.4 `shlibs` ファイルを提供する

パッケージが共有ライブラリを提供する場合、上記のフォーマットで shlibs ファイルを作成する必要があります。普通は debian/shlibs という名前にします (もし複数のバイナリパッケージを作成する場合には、 debian/shlibs.package としたほうがいい場合もあります)。次に、debian/rules でそれを制御情報ファイル領域にインストールしてください。

     install -m644 debian/shlibs debian/tmp/DEBIAN

または、複数のバイナリパッケージの場合には、次のコマンドとします。

     install -m644 debian/shlibs.package debian/package/DEBIAN/shlibs

もう一つの方法として、debian/rules から制御情報ファイル領域に、 debian/shlibs をまったく使わずに shlibs を直接作成するやり方 [62] もあります。これは、dpkg-shlibdeps からは debian/shlibs ファイル自体は無視されるためです。

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