☰

哪些 Debian 软件包在构建时依赖于服务？

tag-icon • tag-icon debian ubuntu package-management deb
哪些 Debian 软件包在构建时依赖于服务？

我在尝试构建一个依赖于其他几个包的包时遇到问题，其中一些包包含服务。所述服务尝试在 postinst 脚本中启动，结果导致构建失败，因为在构建环境中systemd未安装该服务。

我想看看一些有类似问题的官方软件包。此时，我不需要运行依赖项的服务，但 postinst 脚本仍然需要工作（显然？！），在这种情况下，它尝试手动启动服务，因为名称与包名称（另外，该包中实际上有 2 个服务，但我离题了）。

我的脚本目前尝试执行以下操作：

systemctl enable ipload
systemctl start ipload

在任何 Ubuntu 系统上安装软件包时，它都可以正常工作，但在构建依赖于其-dev软件包的系统时会失败。

我的问题是：

有哪些现有的官方 Debian 软件包具有类似的问题：依赖于通常启动服务并在构建中需要的其他软件包？

这样我就可以让我自己的包以类似的方式工作。

答案1

您应该dh_installsystemd在包构建中使用来设置您的服务；这将在您的维护者脚本中生成适当可靠的代码片段。参见示例g810-led的debian/rules;这显示了如何处理与包名称不匹配的单元：

dh_installsystemd --no-stop-on-upgrade --no-start --name=g810-led-reboot

（您不应该使用--no-stop-on-upgrade或--no-start。）

结果postinst包含

# Automatically added by dh_installsystemd/13.3.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
        # This will only remove masks created by d-s-h on package removal.
        deb-systemd-helper unmask 'g810-led-reboot.service' >/dev/null || true

        # was-enabled defaults to true, so new installations run enable.
        if deb-systemd-helper --quiet was-enabled 'g810-led-reboot.service'; then
                # Enables the unit on first installation, creates new
                # symlinks on upgrades if the unit file has changed.
                deb-systemd-helper enable 'g810-led-reboot.service' >/dev/null || true
        else
                # Update the statefile to add new symlinks (if any), which need to be
                # cleaned up on purge. Also remove old symlinks.
                deb-systemd-helper update-state 'g810-led-reboot.service' >/dev/null || true
        fi
fi
# End automatically added section

这使用deb-systemd-helperwhich 来处理带或不带的安装systemd。

您还会看到相应的prerm和postrm。

-dev然而，包裹最终取决于包裹运输服务的情况并不常见（但并非闻所未闻） ；您可能希望进一步拆分内容（例如-dev包、库包和包含服务的包）。

答案2

我很难得到dh_installsystemd为了工作，所以我想对我为使其完美（几乎1）所采取的各种步骤有自己的答案。

  1. 让它变得冗长

    除非您打开详细信息，否则工作时的功能痕迹可能会非常轻。这是通过将以下内容添加到debian/rules文件中来完成的：

    export DH_VERBOSE=1

    调试完成后删除或注释掉。

  2. 将文件放置在debian/...

    在我的原文中，该文件被定义为contrib/ipload.service.我正在安装文件用手（使用该iplock.install文件），然后使用systemctl命令来设置服务²。

    为了与 systemd 提供的 debhelpers 一起使用，您需要将文件移动到debian/...如下所示：

    git mv contrib/ipload.service debian/iplock.ipload.service

    请注意名称如何变化。现在分为三部分：

    • iplock-- 我们要添加服务的包的名称
    • ipload-- 服务文件的名称（和之前一样）
    • service-- systemd 文件的类型，服务

  3. 确保兼容性级别正确

    现在有两种方法来定义兼容性级别。老办法，就是有一个debian/compat文件。该文件仅包含一个级别（即带有十进制数字（如 12）的测试文件）。

    debhelper-compat新方法是在文件中创建依赖项debian/control。

    Build-Depends: debhelper-compat (= 12), ...

    无论哪种方式，请确保它至少为 12，否则将覆盖 systemd debhelpers才不是完全启动（它们将被忽略）。如果您不久前创建了软件包，那么仍然使用较小的兼容性级别并非不可能。

  4. 实际安装服务文件

    与许多项目相反，这个项目有两个.service文件。一个被调用ipwall.service并放入ipwall包中的。另一个，如上所述，它已命名ipload.service并且必须放入iplock包中，而第二个由于名称不匹配而失败。

    如上所述，我首先必须正确重命名该文件 ( <package name>.<service name>.<extension>)。然后我必须像这样进行覆盖：

    override_dh_installsystemd:
    dh_installsystemd
    dh_installsystemd --name=ipload

    第一次调用正确dh_installsystemd安装ipwall（所有默认值，像往常一样，真的）。第二个调用指定一个名称 ( ipload)，这就是安装的内容...您可能会问？！这是由上面提到的文件名定义的：iplock.ipload.service，因此它将安装在iplock.

1 我说几乎因为我仍然有一个问题，因为用户被创建，然后服务启动，然后设置被更新。因此，第一次运行时使用默认设置，无需管理员进行更改。我猜，一次一个问题。

² 这就是我之前遇到的问题，因为 systemd 没有安装在构建系统上。请注意，在使用任何 systemd 工具之前，脚本实际上会测试是否/run/systemd/system是目录。

if [ -d /run/systemd/system ]
then
    ...here you can use systemctl...
fi

相关内容