私たちのチームは、RHEL/CentOS で配布されるさまざまなパッケージのカスタマイズを頻繁に実行します。私たちのワークフローには、SRPM のインストール、rpmbuild -bp
ソースのアンパックとパッチの実行、変更の実行、specfile に含まれる .patch の作成、後でモックで使用するための新しいカスタマイズされた 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 の理解に基づいて、git をこのワークフローに挿入し、その力の一部を活用していくつかのステップを最適化することが可能であると思います (SCM の通常の利点に加えて)。
たとえば、ソースのコピーをdiff
後で作成するのではなく、アップストリームにパッチが適用されたソースの最初のコミットを作成してから、変更を加えることができます。準備ができたら、 を使用git format-patch
して機能パッチを作成し、specfile に追加します。
また、スペックファイルのバージョン管理も行いたいと考えていますが、それを実現する最善の方法はわかりません。
だから私の質問は3つあります:
- アップストリーム パッケージをカスタマイズするときに SCM を使用している人はいますか?
- Git をワークフローに統合する最も効果的な方法は何ですか?
- バージョン管理されたカスタム RPM オーサリングをより助長する、より良いワークフローはありますか?
追加クレジット: git ベースのワークフローを想定すると、プッシュを受け入れる中央リポジトリをどのように構築すればよいでしょうか? サブモジュールを含む 1 つのレポ? パッケージごとに 1 つのレポ?