我有一个Hackage包依赖于第三方包,它不是建立在较新版本的GHC(> = 7.2)上.只需一行补丁(LANGUAGEpragma)即可解决其他软件包的问题.我将补丁发送到上游两次,但没有收到任何反馈.问题是我的包不能安装,直到依赖项得到修复.
我本来可以上传固定版本的depenency软件包(带有一个小版本),但我想听听社区对这种非维护者上传的态度.同样,我不想更改库接口,我只添加一个新的编译标志,使其可以再次构建.
允许非维护者上传包裹(可能存在许可证问题,但是大多数包裹(如果不是全部包含在hackage上都有许可证允许这样做),但当然通常不会这样做.如果善意并采用合理的程序,他们是可以容忍的.如果你联系维护者并且在n周内没有得到任何回复(我不知道n的适当值是多少,不小于3,我会说),自己上传一个新版本就成了一个选择,然而,在邮件列表上讨论这一点似乎更为谨慎.如果包裹看起来像是被放弃了,甚至接管维护人员 - 当然在再次联系维护者之后,让她/他有时间做出回应 - 可能是适当的行动,但这绝对应该与社区讨论(haskell-cafe或邮件列表,例如).是否喜欢非维护者上传或分叉必须留给你的判断,我个人倾向于相信叉子踩到更少的人的脚趾.
但是,如果我们知道哪个方案涉及并且可以查看具体情况,那么可以做出更好的答复.
对于您怀疑仍然保留但作者暂时遗失的包裹而言,分叉是侵入性的.通过侵入性,我的意思是其他程序员可能会拿起你的分支,然后在原作者恢复主线上的工作后不再回到主线.
对于原作者离开Haskell社区的软件包,我的个人意见是,如果你要进一步开发它,最好分包.分叉可以防止继承问题,例如那些在Parsec中发生的问题,许多开发人员不希望更新这些问题,因为后续版本比原版更慢且记录更少.
在所有情况下,询问咖啡馆是最好的,无论人们是否选择不遵循它,它仍然是Haskell社区的中心.
对于问题中的特定情况,虽然Hackage编译的内容很好,但没有规则说他们必须这样做.依赖于破坏的软件包的软件包可以简单地将破坏的依赖项的更改指令放在其首页上,即"此软件包依赖于已损坏的LambdaThing-0.2.0,以修复LambdaThing添加...到文件Lambda.hs "
| 归档时间： |
|
| 查看次数： |
348 次 |
| 最近记录： |