将 CPAN 模块转换为 Debian 软件包的最佳方法是什么？答案

【问题标题】：What's the best way to turn CPAN modules into Debian packages?将 CPAN 模块转换为 Debian 软件包的最佳方法是什么？
【发布时间】：2010-11-23 03:17:51
【问题描述】：

每当我在具有特定处理包管理方式的任何风格的系统上工作时，我都会尝试坚持使用该标准来管理我的 Perl 模块。 “在罗马时，等等。”

例如，在使用 ActivePerl 的 Win32 系统上，我对所有内容都使用 PPM，并使用出色的 PPM::Make。在 RedHat 系统上，我更喜欢使用 RPM。

现在我正在开发一个 Debian 系统，并且发现自己需要一种将任意 CPAN 或 CPAN 风格的发行版转换为 deb 的方法。

Google 显示 dh-make-perl、CPANPLUS::Dist::Deb 和 CPAN::Packager::Builder::Deb 等选项。

有使用这些不同工具经验的人对使用或避免使用什么有任何建议吗？

从标准 CPAN 模块构建 deb 文件的最佳方法是什么？

更新：

我在这个主题上找到了an article by Hans Dieter Piercy - 他根据自己的需要建议使用 CPANPLUS 工具。在某些情况下，他推荐使用 dh-make-perl。 Jeremiah Foster（撰写了 brian d foy 所指的文章）响应 HDP 并为 dh-make-perl 提供了一个案例。

还有 a post on idimmu.net 描述了使用 dh-make-perl。

ATM，我倾向于 dh-make-perl，因为它已被推荐三次（brian d foy 作为 Jeremy Foster、idimmu.net 的作者和 hillu 的代理），而一次推荐给 CPANPLUS

【问题讨论】：

标签： perl debian

【解决方案1】：

dh-make-perl 在处理重复和繁重的工作以及从源头猜测信息方面做得很好。对于我打包为 Debian 软件包（官方或仅供内部使用）的几乎所有 CPAN 模块，它都可以正常工作。

也就是说，生成的软件包只应被视为正确 Debian 软件包的起点。 dh-make-perl 将警告注释放入自动生成的如debian/control（即包和依赖项的描述）和debian/copyright（许可信息）中。

作为对 Manni 的回应，我认为使用操作系统或发行版提供的用于包管理的工具是一个好的想法，而不是反对它们。对于 Debian，这意味着将东西放入 .deb 包并安装它们。 Perl 的构建工具和 CPAN 在提供跨平台构建环境和分发源代码方面做得很好，但与现代 Linux 发行版中的包管理工具相比，它们的性能并不理想，因为通常需要额外的手动干预，即跨多台机器的自动化不如卷起一个包那么容易。

（对于一次性和测试安装，安装到/usr/local/ 并使用stow(8) 作为穷人的包管理器可能没问题。）

即使您只是构建供自己使用的软件包，如果您认为有问题的模块对其他人有用，请考虑联系 Debian Perl 小组并让某人赞助上传到 Debian。

【讨论】：

【解决方案2】：

我建议你询问 Debian Perl 维护者小组，而不是这里的 SO。只需将显示为维护者的地址邮寄到任何奇怪的包裹上：
Debian Perl Group <pkg-perl-maintainers@lists.alioth.debian.org>

过去，我在 Debian 中添加了一些模块，并且只是“手工完成”。我还保持着一些。那也不难。但是该小组现在维护了更多的包，并且拥有了工具。

【讨论】：

【解决方案3】：

Jeremiah Foster 在The Perl Review 的 2009 年春季刊中发表了一篇关于将 Perl 发行版转换为 Debian 软件包的文章。

【讨论】：

【解决方案4】：

这里也有一个非常好的步骤。（还有其他优秀资源和一些不错的 cmets 的链接。[它的日期为 2005 年，但仍然主要是相关的，许多 cmets 更新得多]）

http://www.debian-administration.org/articles/78

这里是 debian perl 政策（也链接到文章中） http://www.debian.org/doc/packaging-manuals/perl-policy/

【讨论】：

【解决方案5】：

你不会喜欢这样，但我真的认为你根本不应该不这样做。各种 Perl Debian 软件包不适用于在其机器上需要某些 Perl 模块的开发人员。构建它们是因为其他应用程序需要它们并且用户想要或可能想要这些应用程序。

在做一些你可能不应该做的事情之前，请先看看this question 的答案。

【讨论】：

我不认为您的建议通常有用。选择任何一种方式都是有原因的。嘿，有些人坚持使用他们自己的 Perl 构建进行常规开发工作，这对于 98% 使用带有维护良好的 Perl 包的发行版的人来说可能没有意义。
虽然我同意应用程序应该对自己的依赖项负责，但这个问题并不是非法的，值得真正回答。