私たちのチームは、RHEL/CentOSで配布されているさまざまなパッケージのカスタマイズを頻繁に行っています。私たちのワークフローは、ソースを解凍し、パッチを適用するrpmbuild -bp
を実行し、SRPMをインストールする私たちの変更を行うと、specファイルに含まれる.patchファイルを作成し、モックで後で使用するためにカスタマイズされた新しいSRPMを構築含まれますgitを使用してSRPMのカスタマイズを追跡するにはどうすればよいですか?
$ rpm -i grub-0.97-13.5.1.src.rpm
$ rpmbuild -bp rpmbuild/SPECS/grub.spec
$ cp -a rpmbuild/BUILD/grub-0.97 grub-0.97.orig
$ cd rpmbuild/BUILD/grub-0.97
# Make modifications, generate .patch against ".orig" copy
$ vim rpmbuild/SPECS/grub.spec
# Add custom .patch to specfile, update version, etc
$ rpmbuild -bs rpmbuild/SPECS/grub.spec
$ mock -r default-x86_64.cfg rpmbuild/SRPMS/grub-0.97-13.5.1.custom-1.src.rpm
このプロセスはうまくいきますが、私たちは現在、ソースコントロールの形式を使用して、変更とスペックファイルの変更を追跡していません。 gitの私の(根本的には)理解に基づいて、私はこのワークフローにそれを注入し、いくつかの力を活用して(SCMの通常の利点に加えて)いくつかのステップを最適化することが可能であるべきだと思います。
たとえば、ソースのコピーをdiff
に作成するのではなく、後で修正したアップストリームパッチソースの最初のコミットを作成して修正することができます。準備ができたら、git format-patch
を使用してフィーチャーパッチを作成し、スペックファイルに追加します。
また、仕様ファイルもバージョン管理したいと思いますが、それを達成するにはどうすればよいかわかりません。
だから私の質問は3つあり:上流のパッケージをカスタマイズするとき
- そこに誰もがSCMを使用していますか?
- 私たちのワークフローにgitを統合する最も効果的な方法は何ですか?
- バージョン管理されたカスタムRPMオーサリングにより適したワークフローがありますか?
エクストラクレジット:どのように私はプッシュを受け入れるための中央リポジトリを構築するだろう、のgitベースのワークフローを想定すると?サブモジュールと1つのレポ? 1パッケージにつき1レポですか?
偉大な答えです。 1つの追加:私は通常、軽微なdevに 'mock'を使い、依存関係がインストールされていなければrpmbuildは文句を言うでしょう。 rpmbuildに '--nodeps'を追加すると、誰もが幸せになれます。 – Mansour
なぜ消え去りますか? – MarkHu
ビルドプロセスの一環として、 'BUILD'ディレクトリの内容はrpmによって削除されます。もちろん、このリポジトリを他のどこかで永続的に管理することができます。 – larsks