![我如何评估 Ubuntu 软件包背后的社区?](https://linux22.com/image/1093342/%E6%88%91%E5%A6%82%E4%BD%95%E8%AF%84%E4%BC%B0%20Ubuntu%20%E8%BD%AF%E4%BB%B6%E5%8C%85%E8%83%8C%E5%90%8E%E7%9A%84%E7%A4%BE%E5%8C%BA%EF%BC%9F.png)
在投入精力配置和尝试使用复杂的开源组件之前,了解错误报告或支持请求是否可能得到回复是很有用的。我对如何对 ubuntu 中某些东西的原始上游源代码进行此操作有一个合理的线索。
但是,当我看到像 6.2u5-1ubuntu1 这样的版本时,我知道 Ubuntu 开发社区特别负责这个软件包。如果上游源包难以构建,那么尤其如此,因此很明显,为 Ubuntu 制作 .deb 的人做了很多工作。
我如何追踪 Ubuntu Debian 的出处并了解制作它的人是否仍在维护它?是否有一些 Ubuntu 索引可以将软件包映射到其打包者?
我目前的例子是 gridengine-qmon 和朋友。
答案1
您可以从变更日志中推断出一些内容。首先,让我们看一下 Ubuntu 中的变更日志:
如果你点击小扩展器,你会看到 Ubuntu 更新日志。对于 oneiric,你会看到:
gridengine (6.2u5-3ubuntu1) oneiric;紧急程度=低
- 与 Debian 重新同步:
- 删除设置 -Wno-error,它已经在 Debian 包中完成
- 100-as-needed.diff:新补丁,修复 FTBFS(LP:#770777)。
- 重建摆脱了对 openssl0.9.8 的二进制依赖。
好的,看起来最后一个接触过这个软件包的人已经与 Debian 同步了,这很好。现在让我们看看 Debian 更新日志:
看起来这个软件包在 Debian 中也得到了积极维护,到目前为止一切顺利。
由于有人积极地让软件包与 Debian 保持同步,这可能表明维护者反应灵敏。我在这里建议的是针对 ubuntu 软件包提交错误报告,然后概述问题的步骤,然后从那里开始。
您还可以通过其他方式了解该软件包的社区活跃程度。例如,您可以查看接触该软件包的人是否定期在上游邮件列表上发帖,他们是否定期向上游发送补丁等。不过,对我个人而言,更新日志通常是一个足够好的指标。
答案2
与 Debian 不同,ubuntu 软件包通常没有自己的维护者。实际上,这意味着它们非常接近原始的 Debian 软件包。这个特定的软件包也是如此。
尽管如此:您可以在启动板上看到具体是谁上传了最新版本。 https://launchpad.net/ubuntu/+source/gridengine/6.2u5-3ubuntu1
您还可以联系 Debian 维护人员,看看他们是否愿意解答 ubuntu 问题。他们中的许多人都会这么做。
答案3
首先,这是一个非常困难且可能引起争论且主观的问题。
话虽如此,我的建议是这样的:
看看上游项目。我见过的许多 Ubuntu 打包程序都只关心打包,而不是错误等。
但是,您必须自己做出决定——需要查看的一个地方包括该软件的启动板项目。