用了一段时间，大概了解了下 Calamares 怎么用的，基本做出来了一个可用的安装程序，后面我尽量参考官方文档，写一个指南，可以看作是官方文档的翻译。
前一篇相关文章介绍了 Calamares，它是一个为发行版提供的安装程序，所以他的配置等并不面向最终使用者，而是发行版本的制作者。它设计得高度可配置，适用于广泛的使用场景，所有配置都通过 YAML 配置文件完成。随 Calamares 一起提供的文件是示例配置文件，这些文件还包含每个文件中设置的文档。
官方建议发行版将配置文件与 Calamares 本体分开打包，并安装到 /etc/calamares 中，不过 Magic 目前没有遵守此建议，因为 Fedora 没有。
它的配置有两类，一是模块（module)，基本上是安装程序的各种行为；一是品牌化（branding），是设置安装程序的外观等。
Calamares 模块是提供诸如安装程序页面、批处理作业等功能的插件。安装程序页面（用户可见）称为“视图”（view），而其他模块则称为“作业”（jobs）。
每个 Calamares 模块都位于自己的目录中。Magic 上所有模块都安装在 /usr/lib64/calamares/modules 中。
视图（view）模块是用于用户可见的模块。这些模块使用 C++ 和 Widgets 或 QML 编写。
作业（job）模块用于非用户可见的模块。这些模块可以使用 C++、Python 或作为外部进程实现（不推荐使用外部进程）。
视图模块向用户暴露用户界面（UI）。
Calamares 的模块有三种接口：
qtplugin（两种模块都有）
python（仅限作业模块）
外部进程（仅限作业模块，不推荐）
Calamares 模块必须有一个模块描述符文件，名为 module.desc。对于使用 CMake 作为构建系统的 C++（qtplugin）模块，并使用 calamares_add_plugin() 函数——这是创建此类模块的推荐方式——模块描述符文件是可选的，因为它可以由构建系统生成。对于其他模块接口，模块描述符文件是必需的。
如果需要，模块描述符文件放置在模块目录中。模块描述符文件是一个 YAML 1.2 文档，它定义了模块的名称、类型、接口以及可能的其他属性。在 module.desc 中定义的模块名称必须与模块目录的名称相同。
模块描述符必须具有以下键：
name（一个标识符；必须与目录名称相同）
type（”job” 或 “view”）
interface（见下文的不同接口；通常我们通过接口来指代模块的类型）
C++ 模块的模块描述符可以具有以下键：
load（要加载的共享库的名称；如果为空，则使用从模块名称派生的标准库名称）
Python 模块的模块描述符必须具有以下键：
script（要加载的 Python 脚本的名称，几乎总是 main.py）
外部进程模块的模块描述符必须具有以下键：
command（要运行的命令）
进程模块的模块描述符可以具有以下键：
timeout（等待命令运行的秒数）
chroot（如果为 true，则在目标系统中运行命令，而不是主机系统）请注意，不推荐使用进程模块。
模块描述符可以具有以下键：
emergency（一个布尔值，设置为 true 以将模块标记为紧急模块；见下面的紧急模块部分）
noconfig（一个布尔值，设置为 true 表示模块没有配置文件；默认为 false）
requiredModules（此模块正常运行所需的模块列表）
weight（相对模块权重，用于缩放进度报告）。
Calamares 模块可以读取一个模块配置文件，名为 <modulename>.conf。如果模块目录中存在这样的文件，它可以作为默认配置文件提供。这仅在 CMake 时选项 INSTALL_CONFIG 为开启时发生。
给定模块的配置文件名称可以受整体 Calamares 配置的 settings.conf 影响。不过，默认情况下，使用模块自身的名称。
将 noconfig 设置为 true 的模块不会尝试读取配置文件，也不会警告缺少配置文件；相反，如果 noconfig 设置为 false（或缺失，因为默认值为 false），如果没有配置文件，则在 Calamares 启动期间会打印警告。
示例配置文件可能适用于您的发行版，但除了语法正确性之外，不保证其稳定性。
如果存在，模块配置文件是一个 YAML 1.2 文档，包含任何内容的 YAML 映射。
所有示例模块配置文件都安装在 /usr/share/calamares/modules 中，但可以通过手动（或由打包者）放置同名文件在 /etc/calamares/modules 中来覆盖它们。
在安装的 exec 阶段，运行作业并对目标系统进行操作时，有一个运行中的进度条。它从 0% 到 100%，同时运行该 exec 阶段的所有作业。通常，一个模块创建一个作业，但这会有所不同（例如，分区模块可以生成一堆作业来处理每个磁盘，用户模块有单独的作业用于常规用户和 root 用户）。
默认情况下，所有模块的“权重”相同，每个作业相等。典型的安装在 exec 阶段有大约 30 个模块，因此可能有 40 个左右的作业：每个作业代表安装整体进度的 2.5%。
结果是，unpackfs 模块需要将几百 MB 写入磁盘，却只获得 2.5% 的进度，而 machineid 模块本质上是瞬时的，也获得 2.5% 的进度。这使得进度报告看起来奇怪且不均匀，并向用户暗示 Calamares 可能在 unpackfs 阶段“挂起”。
模块可以在 module.desc 文件中（或通过添加插件的 CMake 宏）分配不同的“权重”。这为模块在整体进度中提供了更多空间：例如，unpackfs 模块现在权重为 12，因此（假设 exec 阶段有 38 个权重为 1 的模块，以及 unpackfs 的权重为 12），常规模块获得整体进度条的 2%（1/50 总权重），unpackfs 模块获得 24%（12/50）。虽然这不会加速任何事情，但它确实使 unpackfs 模块的进度更可见。
也可以在 settings.conf 中为特定模块实例设置权重。这会覆盖模块描述符中设置的任何权重。这样做是推荐的方法，因为那是配置特定安装过程的地方；可以在那里考虑整个安装过程来确定相对权重。
上面基本上是官方文档的翻译，简单的说就是可以通过修改settings.conf和对应模块的.conf文件来配置 calamares 的行为。所以下一篇文章主要介绍如何配置这些模块。
标签：