SC Linux / ShenChen Linux × Sage

BUILD THE DISTRO. OWN THE STACK.

SC Linux 不从现成发行版改名,也不把包管理器当作外部黑箱。它从工具链和配方开始自举;C++23 编写的 Sage,则把每一份配方变成可构建、可索引、可求解、可安装的软件。一个定义系统,一个让系统真正运转。

DistributionSC Linux
Package engineSage
Sage coreModern C++23
Recipes286 validated
Release modelRolling
01Sage package engine
the state engine

Sage 管的不只是包,
而是系统如何改变

构建一个包并不难,持续维护一个系统才难。Sage 把来源校验、构建、能力依赖、仓库索引和安装事务连成同一条路径,让 SC Linux 能回答三个问题:装了什么、谁提供它、一次变更改动了哪里。它也是独立维护的通用 Linux 包管理器,不是只为发行版准备的附属脚本。

sage / package lifecycleC++23
$ sage build ./packages/shc
 recipe → package archive
  shc-1.0.0-1-any.pkg.tar.zst

$ sage repo index ./repo system
 archives → index.toml

$ sage --root /mnt install base
 resolve → transact → rebuild
PK / 01一份配方走完整条路

recipe.toml 同时描述输入与构建过程,最终产出带架构、依赖和元数据的包归档。

DB / 02每次安装都有账可查

包、文件归属、能力、Channel 与活动提供者进入同一份 LMDB 事务状态。

RP / 03一个目录也能成为仓库

从同一批包生成 index.toml;无需复杂服务,本地 file:// 就能开始分发。

CH / 04工具链不必污染系统层

system、runtime、toolchain 与 user 四层各守边界,又能被统一求解和使用。

SV / 05事务结束,系统才算完成

service.toml 描述服务,rebuild 钩子集中更新事务产生的系统派生状态。

PF / 06分层安装,一致使用

Profile 把多个 Channel 汇成稳定的 bin、lib 与 runtimes 视图,不让层次变成负担。

02Bootstrap path
from host to self

不是把软件装进目录,
而是让系统学会重建自己

SC Linux 从宿主能够提供的最小起点出发,一层层减少对宿主的依赖。Stage1 重建基础工具链与核心用户空间;Stage2 用更完整的工具链和更细的包边界进入原生自举。目标不只是编出一个根文件系统,而是让它能够构建自己的下一次更新。

Stage / 01Foundation
107

Stage1 配方

在 stage0 chroot 内重建基础工具链与核心用户空间,先建立可信的起点。

Stage / 02Native
178

Stage2 配方

把完整工具链、系统组件与功能拆分带进原生环境,继续向自举闭环推进。

Tree / allValidated
286

全树配方

递归校验覆盖 Stage1、Stage2 与发行版自有包;新增配方不会躲在检查之外。

03Package model
boundaries, not suffixes

分包不是剪文件,
而是在定义责任边界

一个好看的包名列表没有意义,能解释依赖关系才有意义。SC Linux 先判断上游交付的是纯运行库、独立命令行产品,还是一组可选系统能力,再决定怎样拆分。结果应该既足够小,也不把一个完整产品割得支离破碎。

纯库 / 两分

用户需要的运行库,不必被头文件和编译元数据拖着一起安装。

zlib + zlib-dev

库与 CLI / 三分

命令行产品、SONAME 运行库和开发接口各自有边界,也能独立成为依赖。

curl + curl-libs + curl-dev

大型组件 / 功能拆分

systemd 这样的系统工程按 udev、网络、解析、时间同步等真实能力拆分。

systemd-libs · systemd-udev · systemd · …

Meta 包 / 仅聚合

只负责把一套系统需要的包聚合起来,不用占位文件伪装成产品。

base → dependency graph
04System policy
choices with consequences

有些选择只改一行,
有些选择会让所有包重来

架构、ABI 和目录布局一旦改变,代价不是改配置,而是重编整个世界。SC Linux 先公开这些最昂贵的决定:当前专注 x86_64,以 glibc 与 systemd 为默认底座,采用 merged /usr 和滚动发布;其余部分尽量保留替换空间。

ARCH / 01x86_64
LIBC / 02glibc
INIT / 03systemd
LAYOUT / 04merged /usr
RELEASE / 05rolling
05Current status
what remains

现在最重要的,
不是宣布完成,而是打通最后一公里

配方树、校验器、Stage1 / Stage2 构建路径和发行版政策已经成形,真正困难的问题也已经暴露出来:能力声明、宿主依赖泄漏、目录落点和 UEFI 引导。这里展示的是一个可以阅读、审查和参与的工程现场,还不是拿来即装的成品镜像。

BOOTSTRAP IN PROGRESS

Stage2 的问题都能落到具体工程对象:补齐 ELF 能力声明,拦住宿主库误链,统一 merged /usr 路径,完成 UEFI 引导,并补上基础包缺口。把这些细节做对,系统才真正站得住。

ELF provides DT_NEEDED audit merged /usr UEFI boot base packages
进入仓库