Perl モジュールの rpm パッケージ化の注意点

(  VineSeed ML 024756 を参照のこと )

背景

従来は、x86_64 環境で noarch パッケージを build すると、モジュールファイルが /usr/lib64 以下にインストールされてしまい、ix86 環境では利用できないパッケージができてしまう。逆に ix86 環境で build された noarch パッケージは、x86_64 環境でも利用可能。

そこで、perl-5.12.3-5 (VineSeed, Vine-6/proposed-updates) より、以下の通り定義を変更した。

x86_64: sitelib, vendorlib の prefix を /usr/lib に

$ perl -V:installsitelib
installsitelib='/usr/lib/perl5/site_perl/5.12.3';
$ perl -V:installsitearch
installsitearch='/usr/lib64/perl5/site_perl/5.12.3/x86_64-linux-thread-multi';
$ perl -V:installvendorlib
installvendorlib='/usr/lib/perl5/vendor_perl/5.12.3';
$ perl -V:installvendorarch
installvendorarch='/usr/lib64/perl5/vendor_perl/5.12.3/x86_64-linux-thread-multi';

ix86: 従来と同じ

$ perl -V:installsitelib
installsitelib='/usr/lib/perl5/site_perl/5.12.3';
$ perl -V:installsitearch
installsitearch='/usr/lib/perl5/site_perl/5.12.3/i386-linux-thread-multi';
$ perl -V:installvendorlib
installvendorlib='/usr/lib/perl5/vendor_perl/5.12.3';
$ perl -V:installvendorarch
installvendorarch='/usr/lib/perl5/vendor_perl/5.12.3/i386-linux-thread-multi';

この作業の際、現在リポジトリにある Perl Module パッケージの spec をみてみると、 意外と統一感のない状態であったので、ここにメモをまとめる。

パッケージングの際の注意点

原則として sitelib, sitearch は使わない方向で

例 (1)：

%build
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="%{optflags}"
make %{?_smp_mflags}

%install
rm -rf %{buildroot}
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} +
find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;

例 (2)：

%build
%{__perl} Build.PL installdirs=vendor optimize="%{optflags}"
./Build

%install
rm -rf %{buildroot}
./Build install destdir=%{buildroot} create_packlist=0
find %{buildroot} -type f -name '*.bs' -size 0 -exec rm -f {} \;
find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null \;

noarch は vendorlib へ

noarch な Perl Module パッケージは、vendorlib (%{perl_vendorlib}) に入る。

%files
...
%{perl_vendorlib}/Fuga/Fuga.pm
...

arch dependent は vendorarch へ

バイナリや so モジュールを含むなど arch dependent な Perl Module パッケージの場合は vendorarch (%{perl_vendorarch}) に入る。

%files
...
%{perl_vendorarch}/auto/*
%{perl_vendorarch}/Hoge/Hoge.pm
...

極力テストを通す

%check
make test (あるいは ./Build test)

テストに必要な他モジュールは BuildRequires? にモジュール名で追加

provides/requires のフィルタリングを適切に

主にプライベートモジュールが不用意に Provides / Requires に現れないように provides/requires フィルタリングを行う。

その他の例としては、Perl モジュールを内包する（が、他のプログラムからの利用を考えていないパスに格納されている）パッケージを作成する場合に、不必要に Provides がついてしまうのを防ぐためにも用いられる。

例えば 0.87.2-1 およびそれ以前の shutter パッケージでは、/usr/share/shutter/resources/modules/ 以下に Perl モジュールが数種類格納されており、Provides されてしまっていた（しかしそれらのモジュールは別パッケージとしてレポジトリに存在していた）。その際、apt-get などであるパッケージをインストールする際、間違えて shutter パッケージが引っ張ってこられてしまうことがあった。

以下、自動検出されパッケージに付加される Provides から perl(DB)、perl(UNIVERSAL) を除去、および perl(Switch で始まるものを全て除去する場合の例。

## 通常 %prep より前に書く

%if "%{_dist_release}" > "vl6"

## VineSeed 用 (rpm >= 4.9)
%global __provides_exclude %{?__provides_exclude:__provides_exclude|}^perl\\((DB|UNIVERSAL)\\)$
%global __provides_exclude %__provides_exclude|^perl\\(Switch

%else

## Vine-6.x 用 (rpm < 4.9)
%global provfilt /bin/sh -c "%{__perl_provides} |\
    grep -Ev '^perl[(](DB|UNIVERSAL)[)]$' |\
    grep -Ev '^perl[(]Switch'"
%define __perl_provides %{provfilt}

%endif