読者です 読者をやめる 読者になる 読者になる

kopug memo

名古屋で働くとあるWebエンジニアの覚書。

CPANモジュールをどう管理するか

Linux Perl

長々がんばって書いたんだけど2回クラッシュして消えてしまった。
いい加減反省してエディタで書いてからコピペすることに。orz

先日の日記にRPMで管理できるものは管理したほうが依存関係の解決や、
その他のトラブルに巻き込まれにくくなるみたいな事を書いたんだけど、
最近気にしているのはCPANモジュールをどう管理するかについて。

考えられる事例はこんな感じ。

  1. Perl Hackをしていて、Hoge::OTL(v1.0)をCPANコマンドからインストール
  2. 1のApplicationではHoge::OTL(v1.0)以上しかサポートされていないメソッドとか使ってる
  3. とあるパッケージをyumでインストール。そのパッケージはHoge::OTLに依存しているので、Hoge::OTLもRPMで追加インストールされる

yumリポジトリにあるのは基本的には安定版で、バージョンが古いことが多いので、古いバージョンで上書きされてしまいます。
(もちろん最新版ばっかを集めてあるリポジトリもありますが、ここでは除外しておきます。)

Hoge::OTL(v1.0)をcpan2rpmとかでRPM化してインストールしてさえすれば、
yumを使っているので、依存パッケージは既にインストール済みと判断され、上書きされませんでした。

先日 Development Environment Conferenceというのがあり、
そこでid:miyagawaさんの「Vox/Plaggerの裏側見せます」の発表でCPANモジュールの管理についてもあったようです。

ソフトはCPAN含めてすべてRPM化し、yumリポジトリを立てて配布している。

上記はどこかのサイトでログを見ただけなのですが、
なるほどなと関心してしまった。

Perlで作ったアプリケーションもRPM化してしまい、それらに依存するモジュールもすべてRPMだったら、
yum install MyApplication とかでインストールできてしまいますね。
# ここでまではしなくてもいいと思いますが。

と同時に最初にあげた問題も回避できます。

ただ何を使ってRPM化しているのか分からないのですが、もしcpan2rpmコマンドを使っているのであれば、
あれは依存するモジュールがあった場合、上手にRPM化できなかったような気がするので、
最下層のモジュールまで下っていき、そこからrpm化して最上部まで上がっていく必要があるのかな?

すべてRPM化して管理するというのも一つの解決方法ですが、
1番手軽なのは、作っているアプリケーションにCPANモジュールを含めちゃえばいいんじゃないかなと。

CPANモジュールを共存させるで書いた方法で、
アプリケーション内に含めてsubversionにcommitしておけば、
yumで被るモジュールがあっても、関係なくなりますね。