pbuilderではなくsbuildを使用する理由
クリーンで再現可能な環境でDebianパッケージをビルドする方法は数多くあります。最もよく使用されるのはpbuilderとsbuildです。個人的には、私は常にpbuilderを使用しています。私はpbuilderの使用と保守がずっと簡単だと感じています。この2つの比較を見つけることはできませんでした。何を見逃していますか？
Pbuilderよりもsbuildを使用する利点は何ですか？
sbuildとpbuilderは長年にわたってほぼ同一の機能を持つように開発されており、どちらか一方に機能が追加されると、もう一方にすぐに採用される傾向があります。
Debianパッケージングはポリシー駆動型の形式であるため、特定のビルドの問題がビルダーの実装のバグであるか、ビルドシステムの複数の実装を持つようにビルドされているパッケージの問題であるかを判断するのに役立ちます。これを維持するために、主要なビルドシステムはすべて、ポリシーの利用可能な最も正確な実装を確保することを目指した協調競争の精神で、強力なパルチザンをサポートする必要があります。
Sbuildとpbuilderの内部メカニズムはかなり異なるため、ビルド依存関係を満たすためにどのパッケージをプルするか、どのようにプルするか、debian/rulesのさまざまなターゲットを呼び出す正確なメカニズムなどが異なる場合があり、特定のパッケージの非常に特殊な場合の動作の違い。ほとんどの場合、これはいずれかの実装のバグを表し、パッケージングポリシーの明確性の欠如を反映する場合があります。いずれにしても、動作の変更を解決する必要があります。
DebianとUbuntuの両方の公式ビルドはsbuild（多くの場合、アーカイブから入手できるsbuildではありません）を使用します。これは、構成がビルド時にパッケージが公開されるものと一致するという確信がより高いため、一部の開発者によって利点と見なされます。誰もがこれを行うと、ポリシーのバグとsbuildのバグを区別する機能が失われます。
歴史的に、私の理解では、エンドユーザーおよびsbuild開発は最初はbuilddおよびアーカイブ管理者のニーズに焦点を合わせていたため、pbuilder開発は最初は開発者のニーズに焦点を当てていました。最近、人々はpbuilderに基づいたアーカイブ管理システム、およびsbuildを使用したより便利な開発者ツールを構築してきたため、これらの焦点は切り替わっています。
両方のツール（またはそれらの一般的に利用可能な密接な派生物）は、システム上で展開された別のボリューム（特別なマウント用のフック：LVMスナップショットなど）でtarballとしてchrootを保存、オーバーレイファイルシステムの使用、コピーオンライトセマンティクスの使用などをサポートします両方のツールは、一般的なケース（パッケージのテストビルド）を合理化する簡単なコマンドラインツールと、複雑なケース（大規模なアーカイブ）をサポートする豊富なフックセマンティクスを提供します。両方とも、chrootでテスト環境を作成する手段を提供します。要するに、両方のツールは、パッケージ構築ツールであなたが望むと思うかもしれないほぼすべてのものを提供します（そして両方ともバグやパッチを受け入れて喜んでアクティブなアップストリームを持っています）。
要約すると、pbuilderに満足しているなら、それを使い続けてください。 sbuildを使用したい場合は、お気軽に。最良のツールは、あなたが行う仕事の種類に使いやすいものです。
エメットに反対することは常に危険なので、彼の答えがおそらくより正しいことを認めることから始めましょう。しかし、個人的には、pbuilderの方がユーザーフレンドリーで、パフォーマンスが優れていると思います。
Ubuntu 12.10以降を使用している場合は、優れたpbuilderスクリプトをインストールしてください。これは、生のpbuilderのextremelyフレンドリーラッパーのセットです。
Ubuntu 12.04を使用している場合、バックポートリポジトリからpbuilder-scriptsをインストールできます。
それでは、同等の操作の使いやすさを比較対照しましょう。これらの例では、x86でホストされるARM chrootを使用して説明しますが、概念はx86でホストされるx86 chrootにも適用されます。覚えておいてください、私はpbuilder-scriptsラッパーを使用しています。
注目すべきことの1つは、pbuilder-scriptがRuby on Railsに基づいていくつかの規則を実装することです。私たちが行くように私はこれらを指摘しようとします。
chrootの作成
mk-sbuild --Arch=armhf quantal
対
# in addition to the chroot, creates a new, empty directory named ~/Projects/quantal-armhf
pcreate -a armhf -d quantal quantal-armhf
判定：tie、両方のコマンドラインは非常に単純であり、必要に応じて、より使いやすいユースケース用の追加オプションを使用できます。ただし、pcreateによって作成された追加の新しいディレクトリに注意してください。
ソースパッケージのダウンロード
# standard debian/ubuntu method, works in any directory
apt-get source casper
vs.
# 'quantal-armhf' is the name of the chroot created earlier
# results in downloading package to: ~/Projects/quantal-armhf/casper/
pget quantal-armhf casper
判定：sbuildのわずかなエッジ。これは、標準のdebian/ubuntuベストプラクティスを使用しているためです。 pgetで使用される規則は最初は奇妙に思えるかもしれませんが、Ubuntuの複数のリリースで複数のパッケージに取り組んでいるので、私はそれが課す組織が好きです。また、apt-get sourceは、コマンドを実行した場所からソースも抽出するため、*。orig.tar.gz、*。debian.tar.gz、*。dsc、および私が個人的に見つけた展開ディレクトリが残ります。乱雑になります。組織の美しさはすぐに来ると私は約束します。
chroot、一時バージョンを入力
schroot -c quantal-armhf
vs.
ptest quantal-armhf
判定：pbuildのわずかなエッジ、入力する文字が少ないほど文字が少なくなります。 chrootに入るこのバージョンでは、ここで行った変更はchrootを終了すると失われます。また、schrootでは通常のユーザーのままであるのに対し、ptestではrootユーザーとしてchrootにいることに注意してください。
chrootを入力、変更バージョンを保存
Sudo schroot -c quantal-armhf-source -u root
vs.
ptest quantal-armhf --save
判定：pbuildのわずかなエッジ、私の意見では、文字数が少なく、より直感的なコマンドライン引数です。 chrootを入力するこのバージョンでは、そこに加えた変更は将来の呼び出しのために保存されます。
chroot内でパッケージをビルド
debuild -S -sa -I -i
sbuild -A --Arch armhf -d quantal-armhf /path/to/casper-1.315.dsc
vs.
# must be invoked when pwd is ~/Projects/quantal-armhf/casper/casper-1.315
pbuild
判定：pbuild、pbuildの規則を使用する場合、最初の重要な勝利が見られます。これは、アーキテクチャ、chrootの名前を指定し、sbuildが必要とする* .dscファイルへのパスを要求するのとは対照的に、覚えておく必要のあるまったく単純なコマンドです。さらに、sbuildで新しい* .dscファイルを生成することを忘れないでください。pbuildは自動的に生成します。
chrootで同じパッケージを2回ビルド
上記の例では、sbuildとpbuildの両方が、それぞれのchrootsにbuild-depsをダウンロードしてインストールします。ただし、pbuildは、ダウンロードした.debファイルを/ varに保存するため、2回目にpbuildを呼び出す場合、すべてのbuild-をダウンロードする必要はありません。再びdeps（chrootにインストールする必要がありますが）。 sbuildは.debファイルをキャッシュしません（少なくともデフォルトではありません）。したがって、chrootにインストールされるのを待つことに加えて、すべてのbuild-depsを再度ダウンロードする必要があります。
判定：pbuildロングショット。 build-depsをキャッシュすることは素晴らしいデフォルト設定であり、pbuildはアーカイブにbuild-depの新しいバージョンがあるかどうかを検出し、必要に応じて新しいバージョンをプルダウンするのに十分スマートです。多くのbuild-depsを使用する複雑なパッケージの場合、この単純な設定により、数分の時間を節約できます。
概要
箱から出して、pbuilder-scriptsはsbuildの同等物よりもはるかに友好的で高速であることがわかりました。もちろん、pbuilderをさらに高速化する方法（tmpfsでビルドし、chrootフックの一部を無効にする）があり、おそらくsbuildにも同じトリックがありますが、私はそれらを知りません。
お役に立てれば。