Feature on SOW

Plain 平面仓库

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

sow create 接手一个已经放着 .rpm / .deb 的目录，在包旁边生成平面仓库索引。Plain 模式没有工作区、配置文件、数据库、期望状态，也没有操作 journal。包目录就是权威事实来源，所有索引都是当前目录内容的可丢弃投影。

Managed 工作区

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

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

功能

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

SOW 提供两条相互隔离的运行路径。Plain 模式无状态地重建一个目录；Managed 模式在工作区中持续记录软件包成员关系与不可变仓库 Generation。两者都不会暗中接管对方的状态。

包池与元数据视图

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

不变式

在一个 Repository 内，每个 live Package Object 在 pool/ 下只有一条正典 payload 路径。 Dist 与架构 view 拥有元数据，不拥有包体 alias：

<repo>/pool/...                              正典包体
<repo>/dists/<rpm-dist>/<arch>/repodata/... 纯 RPM 元数据
<repo>/dists/<deb-dist>/main/binary-*/...   纯 APT 元数据

相同 digest 出现在另一个 Repository 或发布 prefix 时，仍是另一个 owner 下的独立对象。 SOW 不会为了本地去重而制造共享的分布式所有权。

成员策略

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

本页说明 Managed 模式如何防止 live 指针指向缺失内容，以及如何协调 SQLite 状态与文件系统变更。

不变式

在受支持的本地 POSIX 文件系统上，沿 Managed 协议指针读取的客户端只会得到完整旧视图或完整新视图，包括进程中断之后。

可观测与审计

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

每个读取表面回答不同问题。

命令	问题	写入？
`status`	Repository 当前是什么状态？	否
`check`	所选 Repository 是否满足完整交付契约？	否
`changes`	两个 Built Generation 之间哪些物理文件不同？	否
`log`	记录了哪些操作与处置结果？	否
`retain ls`	哪些 Generation 是显式本地 GC root？	否

`status`：低成本状态

sow status -r local

它报告 Desired revision、Built Generation、dirty Dist、pending 包体计数、锁状态与 ready_to_copy。它不哈希公共树，不恢复操作，也不构建。

Feature on SOW

Plain 平面仓库

Managed 工作区

功能

包池与元数据视图

不变式

成员策略

签名模型

事务与恢复

不变式

可观测与审计

status：低成本状态

`status`：低成本状态