pkgbump：从简陋工具到不可或缺的助手

# pkgbump: 从笨拙工具到不可或缺的帮手 版本升级是 Gentoo 开发者最常见的任务之一。因此，它也是最需要某种自动化的任务，而 `pkgbump` 脚本很早就成为了 `mgorny-dev-scripts` 包（https://gitweb.gentoo.org/proj/mgorny-dev-scripts.git/）的一部分，这并不意外。 如今的 `pkgbump` 已经与最初那个简陋的脚本大不相同。最近的版本终于实现了我长期以来渴望的功能：版本操作。这也使脚本成为了一个完整的版本升级工具，而不仅仅是更大工作流程中的一部分。在这篇文章中，我想简要介绍一下这些变化背后的故事，并展示新的选项。 ## 第一次迭代 `pkgbump` 的初始版本相当简单。它接受两个路径参数：源路径和目标路径。它复制 ebuild 文件、降低关键词、更新版权年份、更新 Manifest，并运行 `pkgdiff`（现在叫 `pkgdiff-mg`）工具来比较解压后的存档。所以典型的工作流程是这样的： ``` cd pkg svglib pkgbump svglib-2.0.{1,2}.ebuild vim svglib-2.0.2.ebuild # 如有必要 # 在另一个终端测试软件包 pkgcommit -sS . -m '升级到 2.0.2' ``` 显然，这里存在一些重复，还有改进的空间。随着时间的推移，一些改进逐渐出现。我增加了对从 `PYTHON_COMPAT` 中移除过时的 Python 实现的支持，增加了对 `PKGBUMPING` 变量的支持（用于在 diff 时跳过解包 crate），以及与 `pkgcommit` 的集成，这样就不需要重复版本号，只需执行： ``` pkgcommit -sS . --bump ``` ## 批量升级软件包 如果说 `pkgbump` 有时用起来有些繁琐，那在诸如 `dev-python/botocore`、`dev-python/boto3` 和 `app-admin/awscli` 这类软件包组中尤为明显。这三个软件包通常是同时发布的，一周五次，版本号往往略有不同。所以你会做类似这样的事情： ``` pkgbump botocore-1.24.{0,1}.ebuild pkgbump boto3-1.21.{0,1}.ebuild pkgbump awscli-1.22.{55,56}.ebuild ``` 于是，`bump-boto` 诞生了。它的初始版本接受旧的和新的补丁版本号，并自动计算所有其他数字。所以只需调用： ``` bump-boto 0 1 ``` 在这个初始版本中，每当上游更改次版本号时，我都得更新脚本。下一个版本会从仓库中获取次版本号，但当补丁号之间的对齐发生变化时，仍然需要修改。 最终，我将补丁版本参数替换为“增量”。所以只需指定： ``` bump-boto +1 ``` 它会将所有软件包的补丁版本增加一。当然，当次版本或对齐发生变化时，我仍然需要手动 `pkgbump` 它们，但后续的发布只需 `bump-boto` 就能正常工作，无需修改。 很长一段时间里，这是 `bump-boto` 独有的功能，而且实现相当简陋。然而，频繁的内核更新让我不得不反复输入 7 组版本号，这最终促使我将功能通用化。想象一下，每天要输入两次类似这样的命令： ``` bump-kernels 7.0.{12,13} 6.18.{35,36} 6.12.{93,94} 6.6.{142,143} 6.1.{175,176} 5.15.{209,210} 5.10.{258,259} ``` ## pkgbump 中的通用增量 最新版本的 `pkgbump` 仍然接受两个位置参数：源和目标。但它们不再必须是文件名。 目标可以是一个版本号或一个增量。所以你可以这样操作： ``` pkgbump gentoo-kernel-7.0.12.ebuild 7.0.13 pkgbump gentoo-kernel-7.0.12.ebuild +1 ``` 如果次版本变化了呢？增量可以后跟一个或多个版本组件，此时最终的组件被设置为指定值，而它前面的组件则被递增。所以你可以这样： ``` pkgbump gentoo-kernel-7.0.12.ebuild 7.1.0 pkgbump gentoo-kernel-7.0.12.ebuild +1.0 ``` 或者： ``` pkgbump gentoo-kernel-7.0.12.ebuild 7.1.2 pkgbump gentoo-kernel-7.0.12.ebuild +1.2 ``` 源可以是一个模式，脚本会找到匹配该模式的最高版本号的 ebuild： ``` pkgbump 'gentoo-kernel-7.0.*.ebuild' +1 pkgbump 'gentoo-kernel-6.18.*.ebuild' +1 ``` 至此，我可以让参数变为可选。如果省略源，则假定为 `'*.ebuild'`。如果省略目标，则假定增量为 `+1`。因此，以下命令都是合法的： ``` pkgbump 'gentoo-kernel-6.18.*.ebuild' # 目标：+1 pkgbump +2 # 源：'*.ebuild' pkgbump 1.2.3 # 源：'*.ebuild' pkgbump # 源：'*.ebuild'，目标：+1 ``` ## 集成工作流的更多选项 同时，我为 `pkgbump` 添加了一些选项，使其更适合作为一体化工具。根据给出的选项，过程变为： 1. 复制 ebuild，复制并清理。 2. 降低关键词，除非传递了 `-s`/`--stable`。 3. 如果传递了 `-E`/`--edit-early`，则运行编辑器编辑 ebuild。 4. 更新 Manifest，除非传递了 `-M`/`--no-manifest`。 5. 对比工作目录，除非传递了 `-D`/`--no-diff`。 6. 如果传递了 `-e`/`--edit`，则运行编辑器编辑 ebuild。 7. 如果传递了 `-c`/`--commit`，则提交更改。 现在可以将最初的工作流程简化为单个调用： ``` pkgbump -e -c ``` 就这样！意思是：“选择最新的 ebuild，将最后一个版本组件加一，生成 Manifest、对比、编辑并提交。” ## 轻松升级内核 这意味着我终于可以更轻松地升级内核了。脚本仍在完善中，但现在我可以指定分支而不是版本对，将它们全部加一： ``` bump-kernels 7.0 6.18 6.12 6.6 6.1 ``` 或者，我可以直接运行脚本而不带参数，让它自动确定可用的分支并全部升级： ``` bump-kernels ``` ## 未来的代码片段 `pkgbump` 的一个特性是它尝试对 ebuild 进行一些最小的清理/现代化。例如，我很早就添加了从 `PYTHON_COMPAT` 中清理旧 Python 实现的功能；它并不是紧急到需要批量更新的事情，但如果你已经在升级 ebuild，顺手做一下是值得的。 最近我想添加另一个类似的功能：更新已弃用的 `DISTUTILS_USE_PEP517` 值。同样，这不紧急；但 EAPI 9 会需要它。与 `PYTHON_COMPAT` 更新类似，它非常 Python 专属。感觉 `pkgbump` 作为一个通用工具，会积累大量特定于 Python 的逻辑。 但为什么只限于 Python 呢？我非常欢迎人们提交其他类型的清理功能；只是将所有不同的逻辑内联在一起显得有些丑陋。所以最新版本的 `pkgbump` 引入了清理片段！ Python 专用代码已从工具中移除（核心只保留了通用的版权年份更新和关键词降低逻辑），现在位于 `/usr/lib/pkgbump.d/python`。新的脚本也可以放入该目录，既可以作为 `mgorny-dev-scripts` 的一部分，也可以单独打包。还有 `/etc/pkgbump.d` 用于用户脚本，也可以用来覆盖系统脚本。所以如果你不希望 `pkgbump` 执行它的 Python 魔法，可以放一个替代的 `/etc/pkgbump.d/python`。