2011年06月24日　(2011/06/29 00:43 )

perlのTime::Localモジュールがいつのまにかバージョンダウン、原因はyumの自動更新

　カテゴリ : 雑談　タグ :

先日、コミックダッシュ！の一部のプログラムが不具合で動かなくなっていたのを
見つけて調査をしていたのですが、原因はこんなところにありました。
　

Day too big - 29220 > 24855
Cannot handle date (0, 0, 0, 01, 0, 2050) at xxxxx.pl line xxx
　
Time::Local のモジュールが2050年という数字を喰わされてエラーを
吐いています。Time::Localのモジュールには 「2039年問題」 という、
一部の古いバージョンでは処理ができないという問題がありました。
　
しかし、これは前々から分かっていた問題で、そもそもサーバ環境構築の際に
早々に気づいてTime::Localのバージョンを新しくしておいた筈なのですが・・・。

　

use vars qw( $VERSION @ISA @EXPORT @EXPORT_OK );
$VERSION = '1.11';
$VERSION = eval $VERSION;
　
現存している.pmファイルを見るとやはり 1.11に戻って います。
　
何かイヤな予感がして、yumの自動アップデートログを追ってみると、
perl本体のアップデート が発生していました。
　

perl x86_64 4:5.8.8-32.el5_6.3 updates 12 M
　
■Twitter / @hikarine3 Hajime Kurita(栗田創)
http://twitter.com/#!/hikarine3/status/3525740968546304
今更ながらyumのperlアップデートでTime::Localのバージョン下げ起きてしまってた事分かり修正。Time::Localは標準モジュールだけどバージョンアップが必須 http://j.mp/ddGxfj Encodeもだけどおかげでperlにyum update使えない
　
まさにこれですね・・・こんな盲点があろうとは。
　
perlの標準モジュールに含まれているものは、自前でアップデートをしても、
次の自動アップデートのときに 古いものに上書きされて しまう危険性がある、
というワケです。これにはちょっと頭を抱えました。
　
とりあえず、
　

perl -e 'use Time::Local;print $Time::Local::VERSION."\n";'
1.2000
　
Time::Localのバージョンは再び上げておいたのですが、これだけではまた
上書きされてしまう可能性がありますので、別のlibディレクトリ を作っておいて、
プログラムからは優先的にそちらを読ませるように設定しておきました。
そのかわり今度は逆に、perl本体の標準モジュールに含まれるTime::Localが
本当にバージョンアップしたらそれに気づかない可能性も出てきてしまうわけですが・・・。
　
yumで自動アップデートを掛けているとこういうことが起こりえるということで、
今回は良い教訓になりました。とはいえ、自動アップデートを掛けるリスクと
掛けないリスクを天秤に掛ければ、やらないという選択肢はありえないわけで、
今後もこうした問題とは上手くつきあっていかなければならなくなりそうです。。。