最近没事找事打了个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的问题的话,可能非技术上的一些约束从成本上来说更有优势和见效.
于是这里就变成了,技术或者说解决方案本身是要解决什么问题的哲学命题了.
就像原教旨的马克思主义,生产力和生产关系的论述是要解决什么问题.
以及更重要的是能解决什么问题.
约束是什么.
