非维护者上传到Hackage

Question

我有一个关于Hackage的软件包，它取决于第三方软件包，它不构建在较新版本的GHC（＆gt; = 7.2）上。只使用一行补丁（LANGUAGE编译指示）就可以解决其他包的问题。我将补丁发送到上游两次，但没有收到任何反馈。问题是我的包在安装依赖项之前都不可安装。

我本可以上传固定版本的depenency软件包（带有次要版本），但我想听听社区对这种非维护者上传的态度。同样，我不想更改库接口，我只添加一个新的编译标志，使其可以再次构建。

• 是否允许和容忍非维护者上传到Hackage？
• 当Hackage上的软件包是一个更好的方法吗？

Answer 1

允许非维护者上传包裹（可能存在许可证问题，但是大多数包裹（如果不是全部都在hackage上都有许可证允许这样做），但当然通常不会这样做。如果善意并采用合理的程序，他们是可以容忍的。如果你联系维护者并且在n周内没有得到任何回复（我不知道n的适当值是什么，不小于3，我会说），自己上传新版本就成了一个选择，然而，在邮件列表上讨论这一点似乎更为谨慎。如果包裹看起来像是被放弃了，甚至接管维护人员 - 当然在再次联系维护者之后，让她/他有时间做出回应 - 可能是适当的行动，但这绝对应该与社区讨论（haskell-cafe或邮件列表，例如）。是否更喜欢非维护者上传或分叉必须留待您的判断，我个人倾向于相信叉子会减少人们的脚趾。

但如果我们知道涉及哪个方案并且可以看看具体情况，那么可以做出更好的答复。

Answer 2

对于您怀疑仍然保留但作者暂时缺失的程序包，分叉是侵入式。通过侵入性，我的意思是其他程序员可能会拿起你的分支，然后在原作者恢复主线上的工作后不再回到主线。

对于原作者离开Haskell社区的软件包，我的个人意见是，如果你要进一步开发它，最好分包。分叉可以防止继承问题，例如那些在Parsec中发生的问题，许多开发人员都不想更新，因为后续版本比原版更慢且文档记录更少。

在所有情况下，询问咖啡馆是最好的，无论人们是否选择不遵循它，它仍然是Haskell社区的中心。

对于问题中的特定情况，虽然Hackage编译的内容很好，但没有规则说他们必须这样做。依赖于破坏的软件包的软件包可以简单地将破坏的依赖项的更改指令放在其首页上，即＆＃34;此软件包依赖于LambdaThing-0.2.0，它已损坏，以修复LambdaThing添加...到Lambda.hs＆＃34;

文件

Answer 3

我想说，咨询有关特定包裹和失踪的特定人员的邮件列表是一个非常好的主意。我从其原始所有者那里获得了对haskell-src-meta软件包的控制权，但只是在咨询了列表和IRC之后，他们向我保证Matt Morrow已经失踪了好几个月并且没有人知道为什么。

在我看来，包装所有权可能只有在达成共识的情况下才会改变，或者至少应该努力找到包装所有权。在Hackage软件的开发版本中，我理解有访问控制，只有管理员才能进行这种干预。