☰

在 CTAN 上发布包更新？

tag-icon • tag-icon packages ctan contribute
在 CTAN 上发布包更新？

这是我时常遇到的问题之一，所以我想发布一下它。

有几次，我遇到了需要修改 CTAN 包中的代码的情况 - 也就是说，我不能只使用如下重新定义模式来管理：

\let\old@COMMAND\current@COMMAND
\def\current@COMMAND{%
  % pre-hook commands ...
  \old@COMMAND
  % ... post-hook commands ...
}

... 在我的主代码中。更改可能只是几百行代码中的几行.sty，添加一个新命令 - 因此它属于“功能请求”类别，而不是“错误修复”；因此，在我看来，用“新”包名称来调用它并以此形式发布它是不合理的。

当然，我可以随时将此类“更新”发布到网络上的任何地方（从 pastebin 到这里）；但我感兴趣的是 - 如果我想将此更新发布在 CTAN 包上，并且作者/当前维护者目前无法联系到（比如，从初始查询开始最多一个月）来批准/不批准更新，那么正确的程序是什么？

一些相关信息：

  • 我如何为 CTAN 做出贡献？

    完成此操作后，将您的文件打包成 ZIP 或 TAR.BZ（或等）存档并上传。有两个 CTAN“镜像”可供您上传您的作品：...
    两者之间的唯一区别是不同的人（在不同的时区）将处理上传。

  • 软件包的历史稳定版本档案

    CTAN 保存每个软件包的当前版本：名称中的“存档”更多是因为它是“所有内容”的单一来源，而不是暗示记录。（请记住，在 CTAN 之前，收集 TeX 源意味着要搜索许多不同的作者维护的网站。）

    维护材料的“后备目录”取决于每个软件包的作者，因此许多软件包的公开源代码存储库有限或根本没有。您能找到的最接近的存储库可能是 TeX Live SVN，每次 TeX Live 中的软件包发生变化时它都会更新。...

    只有完整 TeXLive 版本的档案：ftp://tug.org/historic/systems/texlive/...

    实际上，过去两周我一直在使用自动化 Mercurial 存储库来处理 CTAN 的存档。CTAN 内容每天都会镜像，每个 CTAN 包（有例外）都会提交到自己的 Mercurial 存储库中。

    目前在线的是http://ctanhg.scharrer-online.de/，但尚未 100% 完成。此外，它可能无法很好地处理大量负载。您可以将每个存档版本作为 ZIP 或 Mercurial 克隆获取。

  • 是否有一个 Tex/LaTeX 包错误数据库可供报告或跟踪状态？：不，而且：

    您可能知道，您可以从 CTAN 的镜像中下载所有软件包。但 CTAN 本身由大约三个人运营，他们在那里服务了很多年。没有他们，就没有 CTAN。[1]

    因此，如果任何读者阅读这个问题并考虑要求提供比 CTAN 上的软件包更多的东西，即 bugzilla 或其他什么：我们依靠贡献自己工作的人来维护我们的基础设施，但即使在最核心的地方，也缺少人手。

  • 联系软件包作者的首选方式是什么？ - TeX - LaTeX Meta Stack Exchange

    您应该首先检查软件包手册及其 README 文件（通常位于http://www.ctan.org/pkg/）获取电子邮件地址

    请注意，几乎所有软件包作者都是在业余时间编写这些内容，并且可能忙于日常工作，因此您应该给他们 1-2 周的时间来回复，然后再给他们写第二封电子邮件。

    一些软件包作者也在阅读 comp.text.tex usenet 组，人们经常在那里发布与软件包相关的问题。但是，您仍然应该使用私人电子邮件抄送作者。否则，他/她可能会忽略该帖子。另外，公开发布但不直接联系作者也有点不礼貌。

    不同软件包作者对此有不同的看法。如果您能找到（有效的）电子邮件地址，那么这通常是最好的方法。

所以，换句话说：如果我天真地将我的更改打包在原件中someoneelsespackage.zip并将其上传到 CTAN，那么那些自愿维护 CTAN 的可怜人之一只会收到一条消息，希望它能自动识别出这样的包已经存在，但原始电子邮件不匹配，因此它将被直接拒绝 - 因此我成功地浪费了人们的时间，却一无所获。再说一次，我可以将其重命名为myversionofsomeoneelsespackage.zip- 这可能会通过自动检查，甚至维护人员的判断；但真的值得为本质上只有两行的补丁增加所有的噪音（使用相同的 pdf .docs 等）吗？这是我的主要困境，促使我提出这个问题......

答案1

是否允许进行此类更新完全取决于原始代码发布时的许可/版权条件。如果是 LPPL 版本 1.3，则有明确的条件规定可以接管维护。同样，如果是 GPL，则许可证不会阻止现场编辑。但一般来说，除非使用了此类许可证，否则版权归原作者所有，并且没有权利更改文件。

但即使允许编辑，“一个月”的时间太短了，不足以考虑更改其他人的软件包。如果有人仅仅因为我离开了几周或远离了 TeX 就编辑了我的某个文件，我肯定不会高兴。

这个网站（和类似的网站）有很多答案，它们本质上是对现有软件包的补丁或增强，这是完全合理的。用户可以找到它们，并且软件包维护者可以不时地对建议的更新进行扫描并将它们纳入新的更新中。我最近扫描了这个网站和 latex 错误数据库，寻找 longtable 增强功能，并收集了 20 年的代码建议。这可能是一个过度的稳定性水平，但您不应该期望软件包作者每次有人建议更新时都必须更新软件包。

new-foo.sty 如果您希望增强功能能够更快地应用于 ctan，只需分发与您的两行补丁一起进行的包即可 \RequirePackage{foo}。无需复制原始代码。

相关内容