昨晚，我上传了Ogg :: Vorbis :: Header的新版本—一个CPAN模块，自2003年以来未进行更新，我强烈怀疑没有人再使用了。 您可能想听听我做了什么或为什么要做这件事。
大约一年前，我写了有关为CPAN模块编写的仪表板的信息。 这是一个简单的页面，将有关我所有模块的信息汇总在一起，除其他外，向我展示了它们在Travis CI和Coveralls上的工作方式。
- 使用Web Audio API的提示和技术
- Pro Tools在12.6更新中添加了许多功能强大的新工具和功能
- Zoom Platform —将基于标准的端点连接到实时会议
- Rejuveneciendo al abuelo
- 超级播客主机的5个秘密
仪表板的目的之一是鼓励我做更多的工作，以确保我的CPAN模块运行良好并具有良好的测试覆盖率。 这个想法是，如果我一直在查看一个页面，该页面显示了模块的测试覆盖范围如何，那么我将更有动力进行修复。 当然，只有当我不断查看仪表板时，这才有效。老实说，自从我构建仪表板以来的一年多，我确实并没有对其进行太多注意。
但是最近，当我对其进行更新时，使我想起了它的存在，以删除我移交给其他人的某些模块，并添加一些我已经发布的新模块。 而且，在此过程中，我仔细查看了一下，然后将注意力吸引到了AudioFile :: Info :: Ogg :: Vorbis :: Header。 这是我仅有的一个甚至都不基于Travis构建的模块。 显然，需要更多的调查。 但是，在我们进行讨论之前，可能有必要简要说明一下模块的功能。
你们中的某些人太年轻了，以至于不记得这一点，但是在互联网历史的早期中世纪（大概是15年前），并不是每个人都以MP3形式收听音乐的。 那时，对于许多人来说，最大的数字音乐来源之一是翻录他们现有的CD（问您的父母-他们可能仍然有一两张CD可以向您展示）。 从CD翻录音乐时，我们可以选择格式。 大多数人（甚至那时）都在使用MP3，但是我们当中有些人选择了意识形态上更强的Ogg Vorbis选项。 主要原因是MP3格式获得了专利，但是Ogg Vorbis是完全免费的。
所有这些都意味着在21世纪的头五年或六年中，我最终在硬盘上存储了数百（也许是数千）个Ogg Vorbis文件。 这立即给我带来了问题，因为它极大地限制了我可以播放音乐的设备。 例如，它可能解释了为什么我从未拥有过iPod。
但是我…嗯…同时购买了许多MP3。 而且，作为一个怪胎，有时我想编写一些程序，以收集有关我所有音乐的信息，无论它以什么格式存储。CPAN上都有用于处理MP3的模块，CPAN上有用于处理Ogg的模块。 Vorbis文件。 但是（所有这些模块通常都是这样）所有这些模块都以完全不同的方式工作。
那就是我编写的AudioFile :: Info模块集。 它们充当各种模块的包装，以处理不同的音频格式，并为它们提供相同的接口。 这意味着我可以编写从任何音频文件中获取信息的程序，而无需关心它们的格式。将它们有点像是用于音频文件格式的DBI。
当然，没有人对他们有任何用处。 不久之后，MP3成为了事实上的数字音频标准，Ogg Vorbis被降级为与Betamax相同的（虚拟）抽屉。 我想说没有人再使用它了，但是我怀疑实际上还剩下大约八位用户，他们都会写评论告诉我我错了。
没有一个AudioFile :: Info模块已经更新很长时间了，因为没有人再使用它们，也没有人关心它们。 我将从CPAN中删除它们，但这与我的“包鼠”性质背道而驰。
所有这些都让AudioFile :: Info :: Ogg :: Vorbis :: Header无法在Travis上构建失败而感到烦恼。 因此，几周前，我进行了进一步调查。 而且，令我高兴的是，我发现这不是我的错。 实际上，问题出在底层模块（Ogg :: Vorbis :: Header）。 该模块不再能够在现代Perls上成功构建。 那次失败使我的模块无法在其之上构建。
此票证中描述了该问题。 基本上，测试中有一些非常时髦的语法。 通过一些Perl 5.22中的解析器修复，语法变成了致命错误。 测试看起来像这样：
ok（@ {$ ogg-> comment（“ artist”）}-> [0] ==“ Dan”）;
当它应该看起来像这样时：
ok（（$ ogg-> comment（“ artist”））[0] eq“ Dan”）;
在RT票证中，H。Merijn Brand很好地解释了该测试是如何通过的-但请在尝试之前自己尝试一下。
因此，无论如何，我知道问题出在哪里，并且知道如何解决。 我的下一步是将这些信息传递给模块的作者。 几周前，我给他发了电子邮件，如果他太忙（或太无趣）自己不能解决，我愿意自己进行修复。 我没有得到任何回复，所以在上周末，我给CPAN Powers发了电子邮件，该邮件解释了这种情况并要求对模块进行共同维护，以解决此问题。 他们同意了我的要求，这就是昨天发布新版本的原因。 我已经看到该版本的测试看起来比以前的版本健康得多。
更健康，但仍不如我希望的那样健康。 在我发布CPAN版本的一个小时左右的时间里，就出现了这个问题。 Makefile.PL使用Inline :: MakeMaker，并且我想不出如何使之工作，因为“ use”语句在任何告诉构建工具所需的配置代码的配置代码之前执行了很久。 如果您有任何建议，请让我知道（或向我发送请求请求）。 当涉及到基于Inline的模块时，我有点不尽如人意。
我可能还要修复其他一些问题。 这是旧式发行版，其中没有/ lib或/ t目录。 全部都在顶层目录中。 我很想搬动所有这些东西。
但实际上，我应该回到确保我的模块现在成功构建的位置。
