分类: Feature

每个读取表面回答不同问题。 命令 问题 写入？ status Repository 当前是什么状态？ 否 check 所选 Repository 是否满足完整交付契约？ 否 changes 两个 Built Generation 之间哪些物理文件不同？ 否 log 记录了哪些操作与处置结果？ 否 retain ls 哪些 Generation 是显式本地 GC root？ 否 status：低成本状态 sow status -r local 它报告 Desired revision、Built …

本页说明 Managed 模式如何防止 live 指针指向缺失内容，以及如何协调 SQLite 状态与文件系统变更。 不变式 在受支持的本地 POSIX 文件系统上，沿 Managed 协议指针读取的客户端只会得到完整旧视图或 完整新视图，包括进程中断之后。 下面所有内容都是为了守住这条线:元数据在任何公开变更之前完整 stage 并校验,指针切换就是提交决策,每个操作都留下足够的持久证据,让下一条命令能把它做完或撤销,而不需要猜。 Plain sow create 刻意不属于这套事务模型。它以 …

客户端会对一个仓库提两个不同的问题,SOW 用两套彼此独立的机制分别回答。把它们混为一谈,是"我明明签了名,dnf 还是报错"这类问题最常见的来源 —— 所以本页先把两者拆开。 两条独立的信任链 元数据签名 RPM 包体签名 回答的问题 “这份索引真是你出的、没被改过吗?” “这个 .rpm 文件真是你出的吗?” 配置项 signing.rpm.metadata、signing.deb.metadata signing.rpm.packages 产出 …

策略回答的是这个问题:“我把整个构建目录倒进了这个 Dist,但我不想要 debuginfo 包,而且每个包只留最新版本。“两条规则完成这件事,它们按固定顺序执行,并且作用于 完整候选集,而不是你这次恰好 add 的那几个包。 两条规则与它们的顺序 候选集 → exclude → limit → 期望成员集(Desired Membership) exclude 丢掉命中规则的包,limit 再按包名与架构限制存活的版本数。顺序固定且不可配置 —— 反过来的话,一个即将被排除的包会在离场路上白白 …

不变式 在一个 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 出现在另一个 …

SOW 提供两条相互隔离的运行路径。Plain 模式无状态地重建一个目录；Managed 模式在工作区中 持续记录软件包成员关系与不可变仓库 Generation。两者都不会暗中接管对方的状态。 能力矩阵 能力 Plain Managed RPM 与 DEB 元数据 是 是 RPM + DEB 混合操作 同一目录 同一 Repository、不同 Dist 持久成员关系与 Generation 否 是 分架构视图与中性包投影 否 是 exclude 与版本 limit 策略 否 是 元数据签名 …

当同一个仓库要维护好几个月 —— 包成批到达、由策略决定谁留下、事后还得说清楚什么时候变了什么 —— 你需要的是 Managed 模式。本页讲三层模型、它产出的布局,以及命令怎么判断你说的是哪个仓库、哪个 Dist。 三个层级 Workspace 工作区 发现与配置边界 └── Repository 仓库 所有权边界:pool、dists、SQLite、锁、Generation └── Dist 发行版 单一格式的具名成员集合 └── Architecture View 架构视图 渲染投影 —— …

sow create 接手一个已经放着 .rpm / .deb 的目录，在包旁边生成平面仓库索引。Plain 模式没有工作区、配置文件、数据库、期望状态，也没有操作 journal。包目录就是权威事实来源，所有索引都是当前目录内容的可丢弃投影。 这个边界是刻意的：Managed 仓库保存状态并恢复事务；Plain 仓库失败了就便宜地重建。一次运行失败或被中断后，重新执行同一条命令，覆盖派生元数据即可。 契约 Plain 模式由四条规则定义： 包是权威事实。 默认 create 不修改包字节，只替 …