我们的团队经常对随 RHEL/CentOS 分发的各种软件包进行定制。我们的工作流程包括安装 SRPM,执行rpmbuild -bp
解压和修补源代码,进行更改并创建要包含在规范文件中的 .patch,以及构建新的自定义 SRPM 以供以后与 mock 一起使用:
$ 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
创建我们的功能补丁并将其添加到规范文件中。
我也想对规范文件进行版本控制,尽管我不确定如何最好地实现这一点。
所以我的问题有三个:
- 有没有人在定制上游包时使用 SCM?
- 将 git 集成到我们的工作流程中最有效的方法是什么?
- 是否有更好的工作流程更有利于版本控制的自定义 RPM 创作?
额外的功劳:假设一个基于 git 的工作流程,我将如何构建一个中央存储库来接受推送?一个带有子模块的仓库?每个包一个回购?