我们的团队经常对使用RHEL / CentOS分发的各种软件包进行自定义。我们的工作流程涉及安装SRPM,执行rpmbuild -bp
以解压缩和修补源代码,进行更改并创建.patch以包含在specfile中,并构建新的自定义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
此过程运行良好但我们目前没有使用任何形式的源代码控制来跟踪我们的修改和specfile更改。根据我对git的理解,我认为应该可以将它注入到这个工作流程中并利用它的一些优势来优化一些步骤(除了SCM的正常优势之外)。
例如,我可以创建上游修补源的初始提交,然后进行修改,而不是稍后创建源diff
的副本。准备好后,使用git format-patch
创建我们的功能补丁并将其添加到specfile。
我也希望版本控制specfiles,虽然我不确定如何最好地实现它。
所以我的问题有三个:
额外信用:假设基于git的工作流程,我如何构建一个中央存储库来接受推送?一个带子模块的回购?每包一个回购?
答案 0 :(得分:8)
在定制上游软件包时,有没有人使用SCM?
不确定。这很常见。
将git集成到我们的工作流程中最有效的方法是什么? 是否有更好的工作流程更有利于版本控制 自定义RPM创作?
我不知道最有效的,但这就是我的工作。我开始
以下~/.rpmmacros
文件:
%_topdir %(echo ${RPM_TOPDIR:-$HOME/redhat})
%_specdir %{_topdir}/PACKAGES/%{name}/%{version}
%_sourcedir %{_topdir}/PACKAGES/%{name}/%{version}/sources
%_rpmdir %{_topdir}/PACKAGES/%{name}/%{version}/rpms
如果我安装了一个软件包(例如,foo-1.0-1.src.rpm),那么spec文件最终会进入
~/redhat/PACKAGES/foo/1.0/foo.spec
和源代码tarball(以及任何
补丁)最终在~/redhat/PACKAGES/foo/1.0/sources
。
现在我将包目录初始化为git存储库:
cd ~/redhat/PACKAGES/foo/1.0
git init
git add foo.spec sources/*.patch
git ci -m 'initial commit'
记录对spec文件的更改没有什么特别之处:
git ci -m 'made some really spiffy changes' foo.spec
如果我需要对包源文件进行更改,请执行以下操作:
rpmbuild -bp foo.spec
现在我创建了一个临时的git存储库:
cd ~/redhat/BUILD/foo-1.0
git init
git add .
git ci -m 'initial commit'
git tag upstream
从现在开始,如果我做了任何更改,我可以生成补丁 像这样的上游包:
git diff upstream
或者如果我进行了一系列提交,我可以使用git的format-patch
命令
创建一系列补丁:
$ git format-patch upstream
0001-added-text.patch
0002-very-important-fix.patch
这些可以复制到相应的sources
目录中并添加
到spec文件。
请注意我为跟踪更改而创建的临时git存储库
下次运行rpmbuild
时,构建目录将被删除。