「Perl パッケージガイドライン」の版間の差分

2023年6月29日 (木) 21:40時点における最新版

パッケージ作成ガイドライン

32ビット – CLR – クロス – Eclipse – Electron – Free Pascal – GNOME – Go – Haskell – Java – KDE – カーネル – Lisp – MinGW – Node.js – ノンフリー – OCaml – Perl – PHP – Python – R – Ruby – Rust – VCS – ウェブ – Wine

このドキュメントでは CPAN (Comprehensive Perl Authors Network) で配布されている perl モジュールの PKGBUILD の作成を扱っています。このドキュメントの対象読者は perl モジュールのパッケージ作成者です。

Arch Linux のパッケージの慣習

以下の決まり事は perl のモジュールパッケージを一貫性のあるものにするためのものです。このセクションは perl のパッケージングのイントロダクションです。Arch Linux のパッケージ管理・システム管理の観点から記述しています。TL;DR な人のために、一番簡単かつ重要な文章を上に配置しています。

パッケージの名前

モジュールの場合、パッケージの名前は perl- から始まるようにして、後はモジュールの名前を小文字に変換してコロンをハイフンに置き換えたものを付けてください。例えば HTML::Parser のパッケージ名は perl-html-parser となります。Perl アプリケーションの名前はアプリケーション自体の名前と同じにしてください (同じく小文字で)。

パッケージのファイルの置き場所

Perl パッケージはモジュールファイルを /usr/lib/perl5/$version/vendor_perl/ (スクリプトの中では perl -V:vendorarch) または /usr/share/perl5/vendor_perl/ にインストールしてください。下の例にあるように INSTALLDIRS コマンドラインパラメータを vendor に設定することでインストールできます。/usr/lib/perl5/$version/site_perl/ にファイルを保存してはいけません。システム管理者がパッケージ管理システムの管理外となる Perl パッケージをインストールするため用に予約されたディレクトリです。ユーザーが cpan シェルを使ってシステム全体にモジュールをインストールすると、モジュールは site-perl サブディレクトリに保存されます。

perllocal.pod と .packlist ファイルも存在するべきではありません。

アーキテクチャ

ほとんどの Perl パッケージはアーキテクチャに依存しないため arch 配列には 'any' を指定する場合がほとんどです。XS モジュールは動的にロードされるライブラリとしてコンパイルされるため (.so ファイル)、アーキテクチャを ('x86_64') と明示的に設定する必要があります。XS モジュールには大抵 .c ファイルを動的に生成する .xs ファイルが含まれています。

自動化

第2世代の CPAN シェルである CPANPLUS のプラグインが perl-cpanplus-dist-arch パッケージでインストールできます。CPANPLUS によってインストールされたファイルを即座にパッケージ化します。オンラインドキュメントが https://metacpan.org/release/CPANPLUS-Dist-Arch から確認できます。

PKGBUILD サンプル

サンプル PKGBUILD は [1] で確認できます。

次の 2 つの PKGBUILD の例では、PKGBUILD のより高度な問題に対する回復力を高めることを目的とした、このページで紹介した手法を使用しています。ビルドスクリプトには 2 つのスタイルがあるため、PKGBUILDS の例が 2 つあります。最初の PKGBUILD は、Makefile.PL を使用するディストリビューションをパッケージ化する方法の例です。2 番目の PKGBUILD は、Build.PL を使用するディストリビューションの開始点として使用できます。

PKGBUILD

# Contributor: Your Name <youremail@domain.com>
pkgname=perl-foo-bar
pkgver=1.0
pkgrel=1
pkgdesc='This packages the Foo-Bar distribution, containing the Foo::Bar module!'
_dist=Foo-Bar
arch=('any')
url="https://metacpan.org/release/$_dist"
license=('GPL' 'PerlArtistic')
depends=(perl)
options=('!emptydirs' purge)
source=("http://search.cpan.org/CPAN/authors/id/BAZ/$_dist-$pkgver.tar.gz")
md5sums=(...)

build() {
  cd "$srcdir/$_dist-$pkgver"
  unset PERL5LIB PERL_MM_OPT PERL_LOCAL_LIB_ROOT
  export PERL_MM_USE_DEFAULT=1 PERL_AUTOINSTALL=--skipdeps
  /usr/bin/perl Makefile.PL
  make
}

check() {
  cd "$srcdir/$_dist-$pkgver"
  unset PERL5LIB PERL_MM_OPT PERL_LOCAL_LIB_ROOT
  export PERL_MM_USE_DEFAULT=1
  make test
}

package() {
  cd "$srcdir/$_dist-$pkgver"
  unset PERL5LIB PERL_MM_OPT PERL_LOCAL_LIB_ROOT
  make install INSTALLDIRS=vendor DESTDIR="$pkgdir"
}

PKGBUILD

# Contributor: Your Name <youremail@domain.com>
pkgname=perl-foo-bar
pkgver=1.0
pkgrel=1
pkgdesc='This packages the Foo-Bar distribution, containing the Foo::Bar module!'
_dist=Foo-Bar
arch=('any')
url="https://metacpan.org/release/$_dist"
license=('GPL' 'PerlArtistic')
depends=(perl)
options=('!emptydirs' purge)
source=("http://search.cpan.org/CPAN/authors/id/BAZ/$_dist-$pkgver.tar.gz")
md5sums=(...)

build() {
  cd "$srcdir/$_dist-$pkgver"
  unset PERL5LIB PERL_MM_OPT PERL_MB_OPT PERL_LOCAL_LIB_ROOT
  export PERL_MM_USE_DEFAULT=1 MODULEBUILDRC=/dev/null
  /usr/bin/perl Build.PL
  ./Build
}

check() {
  cd "$srcdir/$_dist-$pkgver"
  unset PERL5LIB PERL_MM_OPT PERL_MB_OPT PERL_LOCAL_LIB_ROOT
  export PERL_MM_USE_DEFAULT=1
  ./Build test
}

package() {
  cd "$srcdir/$_dist-$pkgver"
  unset PERL5LIB PERL_MM_OPT PERL_MB_OPT PERL_LOCAL_LIB_ROOT
  ./Build install --installdirs=vendor --destdir="$pkgdir"
}

これらの PKGBUILD の追加の複雑さの正当化は、後のセクションで試みられます。

CPAN モジュールの仕組み

モジュールシステムを作成するために連携して動作する、慎重に設計されたメカニズムと、それほど慎重に設計されていないメカニズムが多数あります。CPAN を使用する場合は、モジュールのソースコードをフェッチし、フェッチしたモジュールをビルドし、後で実行するためにシステムソフトウェアに挿入する手順に従う必要があります。モジュールがどのようにパッケージ化されるべきかを理解するためには、pacman や ArchLinux パッケージを一切関与させずにモジュールがどのように機能するかを理解すると非常に役立ちます。私たちの最終的な目標は、最終製品の構成と一貫性を向上させながら、できるだけ目立たないようにすることです。

モジュール

モジュールは、perl では package キーワードを使用して宣言されます。モジュールは、.pm (dot-pee-em) ファイル内に含まれています。ただし、ファイル内に複数のモジュール (package) が含まれている可能性があります。モジュールには、Archlinux::Module のように、:: (二重コロン) で区切られた名前空間があります。モジュールをロードするとき、:: はディレクトリ区切り文字に置き換えられます。例: Archlinux/Module.pm はモジュール Archlinux::Module に対してロードされます。

コアモジュールは Perl のインストールに含まれています。一部のコアモジュールは、perl にバンドルされた物のみ利用可能です。他のモジュールは引き続き CPAN とは別にダウンロードしてインストールできます。

ディストリビューション

(別名 dist、package) これは、CPAN-lingo の Archlinux パッケージに相当します。ディストリビューションは、ファイルが詰まった .tar.gz アーカイブです。これらのアーカイブには主に .pm モジュールファイル、含まれているモジュールのテスト、モジュールのドキュメント、その他必要と思われるものがすべて含まれています。

通常、ディストリビューションには同じ名前のプライマリモジュールが含まれています。Template-Toolkit ディストリビューションのように、これが当てはまらない場合もあります。Template-Toolkit dist の最新パッケージ Template-Toolkit-2.22.tar.gz には、Template::Toolkit モジュールが含まれていません。

場合によっては、ディストリビューションの名前がメインモジュールにちなんで付けられているため、それらの名前が同じ意味で使用され、混同されてしまうことがあります。ただし、(Template-Toolkit の場合のように) それらを別個のエンティティとみなすと便利な場合があります。

CPAN

各 CPAN ミラーには、CPAN 上のディストリビューション、dist 内のモジュール、dist をアップロードした作成者の名前をリストするインデックスが含まれています。これらは単なるテキストファイルです。最も役立つインデックスは、各 CPAN ミラーから入手できる /modules/02packages.details.txt.gz ファイルにあります。ここでの package という用語は、pacman パッケージに似たものではなく、Perl 言語自体の package キーワードを指します。CPAN シェルは、小文字で斜体の cpan と呼ばれ、インデックスをナビゲートしてインストールするモジュールを見つける単純な由緒ある Perl スクリプトです。

モジュールは 02packages.details.txt.gz リストにあります。モジュール/パッケージ名と同じ行には、モジュールを含むディストリビューション tarball へのパスがあります。cpan にモジュールのインストールを依頼すると、モジュールを検索して関連するディストリビューションをインストールします。ディストリビューションのインストール中に、モジュールの依存関係のリストが生成されます。Cpan は、各モジュールの依存関係を Perl インタープリターにロードしようとします。指定されたバージョンのモジュールをロードできない場合は、プロセスが繰り返されます。

cpan シェルは、インストールする必要なモジュールのバージョンを気にする必要はありません。cpan は、モジュールの最新バージョンが最初にインストールを開始した元のモジュールの要件を満たしている必要があるという事実に依存できます。モジュールの最新バージョンのみがパッケージ詳細ファイルにリストされます。Perl パッケージ作成者にとって残念なことに、私たちのパッケージが最新バージョンの Perl ディストリビューションとそれに含まれるモジュールを提供するという事実に常に依存することはできません。Pacman の依存関係チェックはより静的であり、強力に適用されます。

モジュールの依存関係

Perl は、Python Egg や Ruby gem などの同様のシステムと比較して、依存関係を定義する独自の方法を持っています。エッグは他のエッグへの依存関係を定義します。Gems は Gems に依存します。Perl の dist はモジュールに依存します。モジュールは CPAN ディストリビューションからのみ入手できるため、ある意味、Perl ディストリビューションはディストリビューションに間接的にのみ依存します。モジュールは、モジュールのソースコード内のディストリビューションから独立して独自のバージョンを定義できます。これは、$VERSION という名前の package 変数を定義することによって行われます。strict および warnings を使用する場合、これは our キーワードで定義されます。例えば:

package Foo::Module;
use warnings;
use strict;
our $VERSION = '1.00';

モジュールはバージョンを自由に変更でき、配布バージョンとは異なるバージョンを持つこともできます。これの有用性には疑問がありますが、覚えておくことが重要です。モジュールのバージョンを Perl インタプリタの外部から判断するのはさらに難しく、Perl コード自体を解析し、場合によってはモジュールを Perl にロードする必要もあります。利点は、Perl インタープリターモジュールのバージョンを内部から簡単に判断できることです。例えば:

use Foo::Module;
print $Foo::Module::VERSION, "\n";

依存関係の定義

Perl ディストリビューションでは依存関係はどこに定義されていますか? これらは、Makefile.PL または Build.PL スクリプト内で定義されています。たとえば、Makefile.PL スクリプト内で WriteMakeFile 関数が呼び出され、次のように Makefile が生成されます。

use ExtUtils::MakeMaker;
WriteMakeFile(
    'NAME' => 'ArchLinux::Module',
    'VERSION' => '0.01',
    'PREREQ_PM' => { 'POSIX' => '0.01' },
);

これは不自然な例ですが、依存関係は Makefile.PL または Build.PL スクリプトが実行されるまで最終的なものではないことを理解することが重要です。依存関係は実行時に指定されます。つまり、perl の全機能を使用して依存関係を変更または修正できます。これは、モジュール作成者がディストリビューションをインストールする直前に、依存関係のバージョンを追加、削除、または変更できることを意味します。一部のモジュール作成者は、これを使用して、モジュールがインストールされている場合にのみモジュールに依存するなど、あまりにも賢いことを実行します。一部のマルチプラットフォーム dist は、異なるオペレーティングシステムにインストールされている場合、システム固有のモジュールに依存します。

例として、CPANPLUS ディストリビューションは、現在インストールされている CPANPLUS::Dist プラグインを検索します。現在インストールされているバージョンの CPANPLUS にプラグインがインストールされている場合、それらは新しい CPANPLUS の前提条件に追加されます。理由はよくわかりません。幸いなことに、perl パッケージャーの場合、ほとんどの依存関係は上記の例のように静的であり、最小バージョン 0.01 の POSIX モジュールが必要です。

メタ情報

メタファイルは、名前、作成者、要約説明、モジュール要件などのディストリビューションに関するメタ情報を含む、最近のディストリビューションに含まれています。以前は YAML 形式の META.yml ファイルがありましたが、最近では JSON 形式の META.json ファイルに切り替えられました。これらのファイルは、手動で編集することもできますが、多くの場合、リリース用にディストリビューションをパッケージ化するときに、Makefile.PL または Build.PL スクリプトによって自動的に生成されます。最新の仕様は CPAN::Meta::Spec のオンラインドキュメントで説明されています。

依存関係は実行時に変更できることに注意してください。このため、ビルドスクリプトの実行後に別のメタファイルが生成されます。この 2 番目のメタファイルは MYMETA.json と呼ばれ、実行時にスクリプトが行った変更を反映しており、ディストリビューションが CPAN 用にパッケージ化されたときに生成されたメタファイルとは異なる場合があります。

CPAN の古いディストリビューションにはメタファイルがまったくありません。これらの古いリリースは META.yml ファイルの考え方よりも前のものであり、その前提条件については Makefile.PL でのみ説明されています。

インストールモジュール

Perl の最大の強みは非常に多くのモジュールが CPAN に存在することです。当然のことながら、モジュールをインストールするためのモジュールも複数存在します。やり方はひとつではありません。ここではモジュールをインストールするためのモジュールを「インストールモジュール」と呼称しています。

これらのモジュールは、ディストリビューションの構築と、ユーザーが好む場所にモジュールファイルをインストールすることに関係します。これは簡単そうに見えますが、Perl が実行されるさまざまなシステムの数を考慮すると、複雑になる可能性があります。インストールモジュールはすべて、Perl コードファイルを dist tarball 内に配置します。この Perl スクリプトを実行すると、ビルドとインストールのプロセスが開始されます。スクリプトは常に .PL 接尾辞で終わり、以下のリストでは ビルドスクリプト と呼ばれます。

ExtUtils::MakeMaker

ビルドスクリプト: Makefile.PL
CPAN リンク: http://search.cpan.org/dist/ExtUtils-MakeMaker

モジュールをインストールための元祖・最古のモジュールが ExtUtils::MakeMaker です。大きな欠点として何かをビルド・インストールするのに make プログラムを必要とします。Linux ユーザーにとっては大きな問題ではありませんが Windows ユーザーには面倒です。

Module::Build

ビルドスクリプト: Build.PL
CPAN リンク: http://search.cpan.org/dist/Module-Build

Module::Build の主な利点は、純粋な Perl であることです。これは、モジュールを構築/インストールするために make プログラムをインストールする必要がないことを意味します。Module::Build がまだインストールされていない場合、バンドルされている Build.PL スクリプトを実行できなかったため、その採用は困難を極めました。Module::Build はコアモジュールであるため、これは Perl の最近のバージョンでは問題になりません。(NOTE perl 5.22 以降、Module::Build はコアモジュールではなくなります。)

Module::Build::Tiny

ビルドスクリプト: Build.PL
CPAN リンク: http://search.cpan.org/dist/Module-Build-Tiny

これも純粋な Perl ビルドツールです。インターフェイスとして、Module::Build のインターフェイスのサブセットを実装します。特に、引数の前にダッシュが必要です (Module::Build は、有無にかかわらず受け入れます)。また、.modulebuildrc はサポートしません。

Module::Install

ビルドスクリプト: Makefile.PL
CPAN リンク: http://search.cpan.org/dist/Module-Install

もう 1 つの最新のビルド/インストールモジュールである Module::Install が機能するには、依然として make プログラムがインストールされている必要があります。MI は、MakeMaker の欠点のいくつかに対処するために、MakeMaker のドロップイン代替品として設計されました。皮肉なことに、動作するには MakeMaker が必要です。 MI によって生成される Makefile.PL ファイルは見た目が大きく異なり、単純なドメイン固有言語を使用して実装されています。

非常に興味深い機能の 1 つは、Module::Install がそれ自体の 完全な コピー を配布ファイルにバンドルすることです。このため、MakeMaker や M::B とは異なり、Module::Install をシステムにインストールする必要はありません。

もう 1 つの非常にユニークな機能は自動インストールです。Module::Install の作成者は推奨していませんが、この機能は頻繁に使用されます。 モジュールの作成者が自分のディストリビューションの自動インストールを有効にすると、Module::Install Makefile.PL の実行時にインストールされていない前提条件モジュールを検索してインストールします。この機能は、Module::Install が CPAN または CPANPLUS によって実行されていることを検出するとスキップされます。ただし、この機能は内部で実行するとスキップされません...原因はよくわかりませんが...PKGBUILD です! PKGBUILD 内 でモジュールを勝手にダウンロードしてインストールする不正な Perl プログラムがどのように問題になるかがおわかりいただけたでしょうか。これを修正する方法については、PERL_AUTOINSTALL 環境変数を参照してください。

環境変数

様々な環境変数がモジュールのビルドやインストールに影響を与えます。一部の変数は劇的な効果をもたらし、間違って使うと問題が発生します。上級ユーザーは以下の環境変数を使用することができます。

PERL_MM_USE_DEFAULT

この変数が true 値に設定されている場合、インストールモジュールは通常の質問に対してデフォルトの回答が与えられたかのように動作します。これは常に機能するとは限りませんが、すべてのインストールモジュールはこれを尊重します。それはモジュール作成者がそうするという意味ではありません!

PERL_AUTOINSTALL

この変数を使用して、追加のコマンドライン引数を Module::Install の Makefile.PL に渡すことができます。自動インストールをオフにするには (強く推奨)、これに --skipdeps を割り当てます。

export PERL_AUTOINSTALL='--skipdeps'

PERL_MM_OPT

この変数を使用して、追加のコマンドライン引数を Makefile.PL や Build.PL に渡すことができます。たとえば、次を使用してモジュールをホームディレクトリにインストールできます。

export PERL_MM_OPT=INSTALLBASE=~/perl5

PERL_MB_OPT

これは、Module::Build のみを対象とする点を除けば、PERL_MM_OPT と同じです。たとえば、次のコマンドを使用してモジュールをホームディレクトリにインストールできます。

export PERL_MB_OPT=--install_base=~/perl5

MODULEBUILDRC

Module::Build を使用すると、そのコマンドライン引数を rcfile でオーバーライドできます。これのデフォルトは ~/.modulebuildrc です。これは、Perl ツールチェーン内では非推奨であると考えられています。MODULEBUILDRC で rcfile へのパスを設定することで、使用するファイルをオーバーライドできます。偏執的な人は、念のため、MODULEBUILDRC を /dev/null に設定するかもしれません。

PERL5LIB

ライブラリを検索するディレクトリは、ユーザーが PERL5LIB を設定することで設定できます (特に Local::Lib を使用している場合) それは構築する前にクリアする必要があります。

PERL_LOCAL_LIB_ROOT

ユーザーが Local::Lib を使用している場合は、PERL_LOCAL_LIB_ROOT が設定されます。それは構築する前にクリアする必要があります。

ユーザーがインストールした perl の問題

微妙な問題は、上級 Perl プログラマが複数のバージョンの Perl をインストールしたい場合があることです。これは、作成されたプログラムの下位互換性をテストするのに役立ちます。独自のカスタム Perl インタープリター (つまり、スレッドなし) をコンパイルすることには速度の利点もあります。カスタム perl を使用するもう 1 つの理由は、単純に、公式の perl Arch Linux パッケージが perl のリリースに遅れることがあるからです。ユーザーは最新の Perl を試している可能性があります。

ユーザーが $PATH にカスタム Perl 実行可能ファイルを持っている場合、ユーザーがシェルで perl コマンドを入力するとカスタム Perl が実行されます。実際、カスタム Perl は PKGBUILD 内でも実行されます。これにより、理解するのが難しい潜在的な問題が発生する可能性があります。

問題はコンパイルされた XS モジュールにあります。これらのモジュールは Perl と C を橋渡しします。そのため、このブリッジを実現するには Perl の内部 C API を使用する必要があります。Perl の C API は、perl のバージョンが異なると若干変更されます。ユーザーがシステム Perl (/usr/bin/perl) とは異なるバージョンの Perl を使用している場合、ユーザーの Perl でコンパイルされた XS モジュールはシステム全体の Perl と互換性がなくなります。コンパイルされた XS モジュールをシステム Perl で使用しようとすると、モジュールはリンクエラーでロードに失敗します。

簡単な解決策は、PKGBUILD で Perl を実行するときに、常にシステム全体の Perl インタープリタ (/usr/bin/perl) の絶対パスを使用することです。

@@ 1行目: / 1行目: @@
 [[Category:パッケージ開発]]
 [[en:Perl package guidelines]]
-[[it:Perl package guidelines]]
+[[pt:Perl package guidelines]]
 {{Package Guidelines}}
@@ 11行目: / 11行目: @@
 === パッケージの名前 ===
 モジュールの場合、パッケージの名前は {{Ic|perl-}} から始まるようにして、後はモジュールの名前を小文字に変換してコロンをハイフンに置き換えたものを付けてください。例えば {{Ic|HTML::Parser}} のパッケージ名は {{Ic|perl-html-parser}} となります。Perl アプリケーションの名前はアプリケーション自体の名前と同じにしてください (同じく小文字で)。
 === パッケージのファイルの置き場所 ===
 Perl パッケージはモジュールファイルを {{ic|/usr/lib/perl5/$version/vendor_perl/}} (スクリプトの中では {{ic|perl -V:vendorarch}}) または {{ic|/usr/share/perl5/vendor_perl/}} にインストールしてください。下の例にあるように {{Ic|INSTALLDIRS}} コマンドラインパラメータを {{ic|vendor}} に設定することでインストールできます。{{ic|/usr/lib/perl5/$version/site_perl/}} にファイルを保存してはいけません。システム管理者がパッケージ管理システムの管理外となる Perl パッケージをインストールするため用に予約されたディレクトリです。ユーザーが {{ic|cpan}} シェルを使ってシステム全体にモジュールをインストールすると、モジュールは {{ic|site-perl}} サブディレクトリに保存されます。
@@ 19行目: / 21行目: @@
 === アーキテクチャ ===
 ほとんどの Perl パッケージはアーキテクチャに依存しないため {{Ic|arch}} 配列には {{Ic|'any'}} を指定する場合がほとんどです。XS モジュールは動的にロードされるライブラリとしてコンパイルされるため (.so ファイル)、アーキテクチャを {{Ic|('x86_64')}} と明示的に設定する必要があります。XS モジュールには大抵 .c ファイルを動的に生成する .xs ファイルが含まれています。
 === 自動化 ===
 第2世代の CPAN シェルである CPANPLUS のプラグインが {{Pkg|perl-cpanplus-dist-arch}} パッケージでインストールできます。CPANPLUS によってインストールされたファイルを即座にパッケージ化します。オンラインドキュメントが https://metacpan.org/release/CPANPLUS-Dist-Arch から確認できます。
 == PKGBUILD サンプル ==
 サンプル PKGBUILD は [https://git.archlinux.org/abs.git/tree/prototypes/PKGBUILD-perl.proto] で確認できます。
+次の 2 つの PKGBUILD の例では、PKGBUILD のより高度な問題に対する回復力を高めることを目的とした、このページで紹介した手法を使用しています。ビルドスクリプトには 2 つのスタイルがあるため、PKGBUILDS の例が 2 つあります。最初の PKGBUILD は、{{ic|Makefile.PL}} を使用するディストリビューションをパッケージ化する方法の例です。2 番目の PKGBUILD は、{{ic|Build.PL}} を使用するディストリビューションの開始点として使用できます。
-The following two PKGBUILD examples use techniques, introduced in this page, that are intended to make a PKGBUILD more resilient to more sophisticated problems. Because there are two styles of build scripts, there are two example PKGBUILDS. The first PKGBUILD is an example of how to package a distribution that uses {{ic|Makefile.PL}}. The second PKGBUILD can be used as a starting point for a distribution which uses {{ic|Build.PL}}.
 {{hc|PKGBUILD|<nowiki>
@@ 103行目: / 108行目: @@
 </nowiki>}}
+これらの PKGBUILD の追加の複雑さの正当化は、後のセクションで試みられます。
-Justification for the added complexity of these PKGBUILDs is attempted in the latter sections.
 == CPAN モジュールの仕組み ==
+モジュールシステムを作成するために連携して動作する、慎重に設計されたメカニズムと、それほど慎重に設計されていないメカニズムが多数あります。CPAN を使用する場合は、モジュールのソース コードをフェッチし、フェッチしたモジュールをビルドし、後で実行するためにシステム ソフトウェアに挿入する手順に従う必要があります。モジュールがどのようにパッケージ化されるべきかを理解するためには、pacman や ArchLinux パッケージを一切関与させずにモジュールがどのように機能するかを理解すると非常に役立ちます。私たちの最終的な目標は、最終製品の構成と一貫性を向上させながら、できるだけ目立たないようにすることです。
-There are a number of carefully, and not so carefully, designed mechanics that work together to create the module system. When making use of the CPAN, procedures must be followed to fetch the source code of a module, build that fetched module, and insert it into the system software for later execution. In order to understand how modules should be packaged, it helps immensely if one understands how modules work without any involvement from pacman and ArchLinux packages. Our goal in the end is to try to be unobtrusive as possible, while improving organization and consistency in the end product.
 === モジュール ===
-Modules are declared with the {{Ic|package}} keyword in perl.  Modules are contained inside a {{ic|.pm}} ("dot-pee-em") file.  Though it's possible more than one module ({{Ic|package}}) is in the file.  Modules have namespaces separated with {{Ic|::}} (double colons), like: {{Ic|Archlinux::Module}}.  When loading a module, the {{Ic|::}}s are replaced with directory separators.  For example: {{ic|Archlinux/Module.pm}} will be loaded for the module {{Ic|Archlinux::Module}}.
+モジュールは、perl では {{Ic|package}} キーワードを使用して宣言されます。モジュールは、{{ic|.pm}} (''dot-pee-em'') ファイル内に含まれています。ただし、ファイル内に複数のモジュール ({{Ic|package}}) が含まれている可能性があります。モジュールには、{{Ic|Archlinux::Module}} のように、{{Ic|::}} (二重コロン) で区切られた名前空間があります。モジュールをロードするとき、{{Ic|::}} はディレクトリ区切り文字に置き換えられます。例: {{ic|Archlinux/Module.pm}} はモジュール {{Ic|Archlinux::Module}} に対してロードされます。
-Core modules are included with an installation of perl.  Some core modules are ''only'' available bundled with perl.  Other modules can still be downloaded and installed separately from CPAN.
+コアモジュールは Perl のインストールに含まれています。一部のコアモジュールは、perl にバンドルされた物 ''のみ''利用可能です。  他のモジュールは引き続き CPAN とは別にダウンロードしてインストールできます。
 === ディストリビューション ===
-(aka dist, package)  This is the equivalent of an Archlinux package in CPAN-lingo.  Distributions are {{ic|.tar.gz}} archives full of files.  These archives contain primarily .pm module files, tests for the included modules, documentation for the modules, and whatever else is deemed necessary.
+(別名 dist、package) これは、CPAN-lingo の Archlinux パッケージに相当します。ディストリビューションは、ファイルが詰まった {{ic|.tar.gz}} アーカイブです。これらのアーカイブには主に .pm モジュール ファイル、含まれているモジュールのテスト、モジュールのドキュメント、その他必要と思われるものがすべて含まれています。
-Usually a distribution contains a primary module with the same name.  Sometimes this is not true, like with the Template-Toolkit distribution.  The latest package, {{ic|Template-Toolkit-2.22.tar.gz}}, for the {{Ic|Template-Toolkit}} dist, contains no {{Ic|Template::Toolkit}} module!
+通常、ディストリビューションには同じ名前のプライマリモジュールが含まれています。Template-Toolkit ディストリビューションのように、これが当てはまらない場合もあります。{{Ic|Template-Toolkit}} dist の最新パッケージ {{ic|Template-Toolkit-2.22.tar.gz}} には、{{Ic|Template::Toolkit}} モジュールが含まれていません。
-Sometimes because distributions are named after a main module, their names are used interchangeably and they get muddled together.  However it is sometimes useful to consider them a separate entity (like in Template-Toolkit's case).
+場合によっては、ディストリビューションの名前がメインモジュールにちなんで付けられているため、それらの名前が同じ意味で使用され、混同されてしまうことがあります。ただし、(Template-Toolkit の場合のように) それらを別個のエンティティとみなすと便利な場合があります。
 === CPAN ===
-Each CPAN mirror contains indices that list the distributions on CPAN, the modules in the dists, and the name of the author who uploaded the dist. These are simply text files. The most useful index is in the {{ic|/modules/02packages.details.txt.gz}} file available from each CPAN mirror. The term "packages" here refers to the {{ic|package}} keyword in the perl language itself, not something similar to pacman packages. The CPAN shell, referred to as lowercased, italicized <i>cpan</i>, is simply the venerable perl script which navigates indices to find the module you want to install.
+各 CPAN ミラーには、CPAN 上のディストリビューション、dist 内のモジュール、dist をアップロードした作成者の名前をリストするインデックスが含まれています。これらは単なるテキストファイルです。最も役立つインデックスは、各 CPAN ミラーから入手できる {{ic|/modules/02packages.details.txt.gz}} ファイルにあります。ここでの ''package'' という用語は、pacman パッケージに似たものではなく、Perl 言語自体の {{ic|package}} キーワードを指します。CPAN シェルは、小文字で斜体の ''cpan'' と呼ばれ、インデックスをナビゲートしてインストールするモジュールを見つける単純な由緒ある Perl スクリプトです。
-Modules are found in the {{ic|02packages.details.txt.gz}} list. On the same line as the module/package name is the path to the distribution tarball that contains the module. When you ask <i>cpan</i> to install a module, it will look up the module and install the relevant distribution. As the distribution is installing it will generate a list of module dependencies. <i>Cpan</i> will try to load each module dependency into the perl interpreter. If a module of the given version cannot be loaded the process is repeated.
+モジュールは {{ic|02packages.details.txt.gz}} リストにあります。モジュール/パッケージ名と同じ行には、モジュールを含むディストリビューション tarball へのパスがあります。''cpan'' にモジュールのインストールを依頼すると、モジュールを検索して関連するディストリビューションをインストールします。ディストリビューションのインストール中に、モジュールの依存関係のリストが生成されます。''Cpan'' は、各モジュールの依存関係を Perl インタープリターにロードしようとします。指定されたバージョンのモジュールをロードできない場合は、プロセスが繰り返されます。
-The <i>cpan</i> shell does not have to worry about what version of the required module it is installing. <i>cpan</i> can rely on the fact that the latest version of the module must satisfy the requirements of the original module that it began installing in the first place. Only the latest versions of modules are listed in the packages details file. Unfortunately for the perl package author, we cannot always rely on the fact that our packages offer the most recent version of a perl distribution and the modules contained within. Pacman dependency checking is much more static and strongly enforced.
+''cpan'' シェルは、インストールする必要なモジュールのバージョンを気にする必要はありません。''cpan'' は、モジュールの最新バージョンが最初にインストールを開始した元のモジュールの要件を満たしている必要があるという事実に依存できます。モジュールの最新バージョンのみがパッケージ詳細ファイルにリストされます。Perl パッケージ作成者にとって残念なことに、私たちのパッケージが最新バージョンの Perl ディストリビューションとそれに含まれるモジュールを提供するという事実に常に依存することはできません。Pacman の依存関係チェックはより静的であり、強力に適用されます。
 === モジュールの依存関係 ===
-Perl has a unique way of defining dependencies compared to similar systems like python eggs and ruby gems. Eggs define dependencies on other eggs. Gems depend on gems. Perl dists depend on modules. Modules are only available from CPAN distributions so in a way perl distributions depend on distributions only indirectly. Modules can define their own versions independent from distributions inside the module source code. This is done by defining a <i>package</i> variable called {{ic|$VERSION}}. When using strict and warnings, this is defined with the our keyword. For example:
+Perl は、Python Egg や Ruby gem などの同様のシステムと比較して、依存関係を定義する独自の方法を持っています。エッグは他のエッグへの依存関係を定義します。Gems は Gems に依存します。Perl の dist はモジュールに依存します。モジュールは CPAN ディストリビューションからのみ入手できるため、ある意味、Perl ディストリビューションはディストリビューションに間接的にのみ依存します。モジュールは、モジュールのソース コード内のディストリビューションから独立して独自のバージョンを定義できます。これは、{{ic|$VERSION}} という名前の ''package'' 変数を定義することによって行われます。strict および warnings を使用する場合、これは our キーワードで定義されます。例えば:
 {{bc|1=
@@ 138行目: / 147行目: @@
 }}
+モジュールはバージョンを自由に変更でき、配布バージョンとは異なるバージョンを持つこともできます。これの有用性には疑問がありますが、覚えておくことが重要です。モジュールのバージョンを Perl インタプリタの外部から判断するのはさらに難しく、Perl コード自体を解析し、場合によってはモジュールを Perl にロードする必要もあります。利点は、Perl インタープリターモジュールのバージョンを内部から簡単に判断できることです。例えば:
-Modules can change their versions however they like and even have a version distinct from the distribution version. The utility of this is questionable but it is important to keep in mind. Module versions are more difficult to determine from outside of the perl interpreter and require parsing the perl code itself and maybe even loading the module into perl. The advantage is that from inside the perl interpreter module versions are easy to determine. For example:
 {{bc|
@@ 146行目: / 155行目: @@
 === 依存関係の定義 ===
-Where are dependencies defined in perl distributions? They are "defined" inside of the {{ic|Makefile.PL}} or {{ic|Build.PL}} script. For example, inside of the {{ic|Makefile.PL}} script the {{ic|WriteMakeFile}} function is called to generate the {{ic|Makefile}} like this:
+Perl ディストリビューションでは依存関係はどこに定義されていますか? これらは、{{ic|Makefile.PL}} または {{ic|Build.PL}} スクリプト内で ''定義'' されています。たとえば、{{ic|Makefile.PL}} スクリプト内で {{ic|WriteMakeFile}} 関数が呼び出され、次のように {{ic|Makefile}} が生成されます。
 {{bc|<nowiki>
@@ 157行目: / 167行目: @@
 </nowiki>}}
+これは不自然な例ですが、依存関係は {{ic|Makefile.PL}} または {{ic|Build.PL}} スクリプトが実行されるまで最終的なものではないことを理解することが重要です。依存関係は実行時に指定されます。つまり、perl の全機能を使用して依存関係を変更または修正できます。これは、モジュール作成者がディストリビューションをインストールする直前に、依存関係のバージョンを追加、削除、または変更できることを意味します。一部のモジュール作成者は、これを使用して、モジュールがインストールされている場合にのみモジュールに依存するなど、あまりにも賢いことを実行します。一部のマルチプラットフォーム dist は、異なるオペレーティングシステムにインストールされている場合、システム固有のモジュールに依存します。
-This is a contrived example but it is important to understand the dependencies aren't final until after the {{ic|Makefile.PL}} or {{ic|Build.PL}} script is run. Dependencies are specified at runtime, which means they can be changed or modified using the full power of perl. This means the module author can add, remove, or change versions of dependencies right before the distribution is installed. Some modules authors use this to do overly clever things like depend on modules only if they are installed. Some multi-platform dists also depend on system-specific modules when installed on different operating systems.
+例として、CPANPLUS ディストリビューションは、現在インストールされている CPANPLUS::Dist プラグインを検索します。現在インストールされているバージョンの CPANPLUS にプラグインがインストールされている場合、それらは新しい CPANPLUS の前提条件に追加されます。理由はよくわかりません。幸いなことに、perl パッケージャーの場合、ほとんどの依存関係は上記の例のように静的であり、最小バージョン 0.01 の POSIX モジュールが必要です。
-As an example, the CPANPLUS distribution looks for CPANPLUS::Dist plugins that are currently installed. If any plugins are installed for the currently installed version of CPANPLUS it adds them to the new CPANPLUS's prerequisites. I'm not quite sure why. Luckily for the perl packager most dependencies are static like in the above example that requires the POSIX module with a minimum version of 0.01.
 === メタ情報 ===
-Meta files are included in recent distributions which contain meta-information about distributions such as the name, author, abstract description, and module requirements. Previously there were {{ic|META.yml}} files in the YAML format but more recently the switch has been made to {{ic|META.json}} files in the JSON format. These files can
-be edited by hand but more often they are generated automatically by {{ic|Makefile.PL}} or {{ic|Build.PL}} scripts when packaging a distribution for release. The latest specification is described in [http://search.cpan.org/perldoc?CPAN::Meta::Spec CPAN::Meta::Spec's online docs].
+メタファイルは、名前、作成者、要約説明、モジュール要件などのディストリビューションに関するメタ情報を含む、最近のディストリビューションに含まれています。以前は YAML 形式の {{ic|META.yml}} ファイルがありましたが、最近では JSON 形式の {{ic|META.json}} ファイルに切り替えられました。これらのファイルは、
-Remember that dependencies can be changed at runtime! For this reason another meta file is generated after running the build script. This second meta file is called {{ic|MYMETA.json}} and reflects changes the script made at runtime and may be different from the meta file generated when the distribution was packaged for CPAN.
+手動で編集することもできますが、多くの場合、リリース用にディストリビューションをパッケージ化するときに、{{ic|Makefile.PL}} または {{ic|Build.PL}} スクリプトによって自動的に生成されます。最新の仕様は [https://search.cpan.org/perldoc?CPAN::Meta::Spec CPAN::Meta::Spec のオンラインドキュメント] で説明されています。
+依存関係は実行時に変更できることに注意してください。このため、ビルドスクリプトの実行後に別のメタファイルが生成されます。この 2 番目のメタファイルは {{ic|MYMETA.json}} と呼ばれ、実行時にスクリプトが行った変更を反映しており、ディストリビューションが CPAN 用にパッケージ化されたときに生成されたメタファイルとは異なる場合があります。
-Elderly distributions on the CPAN have no meta file at all. These old releases predate the idea of the META.yml file and only describe their prerequisites in their {{ic|Makefile.PL}}.
+CPAN の古いディストリビューションにはメタファイルがまったくありません。これらの古いリリースは META.yml ファイルの考え方よりも前のものであり、その前提条件については {{ic|Makefile.PL}} でのみ説明されています。
 == インストールモジュール ==
 Perl の最大の強みは非常に多くのモジュールが CPAN に存在することです。当然のことながら、モジュールをインストールするためのモジュールも複数存在します。やり方はひとつではありません。ここではモジュールをインストールするためのモジュールを「インストールモジュール」と呼称しています。
+これらのモジュールは、ディストリビューションの構築と、ユーザーが好む場所にモジュールファイルをインストールすることに関係します。  これは簡単そうに見えますが、Perl が実行されるさまざまなシステムの数を考慮すると、複雑になる可能性があります。インストールモジュールはすべて、Perl コードファイルを dist tarball 内に配置します。この Perl スクリプトを実行すると、ビルドとインストールのプロセスが開始されます。スクリプトは常に {{ic|.PL}} 接尾辞で終わり、以下のリストでは ''ビルドスクリプト'' と呼ばれます。
-These modules are concerned with building the distribution and installing module files wherever the user prefers.  This seems straightforward, but considering the number of different systems perl runs on, this can get complex.  Installation modules all place a perl code file inside the dist tarball.  Running this perl script will initiate the build and install process.  The script always ends with the {{ic|.PL}} suffix and is termed the "Build script" in the below list.
 === ExtUtils::MakeMaker ===
 ;ビルドスクリプト: {{ic|Makefile.PL}}
 ;CPAN リンク: http://search.cpan.org/dist/ExtUtils-MakeMaker
@@ 181行目: / 194行目: @@
 === Module::Build ===
 ;ビルドスクリプト: {{ic|Build.PL}}
 ;CPAN リンク: http://search.cpan.org/dist/Module-Build
-Module::Build の利点は perl だけで書かれていることです。モジュールをビルド・インストールするのに {{ic|make}} プログラムをインストールする必要がありません。{{Ic|Module::Build}} がインストールされていないと、同梱されている {{ic|Build.PL}} スクリプトも実行できません。最近のバージョンの Perl では {{Ic|Module::Build}} はコアモジュールとなっているためそのような問題はありません。
+Module::Build の主な利点は、純粋な Perl であることです。これは、モジュールを構築/インストールするために {{ic|make}} プログラムをインストールする必要がないことを意味します。{{ic|Module::Build}} がまだインストールされていない場合、バンドルされている {{ic|Build.PL}} スクリプトを実行できなかったため、その採用は困難を極めました。{{ic|Module::Build}} はコアモジュールであるため、これは Perl の最近のバージョンでは問題になりません。('''NOTE''' perl 5.22 以降、Module::Build はコアモジュールではなくなります。)
-{{Note|perl 5.22 現在、Module::Build はコアモジュールではありません。}}
 === Module::Build::Tiny ===
 ;ビルドスクリプト: {{ic|Build.PL}}
 ;CPAN リンク: http://search.cpan.org/dist/Module-Build-Tiny
+これも純粋な Perl ビルドツールです。インターフェイスとして、Module::Build のインターフェイスのサブセットを実装します。特に、引数の前にダッシュが必要です (Module::Build は、有無にかかわらず受け入れます)。また、{{Ic|.modulebuildrc}} はサポートしません。
-This is another pure-perl build tool. As an interface it implements a subset of Module::Build's interface, in particular it requires dashes before its arguments (Module::Build accepts with and without) and doesn't support {{Ic|.modulebuildrc}}.
 === Module::Install ===
 ;ビルドスクリプト: {{ic|Makefile.PL}}
 ;CPAN リンク: http://search.cpan.org/dist/Module-Install
+もう 1 つの最新のビルド/インストールモジュールである {{Ic|Module::Install}} が機能するには、依然として {{ic|make}} プログラムがインストールされている必要があります。{{Ic|MI}} は、{{Ic|MakeMaker}} の欠点のいくつかに対処するために、{{Ic|MakeMaker}} のドロップイン代替品として設計されました。皮肉なことに、動作するには {{Ic|MakeMaker}} が必要です。  {{Ic|MI}} によって生成される {{ic|Makefile.PL}} ファイルは見た目が大きく異なり、単純なドメイン固有言語を使用して実装されています。
-Another modern build/installation module, {{Ic|Module::Install}} still requires the {{ic|make}} program be installed to function.  {{Ic|MI}} was designed as a drop-in replacement for {{Ic|MakeMaker}}, to address some of {{Ic|MakeMaker}}'s shortcomings. Ironically, it depends on {{Ic|MakeMaker}} in order to operate. The {{ic|Makefile.PL}} files that are generated by {{Ic|MI}} look much different and are implemented using a simple domain specific language.
-One very interesting feature is that {{Ic|Module::Install}} bundles a ''complete'' ''copy'' of itself into the distribution file.  Because of this, unlike {{Ic|MakeMaker}} or {{Ic|M::B}}, you do not need {{Ic|Module::Install}} to be installed on your system.
+非常に興味深い機能の 1 つは、{{Ic|Module::Install}} がそれ自体の ''完全な'' ''コピー'' を配布ファイルにバンドルすることです。このため、{{Ic|MakeMaker}} や {{Ic|M::B}} とは異なり、{{Ic|Module::Install}} をシステムにインストールする必要はありません。
+もう 1 つの非常にユニークな機能は自動インストールです。''{{Ic|Module::Install}} の作成者は推奨していませんが、この機能は頻繁に使用されます。'' モジュールの作成者が自分のディストリビューションの自動インストールを有効にすると、{{Ic|Module::Install}} {{ic|Makefile.PL}} の実行時にインストールされていない前提条件モジュールを検索してインストールします。この機能は、{{Ic|Module::Install}} が {{Ic|CPAN}} または {{Ic|CPANPLUS}} によって実行されていることを検出するとスキップされます。ただし、この機能は内部で実行するとスキップされません...原因はよくわかりませんが...''PKGBUILD'' です! ''PKGBUILD 内'' でモジュールを勝手にダウンロードしてインストールする不正な Perl プログラムがどのように問題になるかがおわかりいただけたでしょうか。これを修正する方法については、[[Perl パッケージガイドライン#PERL_AUTOINSTALL|PERL_AUTOINSTALL]] 環境変数を参照してください。
-Another very unique feature is auto-install.  ''Though not recommended by {{Ic|Module::Install}}'s authors this feature is used quite often.''  When the module author enables auto-install for his distribution, {{Ic|Module::Install}} will search for and install any pre-requisite modules that are not installed when {{ic|Makefile.PL}} is executed.  This feature is skipped when {{Ic|Module::Install}} detects it is being run by {{Ic|CPAN}} or {{Ic|CPANPLUS}}.  However, this feature is not skipped when run inside... oh I don't know... a '''PKGBUILD'''!  I hope you can see how a rogue perl program downloading and installing modules willy-nilly ''inside a PKGBUILD'' can be a problem.  See the [[#PERL_AUTOINSTALL]] environment variable to see how to fix this.
 === 環境変数 ===
 様々な環境変数がモジュールのビルドやインストールに影響を与えます。一部の変数は劇的な効果をもたらし、間違って使うと問題が発生します。上級ユーザーは以下の環境変数を使用することができます。
 ==== PERL_MM_USE_DEFAULT ====
-When this variable is set to a true value, the installation module will pretend the default answer was given to any question it would normally ask.  This does not ''always'' work, but all of the installation modules honour it.  ''That doesn't mean the module author will!''
+この変数が true 値に設定されている場合、インストール モジュールは通常の質問に対してデフォルトの回答が与えられたかのように動作します。  これは ''常に'' 機能するとは限りませんが、すべてのインストールモジュールはこれを尊重します。''それはモジュール作成者がそうするという意味ではありません!''
 ==== PERL_AUTOINSTALL ====
-You can pass additional command-line arguments to {{Ic|Module::Install}}'s {{ic|Makefile.PL}} with this variable.  In order to turn off auto-install (''highly recommended''), assign {{Ic|--skipdeps}} to this.
+この変数を使用して、追加のコマンドライン引数を {{Ic|Module::Install}} の {{ic|Makefile.PL}} に渡すことができます。自動インストールをオフにするには (''強く推奨'')、これに {{Ic|--skipdeps}} を割り当てます。
 {{bc|1=export PERL_AUTOINSTALL='--skipdeps'}}
 ==== PERL_MM_OPT ====
-You can pass additional command-line arguments to {{ic|Makefile.PL}} and/or {{ic|Build.PL}} with this variable.  For example, you can install modules into your home-dir by using:
+この変数を使用して、追加のコマンドライン引数を {{ic|Makefile.PL}} や {{ic|Build.PL}} に渡すことができます。たとえば、次を使用してモジュールをホームディレクトリにインストールできます。
 {{bc|1=export PERL_MM_OPT=INSTALLBASE=~/perl5}}
 ==== PERL_MB_OPT ====
-This is the same thing as {{Ic|PERL_MM_OPT}} except it is only for {{Ic|Module::Build}}.  For example, you could install modules into your home-dir by using:
+これは、{{Ic|Module::Build}} のみを対象とする点を除けば、{{Ic|PERL_MM_OPT}} と同じです。たとえば、次のコマンドを使用してモジュールをホームディレクトリにインストールできます。
 {{bc|1=export PERL_MB_OPT=--install_base=~/perl5}}
 ==== MODULEBUILDRC ====
-{{Ic|Module::Build}} allows you to override its command-line-arguments with an rcfile.  This defaults to {{ic|~/.modulebuildrc}}.  This is considered deprecated within the perl toolchain. You can override which file it uses by setting the path to the rcfile in {{Ic|MODULEBUILDRC}}.  The paranoid might set {{Ic|MODULEBUILDRC}} to {{ic|/dev/null}}... just in case.
+{{Ic|Module::Build}} を使用すると、そのコマンドライン引数を rcfile でオーバーライドできます。これのデフォルトは {{ic|~/.modulebuildrc}} です。これは、Perl ツールチェーン内では非推奨であると考えられています。{{Ic|MODULEBUILDRC}} で rcfile へのパスを設定することで、使用するファイルをオーバーライドできます。偏執的な人は、念のため、{{Ic|MODULEBUILDRC}} を {{ic|/dev/null}} に設定するかもしれません。
 ==== PERL5LIB ====
-The directories searched for libraries can be set by the user (particularly if they are using {{ic|Local::Lib}}) by setting {{ic|PERL5LIB}}. That should be cleared before building.
+ライブラリを検索するディレクトリは、ユーザーが {{ic|PERL5LIB}} を設定することで設定できます (特に {{ic|Local::Lib}} を使用している場合) それは構築する前にクリアする必要があります。
 ==== PERL_LOCAL_LIB_ROOT ====
-If the user is using {{ic|Local::Lib}} it will set {{ic|PERL_LOCAL_LIB_ROOT}}. That should be cleared before building.
+ユーザーが {{ic|Local::Lib}} を使用している場合は、{{ic|PERL_LOCAL_LIB_ROOT}} が設定されます。それは構築する前にクリアする必要があります。
 == ユーザーがインストールした perl の問題 ==
-A subtle problem is that advanced perl programmers may like to have multiple versions of perl installed. This is useful for testing backwards-compatibility in created programs. There are also speed benefits to compiling your own custom perl interpreter (i.e. without threads). Another reason for a custom ''perl'' is simply because the official perl Arch Linux package sometimes lags behind perl releases. The user may be trying out the latest perl... who knows?
+微妙な問題は、上級 Perl プログラマが複数のバージョンの Perl をインストールしたい場合があることです。これは、作成されたプログラムの下位互換性をテストするのに役立ちます。独自のカスタム Perl インタープリター (つまり、スレッドなし) をコンパイルすることには速度の利点もあります。カスタム ''perl'' を使用するもう 1 つの理由は、単純に、公式の perl Arch Linux パッケージが perl のリリースに遅れることがあるからです。ユーザーは最新の Perl を試している可能性があります。
-If the user has the custom perl executable in their {{Ic|$PATH}}, the custom perl will be run when the user types the ''perl'' command on the shell. In fact the custom perl will run inside the {{ic|PKGBUILD}} as well! This can lead to insidious problems that are difficult to understand.
+ユーザーが {{Ic|$PATH}} にカスタム Perl 実行可能ファイルを持っている場合、ユーザーがシェルで ''perl'' コマンドを入力するとカスタム Perl が実行されます。実際、カスタム Perl は {{ic|PKGBUILD}} 内でも実行されます。これにより、理解するのが難しい潜在的な問題が発生する可能性があります。
+問題はコンパイルされた XS モジュールにあります。これらのモジュールは Perl と C を橋渡しします。そのため、このブリッジを実現するには Perl の内部 C API を使用する必要があります。Perl の C API は、perl のバージョンが異なると若干変更されます。ユーザーがシステム Perl ({{ic|/usr/bin/perl}}) とは異なるバージョンの Perl を使用している場合、ユーザーの Perl でコンパイルされた XS モジュールはシステム全体の Perl と互換性がなくなります。コンパイルされた XS モジュールをシステム Perl で使用しようとすると、モジュールはリンクエラーでロードに失敗します。
-The problem lies in compiled XS modules. These modules bridge perl and C. As such they must use perl's internal C API to accomplish this bridge. Perl's C API changes slightly with different versions of perl. If the user has a different version of perl than the system perl ({{ic|/usr/bin/perl}}) then any XS module compiled with the user's perl will be incompatible with the system-wide perl. When trying to use the compiled XS module with the system perl, the module will fail to load with a link error.
+簡単な解決策は、{{ic|PKGBUILD}} で Perl を実行するときに、常にシステム全体の Perl インタープリタ ({{ic|/usr/bin/perl}}) の絶対パスを使用することです。
-A simple solution is to always use the absolute path of the system-wide perl interpreter ({{ic|/usr/bin/perl}}) when running perl in the {{ic|PKGBUILD}}.