CPAN::Packager 試してみた
CPAN モジュールを Deb/RPM 形式のパッケージ化が簡単にできる、CPAN::Packager を試してみたのでメモ。ちなみに今回は、Debian GNU/Linux 5.0 でやってるので、Deb 形式のみとなります。たぶん、RPM 形式もそんなに大差ないはずです。
CPANモジュールをdebパッケージ化する仕事
以前、一度同じようなエントリCPAN モジュールを deb パッケージ化 - amari3のはてなダイアリーを書いたが、今日あらためて、dh-make-perl を使って deb パッケージ化する際に面倒くさいと思ったこと。
- 自分で依存関係を解決する必要がある
- 依存関係が多いモジュールはその時点でやる気が失せる
- META.yml 等の書き方がちょっと違ったりするだけで失敗する
ということもあり、CPAN::Packager の導入を検討しようと思う。
そういえば、github のアカウント持ってないし、ついでに登録しとこ。
Parse::AccessLogEntry::Accessor
CPAN に Parse::AccessLogEntry::Accessor なるモジュールをアップしました。しかも、CPAN に初アップです!!やったね。なので、モジュールの説明などをちょこちょこと。
使い方はこんな感じ
下のサンプルだと、ホスト名と時間をアクセサを使って取り込んで表示してるだけです。
#!/usr/bin/perl use strict; use warnings; use Parse::AccessLogEntry::Accessor; my $LOGFILE = 'access.log'; my $parser = Parse::AccessLogEntry::Accessor->new; open my $fh, '<', $LOGFILE or die; while (my $line = <$fh>) { chomp $line; $parser->parse($line); print $parser->host(), $parser->time(), "\n"; } close $fh;
個人的に、Parse::AccessLogEntry をよく使ってて、アクセサがあればなと思って作っちゃいました。よければ使っていただいて、意見等いただければと思います。
あとはモジュールの管理をどうするか。CodeRepos にアカウントをもらうのがいい気もします。
CPAN PAUSE アカウント
PAUSE アカウントを申請してから5日くらい経つけど、パスワードが送られてこない。再申請をした方が良いのかしら。
ググったりして調べると、数時間かかってる人もいるみたいやけど、さすがに5日は長すぎないかなぁ。
CPAN::Mini入れてみた
CPANミラーをローカルに作れる、CPAN::Miniを今更ながら入れてみた。めちゃくちゃうれしいところは、こんな感じっすかね。
- 飛行機や地下鉄といったオフラインな所でもCPANモジュールをごりごり入れられる
- ダウンロードする手間が無い分だけインストールも早い
インストールの仕方はめちゃ簡単です。CPANからCPAN::Miniを入れるだけ。
cpan> install CPAN::Mini
インストールに成功すると、minicpanというコマンドが付属してくる。これを使って、CPANミラーをローカルに作ったりします。こんな感じで実行。
% minicpan -r http://ftp.yz.yamagata-u.ac.jp/pub/lang/cpan/ -l ~/minicpan
CPANシェルからインストールするために、urllistに追加しておきます。*1
cpan> o conf urllist unshift file:///home/amari3/minicpan cpan> o conf commit
あとは、cronか何かで一日一回同期しておくと良いです。
ちなみに、初回起動時は30分くらい処理に時間がかかるので注意!
CPAN モジュールを deb パッケージ化
CPAN モジュールを dpkg とか aptitude でインストールできるように deb パッケージ化してみる。
まずは、CPAN モジュールを deb パッケージにするために必要なコマンド、dh-make-perl をインストールする。
# aptitude install dh-make-perl
dh-make-perl の使い方はこんな感じ。--notest オプションを付けるとテストをスキップしてくれますが、個人的にはおすすめ出来ないです。
# dh-make-perl --cpan モジュール名 --build
別に root じゃなくても実行できるけど、一般ユーザだとこけるときもあるので、root で実行するのをおすすめします。
とりあえず例として、Readonly モジュールを deb パッケージ化してみる。
# dh-make-perl --cpan Readonly --build
実行後、成功すると以下のファイルが出来上がるので、dpkg なり aptitude でインストールすることができる。(aptitude でインストールするときは、sign したりする必要がある。ここでは割愛します)
libreadonly-perl_1.03-1_all.deb
依存パッケージがあったりする場合には、--depends オプションを使ってパッケージを指定する。(XML::XPathEngine で説明。特に意図はないです)
# dh-make-perl --cpan XML::XPathEngine --build --depends 'libmodule-install-perl (>= 0.64-1)'
僕が考える、deb パッケージ化するメリットは、
- サーバが Debian の場合インストールするのが容易になる
- 商用で使う場合で問題になりがちな、バージョンの差異をなくすことができる
あと、デメリットも、
- そもそも deb パッケージにするのが面倒くさい
- 依存関係を自動で解決してくれない(自分で --depends オプションを指定する必要有)
メリットの2が個人的には大きいと思いますが、デメリットの2が大きくのしかかってきます。これを自動化できるようなスクリプトを書くと幸せになれるかもと思います。