まあ、それはパッケージレシピがここに行く方法のように聞こえます。基本的に、パッケージレシピは、Launchpadのbzrブランチが変更されるたびに、Ubuntuソースパッケージを自動的に作成し、PPAにアップロードできます。オンラインドキュメントはかなり良いですが、私は例のカップルを与えるでしょう...
最初に、追跡するブランチ（たとえば、lp:gtk3）を指定してから、独自のDebianパッケージブランチをそのブランチにネストするコマンドを追加します。Inkscapeの毎日のビルド用に作成したこのレシピを見てください。
# bzr-builder format 0.4 deb-version 1:0.48+devel+{revno}+{revno:packaging}
lp:inkscape
nest packaging lp:~inkscape.dev/inkscape/debian-packaging debian
このレシピは、Inkscapeの最新のアップストリームソースを使用して毎日Ubuntuパッケージを作成しますが、カスタマイズされたDebianパッケージ命令をlp:~inkscape.dev/inkscape/debian-packagingブランチから「debian」というサブフォルダーにコピーします。
Launchpadのパッケージレシピページでは、パッケージを自動的にアップロードするPPAを指定できます。私たちの場合、ここにアップロードされています。
別のアプローチとして、上流のソースに直接ではなく、既存のUbuntuパッケージに基づいてレシピを作成することもできます。たとえば、lp:ubuntu/gtk+3.0。次に、このコードのブランチを作成し、必要な変更をコミットする必要があります。lp:~myaccount/ubuntu/saucy/gtk+3.0/my-custom-buildたとえば、としましょう。次に、パッケージング手順をネストするのではなく、変更を自動的にマージするレシピを作成します。レシピは次のようになります。
# bzr-builder format 0.4 deb-version {debversion}+{date}
lp:ubuntu/gtk+3.0
merge my-custom-build lp:~myaccount/ubuntu/saucy/gtk+3.0/my-custom-build
したがって、このレシピは、カスタムUbuntuソースパッケージを自動的にビルドし、公式のUbuntuパッケージに変更があるたびに、PPAにアップロードします。
この「マージ」アプローチを取る場合、パッチを適用するための2つのオプションがあります。上流のソースコードをブランチで直接編集してbzrにマージを任せるか、debian/キルトを使用してフォルダー内にパッチファイルを作成します。それぞれに独自の利点/欠点があります。前者のアプローチは少しスマートです...上流の開発者がパッチの1つを採用している場合、マージは通常どおり機能し、Ubuntuパッケージは正常にビルドされます。後者のアプローチでは、パッケージングコードを上流のコードから分離する標準のDebianベースのアプローチを使用してパッチを処理できます...ただし、上流の開発者がパッチのいずれかを採用している場合、キルトは（複製）を適用できませんパッチとパッケージはビルドに失敗します。
lp:ubuntu/gtk+3.0追跡するのでしょうか？現在の安定版または現在の開発バージョン？