私は本質的に他のソフトウェアを構築するために使用される多くのライブラリとヘッダーを提供するパッケージ用のUbuntuパッケージを書いています。パッケージは、相互に依存する小さなサブパッケージに分割されます。この意味で、パッケージはブーストに非常に似ています。
boostのようなパッケージが提供することに気付きました
[...]
libboost-dbg
libboost-dev
libboost-doc
[...]
libboost-all-dev
[...]
しかし、名前boostまたはで行くものはありませんlibboost。
-dbg、-devと-docパッケージは？回答:
これらの異なるパッケージを分離する主な理由は、ディスク容量とダウンロード速度に関係しています。特に、それはデータの複数のコピーを配布することを意味するため、ミラースペースにとって大きな懸念事項です。することによりfoo-common、foo-dataまたは foo-docパッケージをArchitecture: all、我々は唯一の代わりに、それは（例えば、I386、AMD64、電気ショック療法...）各アーキテクチャでコピーしたのアーカイブ内のデータののコピーを保持します。ほとんどのユーザーはデバッグシンボルを必要とせず、パッケージのダウンロードに時間がかかるだけです。
公式のUbuntuアーカイブにあるパッケージの場合、実際には-dbgパッケージを手動で作成する理由はありません。ビルドマシンは、デバッグシンボルを自動的-dbgsymに取り除き、ddebs.ubuntu.comでホストされているパッケージに入れます。（参照：デバッグシンボルパッケージ）-dbg存在するパッケージは通常、Debianから持ち越されます。
実装については、次の質問をご覧ください。
簡単に言うと、debian/controlパッケージごとに新しいスタンザを作成する必要があります。次に、debian/foo-*.installファイルも作成する必要があります。これによりdh_install、適切なコンテンツを適切なパッケージに入れることができます。
foo.installメインバイナリパッケージのためには、次のようになります。
usr/bin/
usr/lib/
foo-common.install、foo-data.install、foo-doc.install、または何でも：
/usr/share/doc/
/usr/share/icons/
/usr/share/foo/
/usr/share/locale/
そしてfoo-dev：
/usr/include/
/usr/lib/pkgconfig
/usr/lib/*.so
foo-dbgパッケージを作成するにはdebian/rules、通常、dh_stripデバッグシンボルを削除するため、編集が必要です。そのため、その動作をオーバーライドする必要があります。
.PHONY: override_dh_strip
override_dh_strip:
dh_strip --dbg-package=foo-dbg
Boostは複雑な例です。最初に簡単な例を見てみましょう。
正確には、opensslソースパッケージは5つのバイナリパッケージを提供します。
libssl1.0.0OpenSSL動的ライブラリ、バージョン1.0.0が含まれています。それが、このライブラリにリンクされたプログラムを実行する必要があるものです。パッケージ名にはバージョン番号が含まれています。これは、1.0.0とバイナリ互換ではない別のバージョンに対して他のプログラムがリンクされている場合、ライブラリの他のバージョンが同時にインストールされる可能性があるためです。opensslOpenSSLライブラリを使用するコマンドラインツールが含まれています。ライブラリのバージョンが複数ある場合でも、これらのツールの複数のバージョンは必要ありません/usr/bin/openssl。関連するツール、データ、およびドキュメントは1つだけです。libssl-devOpenSSLにリンクするプログラムをコンパイルする場合に必要なファイルが含まれています。Cヘッダーファイル（*.h）、リンク用ライブラリ（*.a、*.so）、およびいくつかの分類されたファイルがあります。libssl-docOpenSSLライブラリのドキュメントが含まれています。ライブラリを使用するプログラムを作成する場合にのみ、このパッケージが必要です。libssl1.0.0-dbgデバッグシンボルが含まれています。OpenSSLライブラリまたはそれを使用するプログラムをデバッグする人にのみ役立ちます。andrewsomethingの回答には、これらの-dbgパッケージに関する詳細情報が含まれています。さらに、preciseには古いバージョンのライブラリが含まれていlibssl0.9.8ます。これは、古いバージョンに対してリンクされているプログラムがまだあるためです。
あなたが見るかもしれない他のパッケージは、C以外の言語のバインディングです。OpenSSLには何も付属していません（他の言語のOpenSSLへのバインディングがありますが、それらは同じソースから来ません）。例はsqlite3で、TCLバインディングが付属しています。
このようにパッケージを分割する主な理由は、パッケージごとにターゲットオーディエンスが異なるためです。誰も何もコンパイルしないシステムには、コアlibパッケージとコマンドラインツールのみが必要です。必要に応じて、依存関係から自動的にインストールされます。ライブラリを使用するプログラムをコンパイルする場合は、-devパッケージが必要です。誰かがライブラリを使用するプログラムを作成する場合は、-docパッケージが必要です。
では、Boostはどうですか？これは、同じ構造に従うが、ブーストは巨大なライブラリですので、それは多くの小型パッケージに分けています：libboost-*1.46.1とlibboost-*1.46-dev。厳密には、Boostのバージョンは1.46だけですが、oneiricには1.42と1.46の両方がありました。バージョン管理されたパッケージを依存関係として取り込むメタパッケージboost-defaultsもあります。
libhangulを見ると、動的ライブラリパッケージlibhangul1と開発パッケージに加えて、パッケージlibhangul-devがありますlibhangul-data。このパッケージには、ライブラリに必要な追加データが含まれています。ライブラリのバージョンが複数ある場合でも、-dataパッケージを共有できます。また、パッケージはアーキテクチャに依存しません。大量のアーキテクチャに依存しないデータを含むソフトウェアは、配信サイトのスペースを節約するために、アーキテクチャに依存するパッケージとアーキテクチャに依存しないパッケージに分割されます。同様の意味を持つ別の接尾辞は-commonです。
UbuntuとDebianのパッケージングルールは非常に似ているため、Debianパッケージの作成に関する資料はUbuntuにも適用されます。実際、DebianとUbuntuで同じソースパッケージを使用できます。DebianとUbuntuパッケージを異なるものにしている唯一のことは、異なるライブラリバージョンに対してそれらをコンパイルすることであり、それはUbuntuの異なるリリース間の違いにすぎません。持っているDebianの開発者向けドキュメントを手に、特にDebianポリシーマニュアルおよび開発者のリファレンス。導入については、新しいメンテナーガイドを参照してください。Debianプロジェクトでの作業などに関する部分は無視してください。パッケージの作成に関する部分を読んでください。dh_make debパッケージを始めるには良い方法です（「ライブラリ」を選択することをお勧めします）。