pbuilderではなくsbuildを使用する理由

クリーンで再現可能な環境でDebianパッケージをビルドする方法は数多くあります。最もよく使用されるのはpbuilderとsbuildです。個人的には、私は常にpbuilderを使用しています。私はpbuilderの使用と保守がずっと簡単だと感じています。この2つの比較を見つけることはできませんでした。私は何を見逃していますか？

pbuilderよりもsbuildを使用する利点は何ですか？

sbuildとpbuilderは長年にわたってほぼ同一の機能を持つように開発されており、どちらかに機能が追加されると、もう一方にすぐに採用される傾向があります。

Debianパッケージングは​​ポリシー駆動型の形式であるため、特定のビルドの問題がビルダーの実装のバグであるか、ビルドシステムの複数の実装を持つようにビルドされているパッケージの問題であるかを判断するのに役立ちます。これを維持するために、主要なビルドシステムはすべて、ポリシーの利用可能な最も正確な実装を確保するための共同競争の精神で、それらをサポートする強力なパルチザンを持たなければなりません。

sbuildとpbuilderの内部機構は大きく異なるため、ビルド依存関係を満たすためにどのパッケージをプルするか、またはどのようにプルするか、debian / rulesのさまざまなターゲットを呼び出す正確なメカニズムなどが異なり、若干の原因となります。特定のパッケージの非常に特殊な場合の動作の違い。ほとんどの場合、これはいずれかの実装のバグを表し、パッケージングポリシーの明確性の欠如を反映する場合があります。いずれにしても、動作の変更を解決する必要があります。

DebianとUbuntuの両方の公式ビルドはsbuild（多くの場合、アーカイブから入手できるsbuildではありません）を使用します。ただし、全員がこれを行うと、ポリシーのバグとsbuildのバグを区別する機能が失われます。

歴史的に、私の理解では、pbuilder開発は最初に開発者のニーズに焦点を当て、エンドユーザーおよびsbuild開発は最初にbuilddおよびアーカイブ管理者のニーズに焦点を当てていました。最近、人々はpbuilderに基づいたアーカイブ管理システム、およびsbuildを使用したより便利な開発者ツールを構築してきたため、これらの焦点が変わりました。

両方のツール（または一般的に利用可能な密接な派生物）は、chrootをtarballとして保存し、システム上でアンパックし、個別のボリューム（特別なマウント用のフック：LVMスナップショットなど）、オーバーレイファイルシステムの使用、コピーオンライトセマンティクスの使用などをサポートします両方のツールは、一般的なケース（パッケージのテストビルド）を合理化する簡単なコマンドラインツールと、複雑なケース（大規模なアーカイブ）をサポートする豊富なフックセマンティクスを提供します。両方とも、chrootでテスト環境を作成する手段を提供します。要するに、両方のツールは、パッケージ構築ツールであなたが望むと思うものを提供します（そして、両方ともバグとパッチを受け入れて喜んでアクティブなアップストリームを持っています）。

要約すると、pbuilderに満足しているなら、それを使い続けてください。sbuildを使用したい場合は、お気軽に。最良のツールは、あなたが行うある種の作業に使いやすいツールです。

エメットに反対することは常に危険なので、彼の答えがおそらくより正しいことを認めることから始めましょう。ただし、個人的には、pbuilderの方がユーザーフレンドリーで、パフォーマンスが優れていると思います。

Ubuntu 12.10以降を使用している場合は、優れたpbuilderスクリプトをインストールしてください。これは、生のpbuilderの非常に使いやすいラッパーのセットです。

Ubuntu 12.04を使用している場合は、backportsリポジトリからpbuilder-scriptsをインストールできます。

それでは、同等の操作の使いやすさを比較対照しましょう。これらの例では、x86でホストされるARM chrootを使用して説明しますが、x86でホストされるx86 chrootにも概念は適用されます。覚えておいてください、私はpbuilder-scriptsラッパーを使用しています。

注目すべきことの1つは、pbuilder-scriptsが少し規則を実装していることです。Rubyon 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

対

# 'quantal-armhf' is the name of the chroot created earlier
# results in downloading package to: ~/Projects/quantal-armhf/casper/
pget quantal-armhf casper

判定：標準のdebian / ubuntuベストプラクティスを使用しているため、sbuildのわずかな優位性。pgetで使用される規則は、最初は奇妙に思えるかもしれませんが、Ubuntuの複数のリリースで複数のパッケージに取り組んでいるので、私はそれが課している組織が好きです。また、apt-get sourceは、コマンドを実行した場所からソースを抽出するため、*。orig.tar.gz、*。debian.tar.gz、*。dsc、および私が個人的に見つけた展開ディレクトリが残ることに注意してください。乱雑になります。組織の美しさはすぐに来ると約束します。

短命バージョンのchrootを入力します

schroot -c quantal-armhf

対

ptest quantal-armhf

判定：pbuildのわずかなエッジ、入力する文字が少ないほど文字が少なくなります。chrootに入るこのバージョンでは、ここで行った変更はchrootを終了すると失われます。また、schrootでは通常のユーザーのままであるのに対し、ptestではrootユーザーとしてchrootにいることに注意してください。

chrootを入力し、変更バージョンを保存します

sudo schroot -c quantal-armhf-source -u root

対

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

対

# 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に保存するので、pbuildを再度呼び出す場合、すべてのbuild-depsを再度ダウンロードする必要はありません（chrootにインストールする必要があります）。sbuildは.debファイルをキャッシュしません（少なくともデフォルトではありません）。したがって、chrootにインストールされるのを待つことに加えて、すべてのbuild-depsを再度ダウンロードする必要があります。

評決：ロングショットによるpbuild。build-depsをキャッシュすることは素晴らしいデフォルト設定であり、pbuildはアーカイブに新しいバージョンのbuild-depがあるかどうかを検出するのに十分スマートであり、必要に応じて新しいバージョンをプルダウンします。多くのbuild-depsを使用する複雑なパッケージの場合、この単純な設定はあなたの人生の数分を節約します。

概要

箱から出して、pbuilder-scriptsはsbuildの同等物よりもはるかに友好的で高速であることがわかりました。もちろん、pbuilderをさらに高速にする方法（tmpfsでビルドし、chrootフックの一部を無効にする）があり、おそらくsbuildにも同じトリックがありますが、私はそれらを知りません。

お役に立てれば。