如何使用git跟踪SRPM自定义?

Jus*_*ᚄᚒᚔ 6 git version-control rpmbuild

我们的团队经常对使用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
Run Code Online (Sandbox Code Playgroud)

此过程运行良好,但我们目前没有使用任何形式的源代码控制来跟踪我们的修改和specfile更改.根据我对git的理解,我认为应该可以将它注入到这个工作流程中,并利用它的一些功能来优化一些步骤(除了SCM的正常好处).

例如,diff我可以创建上游修补源的初始提交,然后进行修改,而不是创建源的副本以供以后使用.准备好后,使用git format-patch创建我们的功能补丁并将其添加到specfile.

我也想版本控制specfiles,虽然我不确定如何最好地实现它.


所以我的问题有三个:

  1. 在定制上游包时,有没有人使用SCM?
  2. 将git集成到我们的工作流程中最有效的方法是什么?
  3. 是否有更好的工作流程更有利于版本控制的自定义RPM创作?

额外的功劳:假设一个基于git的工作流程,我如何构建一个中央存储库来接受推送?一个带子模块的回购?每包一个回购?

lar*_*sks 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
Run Code Online (Sandbox Code Playgroud)

如果我安装了一个软件包(例如,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'
Run Code Online (Sandbox Code Playgroud)

记录对spec文件的更改没有什么特别之处:

git ci -m 'made some really spiffy changes' foo.spec
Run Code Online (Sandbox Code Playgroud)

如果我需要更改包源文件,我这样做:

rpmbuild -bp foo.spec
Run Code Online (Sandbox Code Playgroud)

现在我创建一个临时的git存储库:

cd ~/redhat/BUILD/foo-1.0
git init
git add .
git ci -m 'initial commit'
git tag upstream
Run Code Online (Sandbox Code Playgroud)

从这一点开始,如果我进行任何更改,我可以针对上游包生成补丁,如下所示:

git diff upstream
Run Code Online (Sandbox Code Playgroud)

或者如果我做了一系列提交,我可以使用git format-patch命令创建一系列补丁:

$ git format-patch upstream
0001-added-text.patch
0002-very-important-fix.patch
Run Code Online (Sandbox Code Playgroud)

这些可以复制到相应的sources目录中并添加到spec文件中.

请注意,我为跟踪构建目录中的更改而创建的临时git存储库将在下次运行时被删除rpmbuild.