☰

使用自制包的工作流程

tag-icon • tag-icon ppa packaging
使用自制包的工作流程

我有一个文件夹~/Packaging，里面有我所有的公共和私有包。例如，在这个Packaging/think-rotate文件夹中，有典型的 Debian 内容，如下所示：

think-rotate-2.5.2/
think-rotate-2.5.2.orig/
think-rotate-2.6/
think-rotate-2.6.orig/
think-rotate_1.0.tar.gz
think-rotate_2.5.2-0ubuntu1.debian.tar.gz
think-rotate_2.5.2-0ubuntu1.dsc
think-rotate_2.5.2-0ubuntu1_source.build
think-rotate_2.5.2-0ubuntu1_source.changes
think-rotate_2.5.2.orig.tar.gz@
think-rotate_2.5.2.tar.gz
think-rotate_2.5.orig.tar.gz@
think-rotate_2.5.tar.gz
think-rotate_2.6-0ubuntu1_all.deb
think-rotate_2.6-0ubuntu1_amd64.build
think-rotate_2.6-0ubuntu1_amd64.changes
think-rotate_2.6-0ubuntu1.debian.tar.gz
think-rotate_2.6-0ubuntu1.dsc
think-rotate_2.6-0ubuntu1_source.build
think-rotate_2.6-0ubuntu1_source.changes
think-rotate_2.6-0ubuntu1_source.stable.upload
think-rotate_2.6.orig.tar.gz@
think-rotate_2.6.tar.gz

我有一些脚本可以遍历我的项目并.tar.gz从源代码生成最新代码。因此，对于这个问题，打包目录中会不时出现新的 tar 存档。

因为我不想uupdate ../….tar.gz手动运行每个项目，所以我写了一个Python 3 脚本它负责处理该事情、运行debuild -S并将dput其上传到我的 Launchpad PPA，然后debuild为我的本地机器构建它。

Debian 更新日志中只填充了默认的“新上游版本”消息。这些软件包更适合有组织的本地部署，而不是面向公众。

然后，该脚本还会apt-cache show检查是否安装了最新版本，如果没有，则dpkg -i安装该包。

这在某种程度上是有效的，但是我在使用该脚本的当前版本时遇到了一些问题：

  • 当我将机器升级到新的 Ubuntu 版本时，它不会重建所有内容。因此，我有很多软件包没有收到任何上游更新，而我的 PPA 中的最新版本是quantal，而不是raring。

  • 软件包是amd64在我的主计算机上为 构建的，并且经常无法安装在我的另一台计算机上，该计算机有i686。有些软件包是all，所以这没什么影响。但我需要any在那台机器上重建软件包。Launchpad PPA 负责为每种架构构建它，但我的脚本没有上传该软件包raring，请参阅第一个问题。

总而言之，工作流程必须包含以下所有步骤：

  • 提取新的源 tar 档案并更新debian/changelog。( uupdate)

  • 如果尚未上传到 PPA，请构建源包并将其上传到 Launchpad PPA。但只能这样做，如果这是公共包，请不要将我的私有包上传到 PPA。（debuild -S和dput）

  • 如果包需要在本地升级，请为当前体系结构构建一个二进制包并安装它。（debuild和debi或dpgk -i）

  • 检查该系列是否已过时，即最新上传的版本为quantal，并且当前系统在 上运行raring。如果是，请重新构建源并上传到 PPA。

在您说我应该手动处理每个包之前，请记住我还有 43 个包，而且我真的很想在这里节省工作量。

我可以修改我的脚本来解决当前的问题，但我宁愿使用已经可以运行的脚本，而不是自己动手。维护人员是否使用了一些 takechain 或工作流程来使 PPA 或官方存储库中的这么多软件包保持最新状态？

更新 2013-07-08：我现在也在编写脚本来处理这些问题。但我仍然对规范的解决方案感兴趣。

答案1

我在工作中维护了相当多的软件包，因此让我给你提供我的个人观点。

您的所有内容都应在一个中心位置构建，适用于您需要的所有发行版和体系结构。不要上传源包，然后在本地再次构建。从托管所有内容的构建服务器中选择您的“私有”包。这样，您就可以将您的私有存储库/etc/apt/sources.list与所有其他存储库放在一起（如果需要，请用密码保护它们）。

如果 Launchpad 不适合您，请设置您自己的构建系统。由于您有很多软件包（超过 40 个），因此设置适合您特殊需求的构建环境迟早会有回报。

您将需要一台具有网络访问权限的专用机器 - 无论是在家里还是在工作场所，或者在数据中心租用的服务器。

这里有两个选项：

  1. 使用 Jenkins CI 和构建脚本进行包构建。詹金斯 Debian GlueMichael Prokop 编写的，它可以完成这项工作，并且有很好的文档记录（我最终从头开始重写了它，但它可能对你有用）。它是 100% 的 shell 代码，因此如果您需要对其进行调整，请准备好编写一些 Bash 脚本。
    有了它，您将能够为您想要的所有 dists 和 arches 组合构建所有包。Jenkins 非常灵活且非常稳定，并且可以轻松地将您的存储库划分为多个部分（供私人和公共使用）。

  2. 使用 Buildbot – 与选项 1 相比，这需要更多的手动工作，但 Buildbot 是一个 Python 项目，从你的问题来看，我认为你会觉得设置起来很轻松。i3（窗口管理器）项目有一个出色的描述他们如何设置他们的 Buildbot 环境，并以此作为起点。

我也强烈推薦sbuild完毕pbuilder。 詹金斯 Debian Glue使用 pbuilder（这是我最终放弃它的原因之一）。

无论如何，您都需要做一些迄今为止不需要做的事情，例如设置软件包存储库（这可能非常痛苦）和维护构建服务器。不过，到最后，这一切都是值得的——您将学到很多东西。

相关内容