altlinux

0 引言

ALT Linux 是源自俄罗斯的 Linux 发行版, 基于 RPM 软件包格式与 APT-RPM 包管理体系构建. 就算是官网对于系统本身的介绍也不够详细.

ALT Linux创始于2001年, 由两个大的俄罗斯自由软件计划合并而来. 2008年它成为了一个大的组织, 从事自由软件的开发和部署、文档和技术资料撰写、用户支持及定制产品开发工作. ALT Linux面向不同的目的生产不同类型的发行.这包括面向家庭、办公计算机、企业服务器的各种桌面发行, 广泛包含各种开发工具和文档的通用发行, 认证产品, 面向教育机构的专用发行, 以及面向低端计算机的发行. ALT Linux拥有自己的基础开发设施和软件仓库, 称为Sisyphus, 它为所有不同类型的ALT Linux提供基础. (https://distrowatch.com/table.php?distribution=alt)

PS: 由于这是一个俄罗斯的发行版, 对于中文生态的支持是不太足够的, 甚至官网对英文的文档翻译都不够完善, 下篇我们抛开国别问题对该发行版进行探索.

1 系统理念

在 “What Is ALT Linux” 一文中, 我们可以看到 altlinux 设计的理念(下文已加粗).

• 首先是高可靠性, 这里的高可靠性笔者认为体现在对包的管理, 首先用 hasher 隔离构建环境(当然对包启用隔离环境的编译笔者认为很多发行版都会去做), 用 repocop 检测包的安全性问题(这里下文会提到, 实际上就是在软件包进入仓库之后依然定期检测包的完整性以及规范性问题).

• 更新的便利性与可用性, altlinux 明确自己有维护一个稳定的上游仓库 Sisyphus, 下文会介绍到, 在特定的时间会从该仓库衍生出一个新的较为稳定的仓库分支使用, 开发者和测试人员长期维护 Sisyphus.

  Sisyphus … is the main development repository for all ALT Linux distributions.
  Stable branches are derived from Sisyphus by freezing its state at a given time.

• 简洁有逻辑的用户界面, 这里主要指的是 GUI, 直接展示(GNOME 2, KDE 3, Enlightenment E17), 这里笔者没有体会到桌面优势, 只是觉得很复古轻量直观.

  ALT Linux 4.1 GNOME 桌面.

  

  ALT Linux 6 “KDesktop” 桌面.

  

  ALT Linux “E17” 桌面

  

  https://commons.wikimedia.org/wiki/File:AltLinux-4.1.png

  https://linuxbsdos.com/2011/09/25/alt-linux-6-kdesktop-review/

  https://linux.softpedia.com/get/System/Operating-Systems/Linux-Distributions/ALT-Linux-E17-50260.shtml

• 遵循标准和高质量的本地化支持(可能是这么翻译), 笔者认为这是一个 Linux 发行版所必备的必须性质, 不作为一个有竞争性的特质.

The objective of the ALT project is to develop and support a wide spectrum of solutions based on free software, characterized by high reliability and security, convenience and availability of updates, a simple and logical interface, standards-compliant and high-quality localization and language support. (https://docs.altlinux.org/ru-RU/archive/2.3/html-single/compact/alt-docs-compact-en/ch01s02.html)

综合定位来看, 笔者认为 altlinux 想打造的是一个高稳定性且简洁的桌面级操作系统. 虽然开篇说明了下文抛开国别问题来讨论, 但是目前来看笔者认为限制系统最大发展的就是他的语言问题, 所有的文档, 论坛, 资源几乎全市俄语, 这严重地限制了它地传播. 另外很重要的就是下文会提及的, 他拥有很完整的构建系统, 但都是自研的, 这同 openEuler 社区不一样, openEuler 继承自 Red Hat, 竞标对象至少笔者了解到的初期就是 CentOS, 系统采用了打量地主流发行版工具链, 这对于使用者来说是很熟悉的, 对于开发者来说也易维护易兼容(另外就是仓库维护的问题, 在 altlinux 的 github 上可能不能够找到较为完整的软件仓库, 在 altlinux 自家提供的 git 服务器上可以找到, 但是很明显没有 github 的便捷.).

两图均截取自官方的用户文档, 很明显看到就连用户文档在官方自带的英文语言下都存在大量的描述缺失.

2 软件生态

2.1 hasher

• 项目文档

• 项目仓库

hasher(前身叫sandman) 是 altlinux 的核心构建工具, 几乎所有该系统下的软件包都是通过 hasher 构建出来的.

hasher 的核心理念是构建环境与宿主环境完全隔离(这是必须的, 貌似在许多系统下构建环境的隔离永远是此类构建, 编译工具的一个前提, 这已然成为行业的默认标准).

该工具的流程很简单: 构建隔离环境, 根据 .spec 安装依赖, 然后使用 rpmbuild 编译打包, 最后导出 .rpm 的结果.

更简单来类比一下, hasher 更贴切于 obs_build, 但是对比起来 hasher 又是纯本地的构建工具, 不依赖于远端的配置, obs_build 更像一个分布式的执行组件. openEuler 目前是否缺少有这种本地化的构建工具(rpmbuild上层可以继续包装)?

2.2 gear

• 项目文档/github提供的文档

• 项目仓库

gear 是一个用于从 git 仓库构建 RPM 包的工具(.gear/rules, 可以看到出了 gear 每个软件仓库下都有一个 .gear 目录.).

通俗来讲, 笔者认为 gear 的意义就是把打包流程通 git 串起来. 寻常的 rpmbuild 以及一些打包工具都是本地进行的, 要么就是需要通过远端一个专门的服务器进行链接打包, 但是这里依靠 git 就能直接完成 patch, 打包等操作.

另外这里和其他发行版的一个显著区别, 笔者认为这里通过 gear 将源码仓库和软件包仓库合并在了一起, 而 openEuler 是有一个源码仓和一个软件包仓分开存放的.

gear 能自动从 git 仓库拉下进行处理(按 .gear/rules 的定义去做, 下面还可能有 .spec 这些), 最后产出 SRPM, 之后就协同 haser 之类的工具进行构建产出 RPM(使用 gear-hsh).

那么有了这样的一个工具之后我们的好处是什么? 最重要的还是自动化, 在传统的方式里(例如 openEuler), 笔者在修包过程中通常会先拿到如 tar.gz 格式的源码包, 之后修改版本号, changelog, patches等. 但是这些过程在该工具下是自动完成的, 我们只需要关注修改代码的过程, 然后 gear-commit. 这样一份可维护, 规整的提交就完成了, 他会自动比较 upstream 和本修改分支的代码.

The .gear/rules file will be of the following form:

tar: v@version@:foo

diff: diff: v@version@:foo foo

This will generate foo.tar, containing upstream source code, taken from the tag v${version}, where version is parsed from the foo.spec, and the diff is containing the difference between the directory foo in v${version} tag and current content of the directory foo. (https://en.altlinux.org/Gear/Introduction#Scenario_2._%22Small_fixes%22)

PS: “diff: diff: v@version@:foo foo” 这个写法我貌似在官网的软件当中还没找到过示例, 只在官方文档看到了

2.3 repocop

• 文档介绍

• 测试结果页面

repocop 是 altlinux 的自动化 QA 系统, 它的代码在 github 上查询不到, 而是维护在自己的 Git 基础设施上.

源自: https://git.altlinux.org/gears/r/

总体的流程上, 开发者使用 gear, hasher 等工具打包之后, RPM 被上传到了 Sisyphus (下文会介绍到, 这里可以理解为一个 repo), 此时会触发 altlinux 的 repocop 系统, 经过系统检测后的结果会被上传到测试结果页面(结果输出是一个 report 的形式, 本节开头有链接).

Результаты тестов можно просмотреть либо непосредственно в кеше, либо воспользоваться каким-либо генератором отчетов, например, repocop-report-txt.

这里我们不难看出, repocop 是专为软件包设计的自动化 QA 系统. 那么它能进行什么检测呢?

包的一些依赖性, 安装路径, 许可, spec 规范, 文档完整性等进行检测.

这里不太确定是不是具有检查这些内容的功能, 主要是对测试报告下的 txt 进行的猜测: https://repocop.altlinux.org/pub/repocop/reports/txt/by-test/

那么这里和 openEuler 进行对比, 在 openEuler 下不存在这样一个专门对 RPM 进行检测的系统(笔者说明的专门指的是不存在这样一个独立的监测系统), 在 RPM 构建的过程中我们就已经对其进行了规范的检测. 而 altlinux 在 RPM 构建完成之后再对仓库进行了一次全盘扫描, 即使包进入了仓库, 也可能会被 repocop 扫描出问题.

被 repocop 扫描完成出了错误, 生成了错误报告, 之后呢?

在该框架中, 出了报告的分析, altlinux 还提出了 repocop 的包修复功能, 该功能由 repocop-tools 模块完成, 而 openEuler 的体系只会检测不会修复.

但是 altlinux 社区并不会太信任 repocop 给出的修复方案(毕竟该修复不是语义级的, 而是基于一种模板规则进行修复的), 具体的修复补丁是否被采纳还需要由对应的维护者来决定.

我们可以从 https://www.altlinux.org/Repocop/RepairMiniHOWTO, 查看 repair 的流程;

repocop 生成的 patch 在 repocop.altlinux.org/pub/repocop/reports/diff.

2.4 mkimage

• 项目文档

• 项目仓库

mkimage 是转为 altlinux 设计的官方构建系统. 它的作用是根据一组模板和配置文件, 自动生成不同类型的系统映像: ISO, LiveCD, rootfs, disk image, container, bootable USB 等.

mkimage is an altinux-specific tool for building images (most often ISO9660 ones) from RPM packages and image profile directory.

更明显地该工具依赖 apt 和 hasher 来完成包的依赖解析和安装. 如果进一步同 openEuler 对比的话, 笔者认为它的功能和 imageTailor 相似.

而相比而言, mkimage 的设计理念是 “Creating an image is similar to compiling a program.”. 这里主要 get 到的是一种软件的设计思想. 景象的构建存在多个阶段, 前一个阶段的输出作为下一个阶段的输入.

Creating an image is similar to compiling a program. This is a task that isn’t intended for the average user. As well as the process of creating a profile.

We have a hierarchy of stages of creating an image. Each higher stage receives the results of the lower ones. Each of the stages is treated identically, starting with the deepest level of nesting.

基于官方的介绍, 笔者虽然没有使用过该软件, 但是这样分阶段是否就能够在执行任务的时候不必一蹴而就(下文基于对现有 imageTailor 的改进猜想)? 比如在 2 阶段出错, 我们没必要重新经过 1 阶段, 另外多个格式的镜像也可以共享统一份配置文件. imageTailor 在每次出错之后都必须重新执行一次脚本, 从头开始构建, 这样非常麻烦.

# 来自官方的 github 仓库
ISO image
\- installer
   \- stage1
   \- stage2
   \- stage3
      \- stage3.1
      \- stage3.2
  \- stage4
\- RPMS.base
\- RPMS.extra

2.5 alterator

• 项目文档

• 项目仓库

alterator 是一个系统配置的框架(用来配置系统各个方面), 包括 altlinux 启动的安装也是由该软件提供的.

可以看到 alterator 是模块化设计的, 每项配置功能都是独立的一个 module, 可以单独安装和更新.

在 openEuler 社区中, Anaconda 主要用于执行系统的自动化安装. 而 Alterator 的不同之处在于, 它不仅作为安装器使用, 还能够在系统的日常运行中继续发挥作用, 通过模块化接口实现系统的统一配置与集中管理. 相较之下, openEuler 目前尚缺乏这样一种集成式的系统配置管理框架.

3 系统特性和项目

3.1 APT for RPM

“APT 是 RPM 的前端”, 这是很出乎意料的一个点, 在所有形式下几乎默认了 “dnf/yum for rpm” 以及 “apt for dpkg”. 这里 altlinux 转其道而行之.

Если кратко, то:
APT - пакетный менеджер
RPM - менеджер пакетов

apt for rpm 的优点在于, “APT 通过自动处理依赖关系和更新来简化流程(翻译自google)”(这如何能算作一个优点呢? 笔者没太能理解.).

APT упрощает процесс, автоматически обрабатывая зависимости и обновления

实际上, 不仅仅是笔者, 对于大多数普通使用者而言, 在日常使用过程中往往并不会刻意区分或关注 dnf/yum 与 apt 这类包管理前端.

除非是从零构建系统的 LFS 用户, 否则包管理工具的选择更多是一种发行版内部的约定俗成. 一类系统天然采用 “apt for dpkg”.另一类系统则使用 “dnf/yum for rpm”.

因此, 如果没有显著的性能或生态层面的收益, 大多数用户在体验层面上并不会直接感知两者的差异.

从这一角度看, 笔者认为 ALT Linux 采用 apt-rpm 的原因更多是历史原因.

笔者认为, 这里继续采用 apt-rpm 的方式主要是 altlinux 早期就选择了这种包管理方式, 已经投入了一定的维护成本(甚至可能考虑到一些兼容性问题), 整个构建流程目前早已与其绑定.

Some distributions using APT-RPM … ALT Linux: APT-RPM is the main, officially supported way to upgrade packages from the ALT Linux repositories in ALT Linux distributions since 2001. (https://en.wikipedia.org/wiki/APT-RPM)

3.2 Sisyphus

• 仓库站点

首先要回答 Sisyphus 是什么.

Sisyphus 是 altlinux 团队维护的一个项目——它的目标是构建和发展自由软件仓库, 方便在其基础上开发发行版和其他解决方案.

Sisyphus (Сизиф) — это разрабатываемый ALT Linux Team проект, целью которого является развитие репозитория свободного ПО для удобной разработки на его основе дистрибутивов и других решений

这里的概念绕了一大圈, 可能还是比较困惑, 它是一个软件吗? 不是; 它是一个解决方案吗? 也不是. 笔者的理解是它是一个基础仓库(采取的滚动更新的方式)(从站点信息我们可以看到, 就仅仅是一个普通的仓库, 而 altlinux 团队赋予了它特殊的用途.), 里面集成了 altlinux 团队自己维护的稳定的 Linux 内核, 一些 Linux 的基础软件, 并且搭配社区的其他软件集成了自动化测试交付的功能.

目前这个菜篮子装满了各种架构的菜, 以满足各架构开发者的需求(这里的意思是已经支持 riscv 架构, 但是笔者倒是没有见到有 riscv 分支, 相关文档页面也没有提及.).

В настоящий момент Sisyphus доступен для архитектур x86, x86_64, aarch64, RISC-V, LoongArch64, Эльбрус (e2kv3 и новее) и ведется работа по портированию на другие платформы.

但是很明显的问题是, 这个菜篮子只装着满街的大白菜(一些常用的基础软件), 还有自家的菜(上述描述的生态软件). 于是不能跨发行版使用.

我们试着分析一下 Sisyphus 的优势.

• 滚动更新, 仓库持续演进推动, 这点比较清晰.

• 可以直接作为下游发行版的一个构建基础, 以及作为子分支仓库持续更新且稳定的上游(这里子仓库比如新分出了一个stable分支的仓库是否会继续更新这里应该是不会的, 我不是很确定, 问了一下 GPT5, 它描述是不会继续更新这类稳定的仓库).

• 结合 altlinux 自家的 repocop, hasher 持续稳定地维护该活跃的滚动分支(主要还是依赖自家的QA和包构建系统).

最后了解一下 Sisyphus 的含义: 西西弗斯是希腊神话人物, 象征不断的劳动——这里寓意, 团队持续改进仓库.

Sisyphus … персонаж греческой мифологии … символизирует постоянный труд команды…

4 总结

确切地说, ALT Linux 并不是一个功能薄弱的桌面级发行版. 相反, 它在构建体系, 包管理以及质量控制等方面拥有较为完善的自研工具链. 然而, 它难以走向大众的根本原因在于社区生态相对封闭, 国际化程度不足, 导致外部开发者和普通用户的参与门槛较高.

5 References

1. 官方网站: https://www.altlinux.org; English: https://en.altlinux.org/Main_Page

2. 用户文档: https://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BD%D0%B8%D0%BA_%D1%81%D1%82%D0%B0%D1%82%D0%B5%D0%B9_%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D1%8E#%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_%D1%81%D0%B5%D1%82%D0%B5%D0%B2%D0%BE%D0%B3%D0%BE_%D0%BE%D0%B1%D0%BE%D1%80%D1%83%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F

3. 评测视频: https://www.youtube.com/watch?v=6Q3w6rQHTJk

4. ALT Linux 主项目 Sisyphus: https://www.altlinux.org/Sisyphus

5. altlinux github repo: https://github.com/altlinux

6. altlinux git repo: https://git.altlinux.org/

7. altlinux docs: https://docs.altlinux.org/ru-RU/index.html