有两种基本方法。

编译时配置

这是许多软件包装商所采用的方法。

一种使用宏。在程序包生成时，某种形式的宏预处理程序将在宏化的服务单元文件上运行，并带有代表配置的参数。输出，然后放入包装中，是定制的服务单元文件。

systemd本身就是一个例子。该kmod-static-nodes.service.in文件包含宏：

ExecStart = @ KMOD @静态节点--format = tmpfiles --output = / run / tmpfiles.d / static-nodes.conf

构建systemd的大量Python脚本（称为“ Meson”）包含基于正则表达式的宏预处理器中的许多其他内容。该预处理器在上运行kmod-static-nodes.service.in，替换KMOD宏以产生kmod-static-nodes.service进入软件包的宏。替换是一个字符串，它是kmod可执行程序映像文件的路径，在编译时由Python脚本搜索。（我不打算讨论大型Python脚本系统的细节，因为这远远超出了此答案的范围。）

该方案的缺点是必须在与安装该软件包的目标计算机相同的方式并包含与安装该软件包的目标计算机相同的程序的计算机上创建软件包。每个操作系统的软件包都可能不同（即使版本不同）。

安装时配置

插件

另一种方法是通过生成.conf将服务单元调整到目标系统的插入文件，在安装时配置一个静态服务单元文件。它们不是理想的，因为它们当然会导出到服务流程中，但是可以为此使用环境变量。

例如：静态服务单元文件/usr/lib/systemd/system/wibble.service可以说

ExecStart = / usr / bin / wibble $ OPTIONS

然后，用于安装操作的软件包维护脚本会在安装时动态创建一个文件，其中包含在安装时在当前计算机上计算出的定制选项，而不是在软件包创建时在另一台计算机上计算出的定制选项：/usr/lib/systemd/system/wibble.service.d/20-options.conf

环境=选项=摆动-果冻-o板

这种方案的缺点是，如果软件包已被完全清除，则用于deinstall操作的软件包维护脚本必须记住删除此文件，并且必须记住将其挂接到configure操作中，以便系统管理员可以显式强制重新生成如果他们重新配置或重新排列东东文件。

预处理

前面提到的一种变体是回到宏预处理。实际上会发布宏化的服务单元文件，并在安装时对其进行预处理。

如果根本不制作软件包，而只是将所有内容存储在ustar存档中供系统管理员手动安装，则比生成的插件更可行。

这样做的缺点是，宏预处理系统（如Meson中的宏预处理系统）与Python脚本集合紧密耦合，因此不能作为独立工具使用。对于独立预处理工具之一有这样的人m4，cpp和其他人，其中没有一个是非常适合预处理.ini文件，并作出各种决定（例如“检测的哪些选择wibble方案需要在本机上。”“在哪里是kmod在这台机器上？”）通常涉及到的。

显然，这里没有人发现过一种工具的利基市场-我听说过，无论如何。

在shell脚本中，command -v 可以进行路径查找和ex替换操作。但是（对于大多数人而言，）对路径名中的空格和元字符之类的东西进行强化（或者大多数人不会这么做），或者允许使用转义机制来防止在不需要的地方进行宏扩展，这并非易事。

Perl的字符串处理比shell脚本要安全一些，但是并不是每个操作系统都具有开箱即用的Perl（请参阅“是否有Perl不附带的类Unix系统？ ”），因此必须告知系统管理员以确保首先安装Perl。给定systemd的大型Python脚本集合构建系统，Python显然可以做到这一点。但是，这就存在系统管理员要在您身上更改Python版本，并从您身下抽出毛毛的问题（参见“ apt-get update在重建损坏的PATH变量后不再起作用”，并且所有Ask Ubuntu问题都超链接了） -到那里）。其他可能性包括TCL。

在紧握的手上……

有时，这种可配置性首先是不必要的。@KMOD@实际上，systemd中的宏不是必需的。现在（今天）可以工作：

ExecStart = kmod静态节点--format = tmpfiles --output = / run / tmpfiles.d / static-nodes.conf

将数据库表（某种形式）转换为服务单元？运送发电机。

指定默认的启用/禁用状态？出厂预设。