开源开发者吵架 -> Python Cryptography vs Gentoo

前段时间,有个帖子 为什么发行版不提供新版

其中一个原因是开源软件是由散布在世界各地的各种各样的组织和个人开发的,是一个混乱且需要相互合作的系统。因此需要周期性地稳定一下,来确保各个组件能在一起工作。发行版的维护者们潜在地拥有协调不同开源项目之间协作的职能。

今天看到一个超典型的例子。就是 Python 的加密库 pyca 突然在一个小版本添加了对 Rust 的依赖。

Gentoo 的包管理器由于也依赖 pyca,于是就突然需要配合 Rust 才能编译。添加一个 Rust 的支持,对大部分人来说并不是难事。然而,Gentoo 项目支持一大堆 CPU 架构,而其中有一些没有对应的 Rust 编译期。于是乎 Gentoo 项目就突然人在家中坐,锅从天上来,一夜之间一些 CPU 的架构不能编译新版本的包管理器了。

除此了一些稀有的 CPU 架构的用户之外, Alpine Linux(和其他基于 musl 的发行版),BSD 之类的也都被狠狠地背刺了一波。

Pyca 的一部分用户现在就突然开始很痛苦,而且痛苦地毫无意义,要不抛弃掉自己一直用软件,要不 fork 一个 pyca, 或者永远使用纯 C 的旧版,或者迁移到 pyca 的替代品上,或者研究一波 rust,无论哪一个都要浪费大量的人力和时间。

于是乎一场火药味很浓的舌战就开始了,


1赞

也可以去解决现有的问题,把 rust port 到自己所使用的平台上。Alpine Linux 和 BSD 应该都有支持的呀?

以我看来,pyca 这个新的编译期依赖确实来得太过突然了。不过随着越来越多的项目开始采用 rust,迁移的痛苦总是会来的。

CherryTree 就是因为 pygtk2 的 gtksourceview2 组件没人再维护,gtksourceview3 组件也没有人开发,所以几个项目维护者只好又花几个月时间用原生 gtkmm/C++ 重写了 GUI。

1赞

@lilydjwg 但是维护 pyca 的人的技能树不一定点在了 platform port 上面啊?也不一定有硬件测试啊?比如以前我维护 dnsproxy 的时候很好维护,后来它用 golang 重写了,我当时就维护不了了。再比如 microcai 写软件看起来很高端,却总是要最高版本的 cpp,我直接就弃坑了,对于没有 backward compatibility in mind 的开发者来说,咱们 downstream 确实 backport 不起,能做的要么迁走要么 fork。

这段空档期由于版本过旧带来的安全问题其实更大。甚至 downstream 维护者直接就像我一样弃坑了。再找一个维护者,开源社区找一个上来就要干那么大活的维护者几乎是找不到的,现在老 K 弃坑 fcitx5 你说谁能捡起来?scim 的前例不就放在那儿。那几个架构都是生产环境,没人搞 s390x 的桌面的。所以这个问题我看错就错在上游开发者嘴里喊着长期长期,却直接让你死在了今天。地球几千年每一天的秒数据都是有细微差别的,但是让它停转试试,巨浪直接能拍到乌鲁木齐…

1赞

我是指受影响的用户,他们有硬件。如果 llvm 有支持的话,可能跑起来并不会很难。(当然如果 llvm 不支持,那就惨了。)

cryptography 这事其实更好的做法是同时维护两个分支版本,这样就不会有空档了。就像 Python 2->3 那样。不过确实迁移不容易。这种迁移,总是会有用户被落在后边,唉。

开源的世界好乱

毕竟林子大了,又没有林长管着。