by Hippo2000(2000/12/19)
CPAN.pmなのです。
腰が抜けるほど、モジュールのインストールが簡単になるモジュールなのです。
作者はAndreas Koenigさんです。メールで了解をいただきました。
なお内容等が間違っていたら修正します。ご連絡ください。
変更履歴：
Kentaro Shirakataさんからの指摘を受けて誤字を修正しました。(2002/2/1)
CPAN - CPANサイトからのperlモジュールの問い合わせ、ダウンロード、構築を行う
対話モード：
perl -MCPAN -e shell;
バッチモード：
use CPAN;
autobundle, clean, install, make, recompile, test
CPANモジュールはperlモジュールのmakeとインストールを自動化するように設計されています。それはいくつかの検索機能を持ち、ネットから生のデータを取得するためにNet::FTPまたはLWP（またはlynxや外部のftpクライアント）の使い方を知っています。
モジュールは１つまたは複数のミラー化されたCPAN(Comprehensive Perl Archive Network) サイトから取得され、与えられたディレクトリに解凍されます。
CPANモジュールはモジュールの名前付きとバージョン付きのbundlesの考えにサポートします。Bundlesは関連するモジュールのセットの扱いを簡単にします。下記のBundlesをご覧ください。
パッケージにはセッション・マネージャとキャッシュ・マネージャが入っています。セッション間で保持されるステータスありません。セッション・マネージャは現在のセッションで何が取り出され、構築され、インストールされたかを追跡します。キャッシュ・マネージャはmakeプロセスにより占有されたディスク・スペースを追跡し、単純なFIFO機能にしたがって過剰なスペースを削除します。
拡張された検索機能のために、CPANが利用できるプラグイン、CPAN::WAIT.があります。CPAN::WAITは全文検索エンジンで、CPAN authorsディレクトリで利用できるすべてのドキュメントを索引付けします。CPAN::WAITがあなたのシステムにインストールされると、<CPAN.pm>の対話シェルは、インストールで設定されたWAITサーバへ問い合わせを送信するwq、wr、wd、wlそしてwhコマンドが使えるようになります。
他の全てのメソッドはプログラマ形式と対話シェル形式でアクセスできるように提供されています。
対話モードには以下のように実行することで入ります：
perl -MCPAN -e shell
これは行読込インターフェースにします。ヒストリとコマンド完成の両方を楽しむためにTerm::ReadKeyとTerm::ReadLineをインストールするとより楽しめるでしょう。
コマンドラインであれば、'h'を叩いてください、そして残りはすぐにわかるでしょう。
対話モードでの最も一般的な使用方法は
これらのコマンドに渡す引数は、オブジェクトを識別する文字列に完全にマッチするか、オブジェクトの多くの属性に対して大文字小文字の区別なくマッチする正規表現のいずれかになります。パーサーは２つのスラッシュで囲んだときだけ、正規表現を解析します。
原則は見つかったオブジェクトの数が項目の表示のされ方に影響を与えます。もし検索が１つの要素を見つければ、結果はむしろ冗長なメソッドas_stringで表示されます。しかし１つより多ければ、簡潔なメソッドas_glimpseで表示します。
すべてのmakeまたはtestは無条件に実行されます。
install <distribution_file>
も無条件に実行されます。しかし
install <module>
では、CPANは、インストールが本当にそれに必要なのかをチェックし、そしてそのディストリビューション・ファイルに更新する必要がないモジュールが入っていた場合には、module up to date （最新版）と出力します。
CPANは現在のセッションで何をしたかを追跡し、そしてそれが成功したかどうかにかかわらず、パッケージを2度ビルドしようとはしません。forceコマンドは最初の引数を（現在は：make、testまたはinstall)呼出し、そしてはじめからコマンドを実行するように取ります。
例：
cpan> install OpenGL
OpenGL is up to date.
cpan> force install OpenGL
Running make
OpenGL-0.4/
OpenGL-0.4/COPYRIGHT
[...]
cleanコマンドは結果として ディストリビューション・ファイルの作業ディレクトリでの
make clean
が実行されます。
CPAN.pmはSIGPIPEを無視します。もしユーザが inactivity_timeoutを設定すると、perl Makefile.PLサブプロセス実行中にSIGALRMが使われます。
シェル・インターフェースで利用できるコマンドはCPAN::Shellパッケージでのメソッドです。もしシェル・コマンドを入れると、入力されたすべてのものはText::ParseWords::shellwords()ルーチンによって分割されます。これはほとんどのシェルがするように行われます。最初の単語は呼び出されるメソッドとして、残りの単語はこのメソッドへの引数として解釈されます。もし行の最後がバックスラッシュであれば、行の続きがサポートされます。
autobundle はバンドル・ファイルを$CPAN->Config->{cpan_home}/Bundleディレクトリに書込みます。そのファイルにはCPANからと現在@INCにインストールされている両方から利用でいるすべてのモジュールが入ります。バンドル・ファイルの名前は現在の日付とカウンタが基本になります。
recompile()
は非常に特殊なコマンドで、引数をとらず、すべてのインストールされている動的にロードできる拡張（いわゆるXSモジュール）に対して'force'を有効としてmake/test/installのサイクルを強引に実行します。このコマンドの基本的な目的は、ネットワーク・インストールを完了させることです。２つの異なるアーキテチャのための共通なソース・ツリーを持っているとします。完全に独立した新しいインストールをすることを決意します。既にあるバンドル(Bundle)ファイルの助けをかりて１つのアークテクチャに対して開始します。CPANはすべてのバンドルをインストールします。しかし2番目のアーキテクチャでその仕事を繰り返そうとすると、CPANはすべてのモジュールに対して"Foo
up to date"というメッセージを返します。そこでCPANのrecompileを２番目のアーキテクチャに呼び出して、行うことができます。
recompileのもう１つのよくある利用法は、perlがバイナリ互換性を壊したときです。もしCPANが使うモジュールがバイナリ互換性に依存していたら（そのためCPANコマンドを実行できなければ）、回復するためにCPAN::Noxモジュールを試してみなければなりません。
これは内部のことと考えられますが、クラス階層はユーザとプログラマの両方に関わりがあります。CPAN.pm上記の４つのクラスを扱い、そしてそれらのすべてがメソッドを共有します。事実上、古典的な１つの多態性です。メタクラス・オブジェクトは全ての種類の全てのオブジェクトを登録し、文字列で索引をつけます。オブジェクトを表す文字列は分けられた名前空間を持ちます（完全には分割されません）：
名前空間 クラス
"/"（スラッシュ）が入った単語 Distribution
Bundle::で始まる文字列 Bundle
その他 Module もしくは Author
Modulesはそれに関連するDistribution オブジェクトを知っています。それらは常に最も新しい公式のリリースを参照します。開発者は（目に見えるバージョン番号にアンダーバーを入れることにより）リリースを安定していない開発バージョンと印をつけることができます。そのため本当に最もホットで新しいディストリビューション・ファイルが常にデフォルトになるわけではありません。もしモジュールFooがCPANで1.23と1.23_90が配布されていれば、CPAN.pmは以下のようにすることによって、バージョン1.23をインストールするような手近な方法を提供します。
. install Foo
これはすべてのものがついた完全なディストリビューション・ファイル（BAR/Foo-1.23.tar.gz)をインストールします。しかしバージョン 1.23_90をインストールしたければ、authors/id/directoryでの相対でCPANでのどこにディストリビューション・ファイルがあるかを知る必要があります。もし作者(author)がBARならば、これはBAR/Foo-1.23_90.tar.zかもしれません。そうしたら以下のようにします
install BAR/Foo-1.23_90.tar.gz
最初の例はCPAN::Moduleクラスのオブジェクトによって行われ、2番目はCPAN::Distributionクラスのオブジェクトによって行われます。
シェルに入らなければ、利用可能なシェルコマンドはメソッドとしても（CPAN::Shell->install(...))、そして呼出しパッケージの中での関数としても(install(...))使うことができます。
現在のところ、たった1つだけ−CPAN::Shellが安定したインターフェースを持っています。CPANシェルで利用できるすべてのコマンドはCPAN::Shellのメソッドです。モジュールの一覧を作成するコマンド（r、autobundle、u)のそれぞれも、リストのなかのすべてのモジュールのIDのリストを返します。
# ディスク上にある古くなったすべてのものをインストールする：
perl -MCPAN -e 'CPAN::Shell->install(CPAN::Shell->r)'
# 必要であれば好きなプログラムをインストールする
for $mod (qw(Net::FTP MD5 Data::Dumper)){
my $obj = CPAN::Shell->expand('Module',$mod);
$obj->install;
}
# ディスク上にあるVERSION番号を持っていないすべてのモジュールの一覧を出力
for $mod (CPAN::Shell->expand("Module","/./")){
next unless $mod->inst_file;
# MakeMaker convention for undefined $VERSION:
next unless $mod->inst_version eq "undef";
print "No VERSION in ", $mod->id, "\n";
}
# CPAN上であるモジュールが入っているディストリビューションを探す：
print CPAN::Shell->expand("Module","Apache::Constants")->cpan_file
またはCPANを見るようなcronジョブを書きたければ、更新する必要があるすべてのモジュールの一覧を出すことができます。最初に早くて汚い方法：
perl -e 'use CPAN; CPAN::Shell->r;'
すべてのモジュールが最新であれば、何も出力を取得したくなければ、上記のコマンドの出力を正規表現//modules are up to date// で解析し、マッチしなかった場合だけ出力をメールするように決めることができます。
もし１つの処理でよりプログラマ的な方法でそれをしたければ、以下のようにすることができます：
# ディスク上からCPAN上により新しいバージョンがあるすべてのモジュールの一覧
for $mod (CPAN::Shell->expand("Module","/./")){
next unless $mod->inst_file;
next if $mod->uptodate;
printf "Module %s is installed as %s, could be updated to %s from CPAN\n",
$mod->id, $mod->inst_version, $mod->cpan_version;
}
もし毎日あまりにも多くの出力をだすのであれば、３つのモジュールだけにしたいかもしれません。１行目を以下のように書くことができます。
for $mod (CPAN::Shell->expand("Module","/Apache|LWP|CGI/")){
もしくは上記のいくつかの方法を組み合わせることができます：
# 新しいmod_perlモジュールだけを見る
$mod = CPAN::Shell->expand("Module","mod_perl");
exit if $mod->uptodate;
# 新しいmod_perl が届いたら、すべての更新のすすめを教えて
CPAN::Shell->r;
現在はキャッシュ・マネージャはbuildディレクトリ($CPAN::Config->{build_dir})だけを追跡します。そこにあるすべてのディレクトリの大きさが$CPAN::Config->{build_cache} (MB単位)よりも大きくなったら、.build_dirの下にあるディレクトリを削除するのは、単純なFIFO機構です。このキャッシュの内容は後から手動で行おうとする再インストールのために使われるかもしれませんが、CPANそのものからはまったく信用されません。これはユーザがこれらのディレクトリを異なるアーキテクチャでのモジュールの構築のために使うことができるためです。
元のディストリビューション・ファイルが保管される他のディレクトリ($CPAN::Config->{keep_source_where})があります。このディレクトリはキャッシュ・マネージャによってカバーされていません。そしてユーザによって制御されなければなりません。もしbuild_dirとkeep_source_whereに同じディレクトリを選択すれば、同じFIFO機能でソースも削除されます。
Bundleは何も関数やメソッドを定義しない単なる名前空間Bundle::のperlモジュールです。それには通常ドキュメントだけが入っています。
それはperlモジュールのようにpackage宣言と$VERSION変数から始まります。その後、podセクションは他のpodと同じように見えます。唯一の違いは、（逐語的に）以下のように始まる1つの特別なpodセクション（one special pod section ）があることです：
=head1 CONTENTS
このpodセクションの各行は以下のフォーマットに従います。
モジュール名 [バージョン文字列] [- オプションのテキスト]
唯一必須の部分は最初のフィールド、モジュール名です（例えば Foo::Bar つまり ディストリビューション・ファイル名ではありません）。行の残りはオプションです。コメント部分は、manページ・ヘッダと同じようにダッシュで区切られます。
bundleのディストリビューションは他のディストリビューションと同じ書き方に従います。
BundlesはCPANパッケージの中では特別に扱われます。もし"install Bundle::Tkkit"とすると（そのようなBundleがあるものとします）CPANはpodのCONTENTSセクションでのすべてのモジュールをインストールします。 @INCパスのどこかに同じ構造のBundleファイルを置くことによりローカルに独自のBundleをインストールすることができます。シェル・インタフェースで利用できるautobundle()コマンドはスナップショット・バンドル・ファイルに現在インストールされているすべてのモジュールが入れることによりそれをおこないます。
もしローカルなCPANミラーを持っていて、"file:" URLですべてのファイルにアクセスすることができるのであれば、このモジュールを実行するにはperl5.003よりも新しいperlであることだけが必要です。そうでなければNet::FTPが強く推奨されます。LWPはUNIXではないシステムあるいは最も近いCPANサイトがftp:ではないURLに関連付けられていれば、必要かもしれません。
もしNet::FTPもLWPも持っていなければ、頼みの綱として外部ftpコマンドまたは外部lynxコマンドのための機能が実装されています。
このモジュールはCPAN上のすべてのモジュールが以下のようであるものと考えます
perl -MExtUtils::MakeMaker -le \
'print MM->parse_version(shift)' filename
もしパッケージの作者で、$VERSIONが解析されるか心配であれば上記の方法を試してみてください。
このモジュールのデバッグはちょっと複雑です。というのもCPAN上の索引を作成するプログラム、CPANのミラー化処理、パッケージ化、構成設定、 同時性、そしてCPAN.pmの中のバグの干渉を受けるからです。
対話モードでのデバッグでは、"o debug"を試すことができます。これはコードのさまざまな部分をデバッグするためのオプションの一覧を出します。"o debug"が組み込の完了サポートを持っていることも知っておくべきです。
データ・デバッグでは、make/test/installと同じ引数をとり、オブジェクトのData::Dumperダンプを出力するdumpコマンドがあります。
CPAN.pmはネットワークなしでもうまく動きます。まったくネットワークにつながっていないマシンを管理しているのであれば、file: URLで動かすことを考えなければなりません。もちろん先にどこかでモジュールを集めてくる必要があります。そこでネットワークにつながったマシーンに必要とするすべてを置くためにCPAN.pmかもしれません。そしてフロッピーの$CPAN::Config->{keep_source_where} ($CPAN::Config->{build_dir}でななく) にコピーします。このフロッピーは個人的なCPANの一種です。ネットワークにつながっていないマシンでのCPAN.pmは、このフロッピーでうまく動きます。以下のCD-ROMサポートについてパラグラフもご覧ください。
CPANモジュールがインストールされると、サイト全体で利用される構成設定ファイルがCPAN/Config.pmとして作成されます。ここで定義されているデフォルト値は他の構成設定ファイル:CPAN/MyConfig.pmで上書きすることができます。そうしたければ、このファイルを$HOME/.cpan/CPAN/MyConfig.pmに格納することができます。というのも$HOME/.cpanはuse()またはrequire()ステートメントの前にCPANモジュールの検索パスに追加されるからです。
現在、ハッシュ・リファレンス $CPAN::Configでは以下のキーが定義されています：
build_cache モジュールをビルドするためのディレクトリのためのキャシュの大きさ
build_dir モジュールをビルドするためにローカルにアクセスできるディレクトリ
index_expire 何日後にインデックス・ファイルを再取得するか
cache_metadata メタデーエタをキャシュするためにシリアライザを使う
cpan_home このパッケージのために予約されているローカルなディレクトリ
dontload_hash 無名ハッシュ： そのキーのモジュールはCPAN::has_inst()ルーチンで
ロードされない
gzip 外部プログラムgzipの場所
inactivity_timeout 動かなくなってから何秒後に対話的なMakefile.PLをブレークするか
0にするとブレークしない。
inhibit_startup_message
もしtrueなら、起動メッセージを表示しない
keep_source_where ソースが保管されるディレクトリ（もしそうすれば）
make 外部のmakeプログラムの場所
make_arg 'make'に常に渡される引数
make_install_arg 'make install'に渡される引数
makepl_arg 'perl Makefile.PL'に渡される引数
pager 外部プログラムmore（または他のページャー）の場所
prerequisites_policy
モジュールの前提条件を満たしていないときにどうするか
('follow' 自動的に従うか, 'ask' 尋ねる, もしくは 'ignore' 無視)
scan_cache キャッシュの検索を制御('atstart'(開始時点) または 'never')
tar 外部プログラムtarの場所
unzip 外部プログラムunzipの場所
urllist 近くのCPANサイト（または同等の場所）への配列リファレンス
wait_list 試してみるwaitサーバの配列リファレンス（CPAN::WAITをご覧ください）
ftp_proxy, } 構成設定のための３つの通常の変数
http_proxy, } プロキシー要求。 CPAN::Config 変数として、そして設定可能な
no_proxy } 環境変数として
o conf コマンドで定義されているコマンド・セットでCPANシェルのなかで対話的にこれらのオプションを設定あるいは問い合わせることができます。
urllist パラメータはRFC 1738に従ったURLです。もしURLが準じていなければどうなるかよくわかりません。しかしファイルURLで問題があるのであれば、正しいフォーマットを試してみてください：
file://localhost/whatever/ftp/pub/CPAN/
もしくは
file:///home/ftp/pub/CPAN/
構成テーブルでのurllistパラメータにはダウンロードのために使われるURLのリストが入ります。もしリストにfile URLがあると、CPANは常にまずそこからファイルを取得しようとします。これはインデックス・ファイルには使うことができません。そのためCPANの内容が入ったCD-ROMを持っている人に推奨されることは、ローカルの、古くなっているかもしれないCD-ROMをurllistの最後にfile URLとしていれることです。例えば以下のように：
o conf urllist push file://localhost/CDROM/CPAN
CPAN.pmはそうすれば、urllistの先頭にあるCPANサイトからインデックス・ファイルを取り出します。後でそれは、最も新しいバージョンがローカルにあるかをチェックします。
もう１つのurllistの特徴は最後にファイルを正常に取得できたサイトが自動的に優先され、次の要求での最初のサイトとして試されることです。そのため実行時に新しいサイトを追加すると、前に優先されたサイトが他のときに最初に試されるかもしれません。次の転送であるサイトを使いたくなければ、urllistから明示的に削除しなければならないことになります
CPAN.pmでは強いセキュリティ・レイヤはありません。CPAN.pmは外からの、マスクされていない、署名されていないコードをあなたのマシンにインストールするのを手助けします。ネットから来たチェックサムとディストリビューション・ファイルそのものとを比較します。だれかがディストリビューション・ファイルをうまいこといじったら、CHECKSUMSファイルもいじってしまったかもしれません。将来の開発では強い認証を目指します。
パッケージCPANの中のほとんどの関数はデフォルトでエクスポートされます。これは基本的な使用法がcpanシェルまたはワンライナーを指向しているからです。
私の好きなモジュールを新しくインストールされたperlに移植することは、プライベートなbundel定義ファイルを保持することによりとても簡単です。便利なbundl定義ファイルの青写真を取得するために、コマンドautobundleをCPANシェル・コマンド行で使うことができます。このコマンドは現在実行されているperlインタープリターのためにインストールされているすべてのモジュールのためのbundle定義ファイルをかき出します。このコマンドは一度だけ実行し、それから後はそのファイルを手動でプライベートな名前 Bundle/my_bundle.pmで保持することが推奨されます。上手なbundleファイルでは、単に以下のようにするだけです
cpan> install Bundle::my_bundle
後はちょっとした質問に答えたら、コーヒーをのみに出かけましょう。
bundle定義ファイルを保持することは、２つのことを追跡することになります：依存性と相互関係です。CPAN.pmはときどき依存性を計りかねることがあります。というのもすべてのモジュールがすべてのMakeMaker属性を正しく定義するというわけではなく、そのためbunlde定義ファイルができるだけ早く前提条件を指定しなければならないためです。
一方、多くのディストリビューションはときどき対話的な設定を必要とするのはちょっと面倒です。プライベートなbundleファイルでやろうとしていることは、設定されることを必要とするパッケージを先に、静かなものを後にファイルに持ち、そのため２、３分たったら出かけて、CPAN.pmをほっておくようにしようとしています。
perlとさまざまなファイヤウォール構成との間の相互作用についての以下のパラグラフを寄稿してくれたGraham Barrに感謝します。ファイヤ・ウォ−ルについてのさらなる情報はncftpプログラムについてくるドキュメントにあたることをお勧めします。簡単なperl設定ではファイヤ・ウォールを通せないのであれば、それがあなたのファイヤ・ウォールでも機能するようにncftpを設定するようになることになるでしょう。
ファイヤウォールは以下の３つの基本型に分類することができます。
perlで、これらのタイプのファイヤウォールの外側にあるサーバーにアクセスするためには（ftpのためであっても）LWPを使う必要があります。
perlで、これらのタイプのファイヤウォールの外側にあるサーバーにアクセスするためにはNet::FTPを使う必要があります。
例えばlynxでおそらく以下のようなコマンドでファイヤ・ウォールを通ることができるのであれば、
/usr/local/bin/lynx -pscott:tiger
CPAN.pmを以下のようなコマンドで設定します。
o conf lynx "/usr/local/bin/lynx -pscott:tiger"
それだけです。ncftpやftpでも同じように、以下のようにします
o conf ncftp "/usr/bin/ncftp -f /home/scott/ncftplogin.cfg"
あなたの道のりは違うかもしれません...
本当に古いバージョンがインストールされている可能性が高いです。モジュールを前にインストールしたのとは別の@INCパスにあるディレクトリにインストールした場合におこります。これは本当はCPAN.pmの問題ではなく、手動でそのモジュールをインストールしても同じ問題になるかもしれません。この動きを阻止する簡単な方法は、make install呼出しに引数 UNINST=1を追加することで、多くの人が設定することによりこの引数を永続的追加します。
o conf make_install_arg UNINST=1
だれが@INCパスのどこにインストールしたのか、そしてだれがどこの@INCを使っているのかについての完全な予測をしている人がいるからです。良くチューニングされた環境ではUNIST=1がダメージを与えてしまうかもしれません。
古いperlでautobundleコマンドを実行し、結果のbundleファイルを適切に名前を変え（例えば Bundle/mybundle.pm）、新しいperlをConfigure にprefixオプションをつけてインストールします。例えば
./Configure -Dprefix=/usr/local/perl-5.6.78.9
最初の段階で作成したbundleファイルを以下のようにしてインストールします
cpan> install Bundle::mybundle
これで終わりです
以下のように設定することができます
o conf make_arg "| tee -ai /root/.cpan/logs/make.out" o conf make_install_arg "| tee -ai /root/.cpan/logs/make_install.out"
こうするとSTDOUTは後から見ることができるようにファイルに出力されます
一番ありそうな方法は以下のようにすることです
o conf makepl_arg "LIB=~/myperl/lib \
INSTALLMAN1DIR=~/myperl/man/man1 \
INSTALLMAN3DIR=~/myperl/man/man3"
install Sybase::Sybperl
この設定をo conf 設定、o conf
commitとすることで永続化させることができます。
~/myperl/man をMANPATH環境変数に追加するようがあるかもしれません。また同様に/myperl/libを見るようにperlプログラムにするために、例えば以下の行を追加する
use lib "$ENV{HOME}/myperl/lib";
もしくはPERL5LIB環境変数を設定する必要があるかもしれません。
もう１つ気をつけなければならないことは、rootでなければUNINSTパラメータを設定してはならないことです。
Sybase::Sybperlをご覧ください
これは開始時点では、CPANはすべてのモジュールの依存関係を知らないためです。インストールする追加のアイテムについて判断するためには、作成されたMakefileで見つかったデータを使うだけです。いわれなかった失われたピースは処理を中断します。しかしそれはBundleがいくつかの依存する要素の後にその前提条件となるものをインストールするかもしれず、そのため2度目の挑戦ではすべてが解決することがあります。CPAN.pmは先に依存関係のツリーを知らないということ、そしてトポロジカルに正しい順序でインストールするために物事の順序を並べ直すことはできなということに注意してください。すべてのモジュールが前提条件となるものをMakeMakerへのPREREQ_PM属性を正しく宣言していれば、正しく解決できます。Bundleについてはもし失敗し、なんどもインストールする必要があれば、Bundle定義を手で並べ直すことをお勧めします。CPANでの一般的な依存関係についてのメタデータの条件は改善する予定ですが、それにはまだ時間がかかります。
CPAN::Siteモジュールをご覧ください
私に言えることは/etc/inputrcはTerm::ReadLineに何らかの関係があります。おそらく/etc/inputrcを削除するかまたはINPUTRC環境変数を設定するだけです（readlineドキュメントをご覧ください）
われわれはPAUSE部分だけでなく、CPANの全てをカバーすべきではないでしょうか？この議論では、CPANとPAUSEは既に同じになりましたか−しかしそうではありません。PAUSEはauthors/, modules/ そして scripts/です。CPANはPAUSEに加えて、clpa/, doc/, misc/, ports/,そして src/です。
将来の開発では、さらに他の部分の統合を目指します。
もしMakefile.PLがライブラリ、特別な入力のためのプロンプトなどの特別なカスタマイズを必要としていると、CPANがそのディストリビューションを構築できないことがあるかもしれません。その場合には、シェルからＰｅｒｌモジュール・パッケージを構築する伝統的な方法を試さなければなりません。
Andreas Koenig <andreas.koenig@anima.de>
perl(1), CPAN::Nox(3)
ご意見、ご質問はこちらの掲示板で受け付けています。
またメールは河馬屋(Nifty)にお願いします。