功能 on SOW

能力总览

Mon, 01 Jan 0001 00:00:00 +0000

SOW 是一个自包含的软件仓库管理器:一个纯静态 Go 二进制(CGO_ENABLED=0),在 Linux 与 macOS 上创建并维护 APT(DEB)与 YUM(RPM)软件仓库。它不调用 createrepo_c、dpkg-scanpackages、reprepro 或 modifyrepo_c,也不需要常驻进程。本页是覆盖面的地图,后续各页解释每一块是怎么实现的。

Plain 平面仓库

Mon, 01 Jan 0001 00:00:00 +0000

sow create 接手一个已经装着 .rpm 和 .deb 的目录,就地给它写一份索引。它的全部工作就是这个。本页讲清楚它读什么、写什么、承诺绝不碰什么,以及执行到一半被杀掉时怎么活下来。

Managed 工作区

Mon, 01 Jan 0001 00:00:00 +0000

当同一个仓库要维护好几个月 —— 包成批到达、由策略决定谁留下、事后还得说清楚什么时候变了什么 —— 你需要的是 Managed 模式。本页讲三层模型、它产出的布局,以及命令怎么判断你说的是哪个仓库、哪个 Dist。

包池与架构视图

Mon, 01 Jan 0001 00:00:00 +0000

列一遍 Managed 仓库,你会在三个不同路径上看到同一个包文件,而 du 坚称它只占一份空间。这不是错觉,也不是符号链接。本页讲清楚这套投影模型 —— 它为什么存在、保证了什么,以及它对你的文件系统提出的那一条约束。

成员策略

Mon, 01 Jan 0001 00:00:00 +0000

策略回答的是这个问题:“我把整个构建目录倒进了这个 Dist,但我不想要 debuginfo 包,而且每个包只留最新版本。“两条规则完成这件事,它们按固定顺序执行,并且作用于完整候选集,而不是你这次恰好 add 的那几个包。

签名模型

Mon, 01 Jan 0001 00:00:00 +0000

客户端会对一个仓库提两个不同的问题,SOW 用两套彼此独立的机制分别回答。把它们混为一谈,是"我明明签了名,dnf 还是报错"这类问题最常见的来源 —— 所以本页先把两者拆开。

事务与恢复

Mon, 01 Jan 0001 00:00:00 +0000

仓库工具翻车通常是两种难堪的姿势之一:留下一份指向已不存在的包的索引,或者把自己的数据库搞坏、只能从头重建。SOW 的设计目标是让这两件事都不可能发生,本页讲清楚支撑这一点的机制。

可观测与审计

Mon, 01 Jan 0001 00:00:00 +0000

四条只读命令回答四个不同的问题,而且每一条都拒绝替另外三条干活。这种分离是刻意的:一个偶尔会把整仓哈希一遍的"便宜状态检查"没法放进循环,一个会偷偷修东西的"完整校验"没法当证据用。