为Debian打包Kubernetes

LWN订户已向您提供以下仅限订阅的内容。数以千计的用户依赖LWN获取来自Linux和自由软件社区的最好消息。如果您喜欢这篇文章，请考虑接受右边的试用报价。感谢您访问LWN.net！

免费试用LWN 1个月：无需付款或信用卡。现在激活您的试用订阅，看看为什么成千上万的读者订阅LWN.net。

Linux发行商从事的业务是集成来自多个来源的软件，将结果打包并提供给他们的用户。长期以来，有些项目比其他项目更容易打包，这一点一直是正确的。Debian技术委员会(TC)目前正被要求就如何处理一个特别难以打包的项目-Kubernetes-的争议做出决定。无论最终结果如何，这种分歧清楚地表明，Linux发行商使用的打包模型与本世纪20年代软件开发的方式越来越不匹配；不过，应该用什么来取代这种模型还不太清楚。大多数发行商遵循的一个长期规则是，系统中任何给定库(或其他依赖项)应该只有一个副本，并且该副本通常应该在它自己的包中。否则，将会使系统膨胀，并使确保安全的任务复杂化。作为一个极端的例子，考虑一下如果每个程序在其软件包中都带有自己的C库副本，会发生什么情况。这数千份拷贝将消耗大量的存储空间和内存。如果在该库中发现安全漏洞，则需要更新数千个软件包才能在任何地方修复该漏洞。相反，由所有用户共享的单个库包更高效且更易于维护。因此，这一规则与将依赖库放入需要它们的程序包中的做法相反-这种做法通常被称为供应商提供服务。然而，对于许多现代项目来说，遵守这一规则可能是具有挑战性的，这些项目通常也会涉及到相当多的卖家。用某些语言编写的项目似乎特别容易出现这种行为；例如，围棋语言似乎鼓励了这种行为。Kubernetes是用围棋编写的，它附带了一长串依赖项。它由Dmitry Smirnov在Debian中维护了一段时间，但孤儿Kubernetes在2018年