用Git来管理已发布到公开Git仓库的Debian软件包的方式
总结
本文是关于使用git-buildpackage软件包提供的gbp命令在Git上管理在GitHub等Git存储库中公开的软件Debian包的方法的备忘录。
首先,需要使用git-buildpackage包中的gbp命令。另外,将会涉及到两个远程仓库。
-
- 上流リポジトリ: パッケージ対象のソフトウェアが公開されているリポジトリ
- 管理リポジトリ: 主として debian/ 配下のパッケージ用ファイルを管理する目的のリポジトリ
我感觉可能还有误解或误会存在,所以请留下评论。
创建初始版本的软件包时
首先,准备一个空的工作仓库。
mkdir pkg-sentencepiece
cd pkg-sentencepiece
git init
git commit --allow-empty -m "first commmit"
然後,下載上游存儲庫。
git remote add upstream https://github.com/google/sentencepiece.git
git fetch upstream
请按照以下命令,在上游存储库中创建一个对应的 upstream 分支。
git checkout -b upstream upstream/master
由于上游分支是用于跟踪上游源代码的分支,所以请注意不要混入debian/子目录下的软件包文件或软件包修改。
我们会给被选中作为打包目标的 upstream 分支添加标签。在标签名中,upstream/ 是 gbp 命令使用的固定字符串。0.0.0+20170516 部分是包维护者可以自由选择的版本字符串。
git tag upstream/0.0.0+20170516
回到主分支,并合并上游源代码。
git checkout master
git merge --allow-unrelated-histories upstream
我们在debian/目录下创建必要的文件并进行包的修改。在包能够正确生成之前,我们会持续修改各种文件并重复执行以下命令。
gbp buildpackage
自 Debian10 (Buster) 以后的 gbp 现在会自动调用 cowbuilder 进行包构建,因此只需要在第一次构建时进行 cowbuilder 的设置。如果未进行设置直接构建包,将会出现以下错误。
$ gbp buildpackage
(略)
Base directory /var/cache/pbuilder/base-stable-amd64.cow does not exist
由于缺少 cowbuilder 的 chroot 环境,因此此错误消息意味着您需要执行以下命令以创建一个干净的 chroot 环境。
sudo env DIST=stable ARCH=amd64 git-pbuilder create
另外,要更新创建的chroot环境,请执行以下命令。
sudo env DIST=stable ARCH=amd64 git-pbuilder update
鑒於我的情況主要是為stable版本創建軟件包,因此我通常使用以下命令來構建軟件包。
gbp buildpackage -us -uc --git-dist=stable --git-arch=amd64
当你能够正确编写时,请使用以下命令创建发布版本的软件包。此命令将在主分支上为发布版本的软件包添加标签。
gbp buildpackage --git-tag
将包括包装文件和修改过的源代码等一套,存储在版本控制存储库中。
git remote add origin ssh://git@bitbucket.org/tsuchm/pkg-sentencepiece.git
git push -u origin master
git push -u origin --tags
随着上游更新的浪潮
切换到上游分支,获取上游存储库的更新。
git checkout upstream
git pull
我会给要打包的上游源代码添加标签。
git tag upstream/0.0.0+20170829
回到主分支并合并上游源代码的更新。
git checkout master
git merge upstream
进行必要的修改,创建软件包。
当重新创建工作用本地代码库时
首先,复制管理仓库。
git clone ssh://git@bitbucket.org/tsuchm/pkg-sentencepiece.git
接下来,我们将添加上游存储库。
cd pkg-sentencepiece
git remote add upstream https://github.com/google/sentencepiece.git
git fetch upsteream
我們將創建一個與上游倉庫最新版本相對應的上游分支。
git checkout -b upstream upstream/master
当原始代码以tarball形式公开时。
尽管与本文的主题不同,但如果上游源代码以tarball形式公开,我也想顺便介绍一下git-buildpackage的用法。首先,将tarball导入到上游分支中。
tar xzf crfsuite-0.12.tar.gz
cd crfsuite-0.12
git init
git commit --allow-empty -m "first commit"
git branch upstream
git checkout upstream
git add *
git commit "Import crfsuite-0.12"
git tag "upstream/0.12"
接下来,我们需要切换回master分支,按照常规的打包流程进行包的制作。
git checkout master
git merge upstream
dh_make
gbp buildpackage
自動檢查能夠建立包裹。
最近的 Git 仓库服务中,为了进行持续集成(CI),很多都有在 git push 后自动执行命令的机制。使用这种机制,可以检查软件包是否可以成功构建。例如,可以使用 BitBucket Pipelines 来检查软件包是否可以成功构建,以下是相应的步骤。
首先,准备一个名为bitbucket-pipelines.yml的文件,其中描述了构建软件包的步骤。在这里,我们从Docker Hub下载了一个不稳定的debian容器,然后安装了构建所需的软件包,最后执行了gbp。
image: debian:unstable
pipelines:
default:
- step:
script:
- apt update
- env DEBIAN_FRONTEND=noninteractive apt upgrade -y
- env DEBIAN_FRONTEND=noninteractive apt install -y build-essential git-buildpackage
- env DEBIAN_FRONTEND=noninteractive apt install -y `perl -ne 's/#.*$//;if(s/^Build-Depends:\s*//){$p=$_;}elsif($p){if(/^\s/){$p.=$_;}else{$p=~s/\(.*?\)//g;$p=~s/[,\s]+/ /g;print $p;undef $p}}' debian/control`
- gbp buildpackage -us -uc
使用下方的perl命令,从debian/control文件中的Build-Depends指定的软件包列表中提取并安装软件包。请注意,该命令会尝试简单地安装所有软件包,因此如果存在特定于体系结构的条件分支或多个软件包的逻辑表达式,需要适当更改代码。
如果不设置 DEBIAN_FRONTEND 环境变量,apt 在执行时会出错。另外,如果在 gbp 命令中未使用 -us 选项和 -uc 选项,则签名会失败并导致错误。
如果只是放置一个名为bitbucket-pipelines.yml的文件,那么在除了debian/目录以外发生更改,将导致执行dpkg-source命令时出现错误。因此,我们需要创建一个内容如下的debian/source/options文件,以忽略对bitbucket-pipelines.yml的更改。
extend-diff-ignore = "^bitbucket-pipelines\.yml$"
如果正确设置,gbp命令将成功运行(即包将成功构建),并且在流水线的执行结果中会显示为“Successful”。