用RPM发布Perl应用

mofdan

　　如果你开发开源的Perl模块或应用可以用CPAN来进行发布。但是，如果你的应用不能开源，那么在RedHat系的发行版上用什么方法发布比较方便？有很多方案比如：

• 冷冻方案，把Perl的解释器和应用依赖的所有模块都打包在一起，具体的方案有， cava packager, ActiveState PDK，PAR等，该方案不利于复用，不适合于打包可复用的模块
  
• 用zip或tar打包，然后安装到单一根目录下，模块和入口程序按固定的相对路径组织，然后在入口程序中用FindBin模块和use lib把模块加入到@INC。此方法比较简洁，但是不利于不同应用之间的复用。
  
• 用RPM打包，把模块安装到vendor_perl的目录下，入口程序则安装到标准的/usr/bin目录。此方法遵循Linux程序部署的标准做法，减少因为使用非标准路径而需要的额外配置，比如PATH，@INC等。此外，它和可以利用RPM软件包依赖管理，安装好的文件的校验等功能
  

　　rpmbuild对制作Perl应用的RPM包有自动依赖扫描功能，比如该功能会对以下程序:

#!/usr/bin/env perl
use strict;
use DBI;
use DBD::SQLite 1.42;
　　识别出：perl(DBI)和perl(DBD::SQLite)的依赖，也就是说管理员需要安装 perl-DBI和perl-DBD-SQLite这两个RPM包。这个看上去不错，但是它有局限性，为了满足该依赖，响应的RPM必须被安装，但有时你需要最新版本的模块，该版本的模块的RPM包未必在相应发行版的软件仓库中可用。自己动手制作最新版的RPM往往不现实，因为复杂的Perl应用一般有很多依赖。而且，有时即使有最新版也未必能升级，因为，那些旧版本的模块很可能被系统中的其它应用所使用，升级到新版本可能会导致这些应用无法正常工作。这时，只能安装CPAN上对应的模块了。由于，用CPAN安装模块时，RPM的依赖管理数据库不会被更新，所以尽管事实上用CPAN也可以解决模块依赖，但是RPM却不知晓。仍旧以上述程序为例，由于Fedora 20的软件仓库中只有DBD::SQLite 1.40，要满足版本要求需要用CPAN来安装。但是，用CPAN安装完1.42后，试图安装上述程序的RPM包仍然会报DBD::SQLite没有找到的错误，如果忽略依赖，强制那么验证软件包的时候同样会报DBD::SQLite没找的错误。此时，显然RPM的依赖管理没有带来正真的价值。最好的办法时，不让RPM自动扫描依赖模块并加以管理。编写spec文件时可以将AutoReqProv设置成no来禁用自动依赖扫描，而让这些依赖在RPM之外管理，比如在该应用的安装文档中写明那些CPAN模块需要预先安装。或者提供一安装脚本把所需CPAN模块和RPM包一并安装。