聊聊RPM

最近没事找事打了个rpm包.

按理来说这种古老的东西自己这个年龄应该也早会的.

不过应该也就是应该而已.

接触之后发觉这个的思路还是挺有时代特征的.

原则上来说,它要解决的问题其实跟docker差不多.

甚至于抽象上来说其实是同一种方案.

dcoker无非是要求一个基础镜像给定一个基准的环境假设然后解决所谓的reproduce/标准化问题.

rpm技术上来说也可以说是同源的,基于rootfs的概念去populate成品layout.

不过有意思是一些设计上的约束.

比如概念上上需要制定一个source code的来源,以及整个rpm包的构建逻辑上就是一个source to binary的run.

所以你要会说他有一直用opensource的infection概念在也不是不行.

尤其考虑到年代上的各个发行版和license/gnu的关系.

当然,也不是说它是个强约束.

实际上你也可以只ship binary相关.

这个可能又涉及到一点也是具有年代性的设计.

用今天的话说,它的package spec也是一种DSL驱动的.

可能类似于nodejs生态.

但是它builtin的语义很少,更多的像是一种支持嵌入脚本的配置语言.

而各种复杂的routine是通过macro来扩展的.

所以如果你问chatgpt之类的一些解决方案,然后发现不能用可能并不是hallucinate,只是没有对应的plugin/macor而已.

当然,这里还涉及到另外一个问题就是每个发行版自带的macro可能不太一样.

甚至于并不代表有的macro就能使用.

因为本质上macro是一种prebuilt/predefine的scriptlet.

也就是它可能需要某些tools/command已经有了.

所以这里衍生的就是当时那个年代对于reproducible和standardize的困境.

不同的发行版对路径和默认配置约束不一.

有时候同一发行版对环境的默认ship的out of box的配置也存在出入.

于是,尽管rpm这种解决方案通过递归把依赖描述做到打包流程里了.

但是形式上来说,它还是不保证完全可重现的.

因为涉及到macro的支持完备程度.

也就是说,你不能保障某个macro在特定环境下的存在性和行为一致性.

这就导致了rpm对于基础系统的版本可能会有一个比较强的约束.

用今天的话说就是隐含锚定了某一个基础镜像.

而现在的docker/container方案本质上也逃不过这种约束.

只不过形式上被降低到了kernal版本上面.

以及像现在apple的m1/2/3出来之后,对于x86架构隐性约束的逐渐大众化.

所以有时候你就会发现,历史就是这么奇诡的往返盘旋.

你说现在的docker相较于rpm优异么?

可能也说不上.

毕竟本质上来说,大家同样是通过约束和expand约束来构筑一个相对reliable的运行时环境.

甚至于docker本身的问题在于它的daemon以及衍生的镜像开销问题.

毕竟虽然image看着解决的对于rootfs的近乎完美的约束表示.

但是随之而来的也是空间上的问题.

就像某个阶段大家可能都在想办法减少不同镜像支离破碎的rootfs空间占用问题.

毕竟理论上可能没有一层是reuse by other的.

然后为了解决这个问题一个路线是slim,/musl这些minimize base image的或者类似google jib这类尝试optimize need dependency的减少非必要依赖的方案.

另外一个路线自然就是提高layout到复用率了.

而相比较下,似乎rpm更可能原封不动的去达到类似的磁盘空间效果.

当然代价可能就是更复杂的隔离性技巧了.

如果是kvm的话,可能就是甚至解决了cpu架构的问题.

但代价可能是更底层的整体kernel IO/设备栈的重构/高度定制.

而如果只是为了解决reproducible的问题的话,可能非技术上的一些约束从成本上来说更有优势和见效.

于是这里就变成了,技术或者说解决方案本身是要解决什么问题的哲学命题了.

就像原教旨的马克思主义,生产力和生产关系的论述是要解决什么问题.

以及更重要的是能解决什么问题.

约束是什么.