AOSC Wiki / 开发者 / 打包 / .
其他语言： English

软件包维护入门：基础教程

了解 AOSC OS 打包流程

注意：这篇指南假定您对 Linux 和它的命令行界面有一定的认识。此外，您还需要装有 Linux 且有 root 访问权限的电脑。

打包工具

我们使用如下几个工具维护 AOSC OS 软件包：

接下来几个章节中，我们会一一介绍这些工具的使用方式。

发行方式

AOSC OS 是滚动发行版，这意味着 AOSC OS 整体发行时不使用版本号（类似于其他滚动更新的发行版，如 openSUSE Tumbleweed 和 Arch Linux）。但与其他滚动发行版不同，aosc-os-abbs 树中有一组特殊的，包含核心运行时 (GNU C 库等）和工具链（GCC 等）的软件包，我们将它们统称为 AOSC OS Core。AOSC OS Core 整体以版本号表示组件更新（Core 7.0.1, 7.0.2, 7.1.1 等）。

作为滚动发行版，我们只有一个面向用户的分支：stable。在更新或引入新软件包时，开发者们在软件包树（前面提到的 aosc-os-abbs）中创建专用分支，基于分支更改创建 Pull Request，并将测试用软件包上传到独立的软件源分支中。用户可以通过使用 AOSC OS APT Topic Manager（简称 ATM）提前测试更新或新包。软件包测试通过后，开发者将商议合并 Pull Request 并基于 stable 环境重构软件包，并推送至 stable 软件源。

我们称该工作流程为“主题制迭代模型（Topic-Base Iteration Model)”。该迭代模型的设计初衷是降低开发者的工作压力并保障软件包质量。您可以阅读主题制维护指南 (Topic-Based Maintenance Guidelines) 了解详情。

配置环境

配置环境的第一步是安装 Ciel，如果您在使用 AOSC OS，您可以直接使用 apt install ciel 安装 Ciel。

Ciel 的主要功能为管理独立的 AOSC OS 构建环境（通称 BuildKit），因此 Ciel 不一定需要在 AOSC OS 上运行。如果您使用的是 Arch Linux，可以通过 AUR 安装 Ciel。

接下来，我们可以开始配置 Ciel 工作区了。该教程使用 ~/ciel 作为 Ciel 工作区路径进行演示。注意：Ciel 需要使用 root 运行，且不能在 Docker 容器中运行。请运行如下几个命令并跟随屏幕指示配置 Ciel 工作区；在向导问是否需要创建新实例时，请选择是，并创建一个名为 main 的实例。

mkdir ~/ciel
cd ~/ciel
ciel new

工作区配置完成后，我们建议更新 BuildKit 环境（AOSC OS 打包者必须保证 BuildKit 环境为最新）。

# 如果这一步耗时很长，您可以考虑通过 "ciel config" 设置 APT 源配置 (sources.list)。
ciel update-os

初试打包

一切准备就绪，我们来尝试构建一个已在树中的软件包。我们先挑个简单的 extra-multimedia/flac 来打。

执行如下命令即可构建 flac 软件包。

# -i 参数用于指定实例名。
ciel build -i main flac

如果构建过程成功完成并显示 Build Summary 提示，恭喜，您的处女包打出来啦！您刚刚打出来的包已由 Autobuild3 存放于 OUTPUT-stable/debs。

引入新包

本章节介绍如何引入软件包，为此我们需要从头编写软件包配置。

首先，切换至 TREE 目录，在这个目录中有许多用于分类整理的，以 base-，core- 或 extra- 开头的子目录。这些目录中就是各个软件包的配置文件夹了。

以 i3 为例，这个软件包位于 extra-wm/i3，在切换到这个目录后，我们会发现其内部文件结构如下：

    .
    ├── autobuild
    │   ├── beyond
    │   ├── conffiles
    │   ├── defines
    │   ├── overrides
    │   │   └── usr
    │   │       ├── bin
    │   │       │   └── i3exit
    │   │       └── share
    │   │           └── pixmaps
    │   │               └── i3-logo.svg
    │   ├── patches
    │   │   └── 0001-Use-OVER-operator-for-drawing-text.patch
    │   └── prepare
    └── spec

接下来，我们来了解下每个文件和文件夹的作用。

spec

spec 文件提供用于指示 ACBS 下载源码文件的配置，以及软件包版本和修订 (Revision) 级别。该文件内容大致如下：

VER=4.17.1  # 软件版本。
# REL=0 软件修订级别。该变量默认赋值为 0。

# 如使用源码压缩包 (tarball) 。
SRCS="tbl::https://i3wm.org/downloads/i3-$VER.tar.bz2" # 源码包下载地址。
CHKSUMS="sha256::1e8fe133a195c29a8e2aa3b1c56e5bc77e7f5534f2dd92e09faabe2ca2d85f45" # 源码包校验和。

# 如使用 Git 源码。
SRCS="git::commit=$COMMIT_ID::https://some.git.hosting/somewhere"
CHKSUMS="SKIP"

# 如使用多个源码。
SRCS="git::commit=$COMMIT_ID::https://some.git.hosting/somewhere \
      tbl::https://some.domain/source_tarball.tar.gz \
      file::https://some.domain/souce_code_file"
CHKSUMS="SKIP sha256::some_checksum sha256::sume_checksum"

在这里尤其需要注意修订级别的值：在引入新软件包或更新现有软件包时，您可以忽略 REL= 变量，但在对进行软件包修订且软件包版本不变时，您需要通过提高某个软件包的修订级别以告知软件包管理器需要更新该软件包。在这种情况下，将 REL= 值加 1 即可。

autobuild/

该文件夹存放 Autobuild3 定义及脚本文件。Autobuild3 可以通过解析这些文件（使用什么构建系统？使用什么构建参数？等）来组织构建流程。

autobuild/defines

该文件定义软件包的各项核心配置：

上面列出的只是最常见的几个配置项。Autobuild3 还有许多其他配置参数，但如果软件包依赖信息和构建流程相对标准，一般不会需要使用其他参数。Autobuild3 会自动填入编译器参数、构建系统等其他构建参数。

以 extra-wm/i3 为例：

PKGNAME=i3
PKGSEC=x11
PKGDEP="dmenu libev libxkbcommon pango perl-anyevent-i3 perl-json-xs \
        startup-notification xcb-util-cursor xcb-util-keysyms \
        xcb-util-wm yajl xcb-util-xrm"
PKGRECOM="i3lock i3status"
BUILDDEP="graphviz doxygen xmlto"
PKGDES="Improved tiling WM (window manager)"

PKGCONFL="i3-gaps"

此外，defines 也支持 Bash 逻辑判断式，便于定义针对特定平台的配置或依赖等，但是这一用法现在已不推荐使用，以后也会禁止这种用法。如需定义特定平台的各项配置信息，请使用 $VAR__$ARCH（如 AUTOTOOLS_AFTER__AMD64）变量。

如需了解其他 Autobuild3 参数，请参阅 Autobuild3 用户及开发者手册 (Autobuild3 User and Developer Manual)

autobuild/prepare

该文件是在构建过程开始前运行的脚本，常用于准备文件或设置构建过程中使用的环境变量。

autobuild/patches/

该文件夹存放构建前要应用的补丁文件，将补丁文件放入该文件夹即可。

实操案例：light

接下来，我们来实战软件包配置编写。该章节介绍 light 这个简单软件包的构建配置编写方式。该软件提供一个用于控制笔记本背光的简单命令，而且因为实现原理只依赖文件 API，该软件只依赖 glibc。

首先切换到 TREE 目录，并确定我们目前处于正确的 Git 分支。如前面提到的主题制迭代流程所要求，您需要首先为这个包创建一个 Git 分支。由于要引入新软件包，根据 AOSC OS 主题制维护指南 (AOSC OS Topic-Based Maintenance Guidelines)，分支名称应为 $PKGNAME-$PKGVER-new，即 light-1.2.1-new。

因为 light 属于实用工具，我们要在 extra-utils 下创建 light 目录。

cd TREE/extra-utils
mkdir light
cd light

接下来，编写 spec 文件。首先，查阅项目网站并辨认最新版本源码包的下载 URL。在计算 sha256 校验和后，我们即可将各项信息填入文件。

VER=1.2.1
SRCS="tbl::https://github.com/haikarainen/light/archive/v$VER.tar.gz"
CHKSUMS="sha256::53d1e74f38813de2068e26a28dc7054aab66d1adfedb8d9200f73a57c73e7293"

注意：我们在源码包 URL 中使用了 $VER 变量，这是个好习惯——因为这样一来，在更新软件包时就不需要再编辑 URL 了。

随后要创建的是 autobuild 文件夹和其中的 defines 文件。完成后的 defines 大致如下：

PKGNAME=light
PKGSEC=utils
PKGDEP="glibc"
PKGDES="Program to easily change brightness on backlight-controllers."

一切就绪！现在即可运行如下命令构建 light：

ciel build -i main light

很简单，对吧？这是因为 Autobuild3 的自动探测功能判断出这个包需要使用 autotools（即 ./configure && make && make install）流程进行构建。

Git 操作规范

软件包构建完成后，接下来要做的就是提交你的构建脚本了。AOSC OS 对 Git 提交说明有着相当严格的要求，下面介绍的是几个常用格式。我们在软件包风格手册 (Package Styling Manual) 描述了全部打包风格规范，建议择时阅读。

如需往树内增加软件包，Git 提交信息应为如下：

light: new, 1.2.1
$PKG_NAME: new, $VER

如需更新现有软件包，提交信息应为如下：

bash: update to 5.2
$PKG_NAME: update to $NEW_VER

另外，我们要求在提交信息中详细描述对软件包构建配置中的具体更改（如依赖变化、特性开关等），如下例：

bash: update to 5.2

- Make a symbolic link from /bin/bash to /bin/sh for program compatibility.
- Install HTML documentations.
- Build with -O3 optimisation.

上传软件包

在成功构建软件包后，您可以将本地 Git 分支（如 light-1.2.1-new）推送至您的 fork 中（如有提交权限，可推送至主树中）。随后，您需要创建 Pull Request 并按模板要求填入信息，最后即可将软件包推送至社区软件源的测试分支中供用户测试。

我们要求使用 pushpkg 推送成品软件包。如果您在使用 AOSC OS，可以直接安装 pushpkg 包（否则可以自行下载脚本，将其添加到可执行文件目录中，并确定脚本已设定可执行位）。一切就绪后，便可在切换到 OUTPUT 目录后执行 pushpkg 上传软件包。请注意，该脚本需要您指定自己的 LDAP 凭证和目标源分支（light-1.2.1-new）。

接下来，请静候 Pull Request 审核和软件包测试。如果一切顺利，在您的 Pull Request 被合并后，请重构相关软件包并将其上传至 stable 源。

结语

恭喜，您已掌握为 AOSC OS 引入、更新、构建和上传软件包的基础技能！

但如您所见，本文只概述了软件包维护的基础知识点。在需要构建更复杂的软件包和批量更新软件包之前，您还需要学习一些进阶知识。请参阅软件包维护入门：进阶教程。

↑