Perl 策略
本页面涵盖了 Perl 本身如何配置和打包的策略。有关 Perl 模块打包指南,请参阅 Perl 包裹指南。
简介
此策略文档已在 perl 包的版本 5.10.0 中被提议、接受和实施。它是关于 perl 包、相关的 Perl 包以及创建 Perl 模块包(包括二进制形式和 PKGBUILD 形式)的标准。部分内容源自 Debian Perl Policy 文档以及 Perl man 页面的各个部分。
原因
5.10.0 版本之前的 Perl 打包约定的明显问题包括:
- 当前的 Arch Linux 默认 Perl 安装将 site 和 vendor 包安装到同一个目录树中,这常常会导致冲突,如果最终用户在 site 包之上安装和升级 Arch Linux Perl(vendor)包的话。
- 当前的 Arch Linux 默认 Perl 安装将 core 模块的更新安装到 Perl 的 core 目录中,造成文件冲突。例如
Data::Dumper和version等模块。 - 在
/usr/lib/perl5/和/usr/lib/perl5/site_perl中创建了一个符号链接农场,这是不必要的且令人困惑的。 - 一些标准模块似乎缺失,或者在 perl 包本身中被忽略添加为 provides,这导致了 AUR 和仓库中的混淆和冗余条目,因为用户试图“修复”似乎缺失的模块的问题,而这些模块是由 perl 提供的。这可能是一个教育问题。
- 当前的 perl-module PKGBUILD 可以被大大简化和标准化。
此策略将消除所有这些问题。
陷阱
采纳此策略的当前(明显的)缺点
- 更新每个 Perl 模块 PKGBUILD,使其安装到正确的(vendor)目录树中。它在一定程度上与旧结构兼容,因为旧的 PKGBUILD 在技术上是**有效**的。
- 对 core 仓库中的 perl 包进行更改,并提议一个名为 perl-modules 的新包,该包将位于 extra 仓库中。
- 编译 Perl 解释器静态副本的非 Perl 包将无法正常运行,直到在遵守本文档的 Arch Linux PC 上重新编译。此类包的示例包括 vim、subversion 和 irssi。还有许多此类示例。
Perl 版本
在任何给定时间,perl 包都应代表 Perl 5 版本当前的稳定上游版本。(参见 Perl_Policy#Perl_7)。
只有一个包可以包含 /usr/bin/perl 二进制文件,并且该包必须是 perl 或其依赖项。为了提供 Perl 的最小安装供应用程序使用,而无需安装整个 Perl,perl 包包含二进制文件和一组基本模块。perl 包应为基础 perl 包提供的每个模块声明 provide 语句。
模块路径
Perl 在三个不同的位置搜索模块,在本文档中称为 core(安装了 Perl 自带的模块)、vendor(用于打包的模块)和 site(用于本地管理员安装的模块)。
Arch Linux 包中的模块搜索路径 (@INC) 已按以下顺序排序:
- site
由本地管理员为当前 Perl 版本安装的模块。通常,这些模块是使用 cpan 或 cpanp 工具安装的,或者以源代码形式下载并通过 make 安装。
/usr/lib/perl5/site_perl/version/usr/share/perl5/site_perl/version
- vendor
通过 pacman 工具从 core 或 extra 仓库安装的打包模块,或者从 ABS/AUR PKGBUILDs 构建的 proper Arch Linux 包。
/usr/lib/perl5/vendor_perl/usr/share/perl5/vendor_perl
- core
包含在核心 Perl 发行版中的模块。
/usr/lib/perl5/core_perl/usr/share/perl5/core_perl
- obsolete
obsolete 是此文档建立之前安装的模块的路径名。这些路径已从 5.12.2 版本的 perl 的 @INC 中删除。
/usr/lib/perl5/site_perl/current/arch/usr/lib/perl5/site_perl/current/usr/lib/perl5/current
在上面的每对目录中,lib 部分用于二进制、与架构相关的 (XS) 模块,而 share 用于与架构无关的 (pure-perl) 模块。在任何情况下,都不应使用 current 来替换 version。核心和供应商模块**应该**与当前的 perl 安装匹配。
文档
POD 文件、手册页和 HTML 文档(不涉及程序的)可以从包中剥离,这对于大多数 Arch Linux 包来说是正常的。这是可选的。
Perl 包随附的手册页必须安装到标准目录中:
- Programs
- 程序和脚本的手册页安装到
/usr/share/man/man1,扩展名为.1perl。 - 模块
- 模块的手册页安装到
/usr/share/man/man3,扩展名为.3perl。
二进制文件和脚本
为防止文件冲突,将 core、vendor 和 site 安装生成的二进制文件分开至关重要。同样重要的是,每个用户配置文件中设置的默认 PATH 环境变量应按与 Perl 的 @INC 路径相同的顺序搜索二进制文件。为实现这一点,二进制文件应安装到以下目录:
- Core
- 所有 core 包的二进制文件和脚本应安装到
/usr/bin/core_perl。 - Vendor
- 所有 vendor 包的二进制文件和脚本应安装到
/usr/bin/vendor_perl。 - Site
- 所有 site 的二进制文件和脚本应默认安装到
/usr/bin/site_perl。
perl 包应包含一种机制来相应地调整最终用户的 PATH 条目,以便按以下顺序搜索 Perl 二进制文件:site、vendor、core。
Core
核心模块是“通常”包含在核心 Perl 发行版中的 Perl 模块。
核心目录
- 包含在核心 Perl 发行版中的模块应安装到
/usr/lib/perl5和/usr/share/perl5。 - 只有 perl 包中包含的模块才应安装到此目录树中。
- 这些路径中不存在版本子目录,因为打包模块的依赖关系应确保所有模块都与当前的 perl 包协同工作。
核心 Perl 包
perl 包应包含 /usr/bin/perl 二进制文件,以及运行简单 Perl 脚本和操作基本系统所需的一组最小模块。它应在 core 仓库中维护。
以下是一些示例模块列表,它们包含在 perl 包中。(官方列表请参见 PKGBUILD)。
'perl-checktree' 'perl-collate' 'perl-config' 'perl-cwd' 'perl-dynaloader' 'perl-english' 'perl-env' 'perl-exporter' 'perl-fnctl' 'perl-filehandle' 'perl-find' 'perl-finddepth' 'perl-getopt' 'perl-makemaker' 'perl-socket' 'perl-sys-syslog' 'perl-db-file' 'perl-storable' 'perl-data-dumper' 'perl-digest-md5'
perl 包中提供的所有模块都必须添加到 PKGBUILD 的 provides 数组中。此数组中的模块**不**应出现在 Perl 包的 conflicts 或 replaces 数组中。最终用户应能够安装核心模块的新版本(在 vendor 或 site 目录中),而不会发生文件冲突。
Site
站点模块是本地管理员为当前 Perl 版本安装的 Perl 模块。通常,这些模块是使用 cpan 工具安装的,或者以源代码形式下载并通过 make(或 MakeMaker)安装。
站点目录
Perl 包必须提供一种机制,允许本地管理员在 /usr/lib/perl5/site_perl 下安装模块,但不得创建或删除这些目录。
模块应安装到 Perl_Policy#Module_paths 中描述的“site”目录,程序安装到 /usr/bin/site_perl,手册页安装到 /usr/share/man。
站点安装
在大多数情况下,以下命令应足以让本地管理员安装模块,并必须按需创建目录。
# perl Makefile.PL # make install
或者
# cpan Foo::Bar
Vendor
供应商模块是打包模块,通过 pacman 工具安装,或者是通过 PKGBUILD 和 makepkg 构建成 proper Arch Linux 包的模块。
包命名
Perl 模块包应以提供的首要模块命名。模块 Foo::Bar 的命名约定是 perl-foo-bar。包含多个模块的包还可以使用相同的约定为这些模块另外提供 provides。
供应商目录
Arch Linux 模块的安装目录必须与 site 模块的安装目录不同。一些指南包括:
- 当前的 Perl 打包使用 vendor 目录来实现此目的,目前正如上面所描述的,为
vendor。 - 这些目录中没有版本子目录,因为打包模块的依赖关系应确保所有模块都与当前的 perl 包协同工作。
- Perl 发行版包含许多可从 CPAN 单独获取的模块,这些模块可能拥有更新的版本。
@INC顺序(如上所述)的目的是允许此类模块打包到 vendor,它们优先于 core 中的版本。以这种方式覆盖 core 模块的打包模块必须是新版本。 - 模块包必须使用扩展名
.1p和.3pm将手册页安装到标准目录中,以确保不会出现打包模块重复 core 模块的冲突。 - 不应安装
.packlist(用于模块卸载)和perllocal.pod(用于记录本地/站点安装)文件,如果发现它们,则应从包中删除。 - 应修剪空目录。
供应商安装
模块应在 PKGBUILD 构建目标中使用以下行:
perl Makefile.PL INSTALLDIRS=vendor
以及此行将结果安装到临时树中:
make DESTDIR="${pkgdir}" install
示例供应商 PKGBUILD
依赖
二进制模块
二进制模块必须指定对 perl 的依赖,且最低版本为构建模块时使用的 perl 包的版本,并且必须另外依赖于使用 Config 模块展开的 perlapi-$Config{version}。
与架构无关的模块
需要 perl 包中的 core 模块的与架构无关的模块必须指定对该包的依赖。
包含显式 require version 或 use version 语句的模块必须指定对 perl 的依赖,且最低版本为所需版本,或者更简单地说,为当前版本。
Perl 7
下一个主要版本的开发目前正在进行中,但规范尚未最终确定。
预计 Perl 7 发布时,它将被打包为 perl7,二进制文件安装为 /usr/bin/perl7,并使用与 Perl 不同的目录来存放打包的模块:
/usr/lib/perl7/usr/share/perl7
这将允许 Perl 5 和 7 的包和模块(应打包为 perl7-foo-bar)在需要时共存。
未来 Perl 7 足够成熟时,包命名可能会颠倒,即 perl 包将包含 Perl 7,而当前包将变为 perl5。