パッケージ固有の作法等について
- III.13.1. GNOME,KDE,Xfce のメニューに追加するために
- III.13.2. Emacs Lisp のパッケージ
- III.13.3. alternatives を利用するパッケージ
- III.13.4. GConf2を利用するパッケージ
- III.13.5. ライブラリのパッケージングポリシー
III.13.1. GNOME,KDE,Xfce のメニューに追加するために
GNOME,KDE,Xfce のメニューに追加するためには、ディレクトリ/usr/share/applicationsに アプリケーションの名前.desktop というファイル(以降 desktopファイルと呼びます)をインストールする必要があります。
desktopファイルを取り扱う desktop-file-installコマンド、desktop-file-validateコマンド、update-desktop-databaseコマンドは、desktop-file-utilsというパッケージに含まれています。
desktopファイルの扱いは次のような手順になります。
%installタグの部分で次のようにして desktopファイルを%{buildroot}/%{_datadir}/applicationsにインストールしておきます。
%install %{__mkdir_p} %{buildroot}/%{_datadir}/applications %{_bindir}/desktop-file-install --dir=%{buildroot}/%{_datadir}/applications hoge.desktop
-
%checkタグの部分で次のようにして desktopファイルが書式にしたがって正しく書かれているかをチェックします。
%check %{_bindir}/desktop-file-validate %{buildroot}/%{_datadir}/applications/hoge.desktop
ソースから make する、make install するなどの部分ではこのチェックが行われないことも多いので、%checkタグの部分でチェックを行うようにしておきます。
desktop-file-validateコマンドは複数のファイルをまとめて処理できないので、*.desktop のようにはできません。desktopファイルの数だけ、コマンドを書いてください。もちろん、for文などを使ってもかまいません。
%postタグや%postunタグの部分で
のように処理します。 update-desktop-database コマンドがインストールされていなければ実行しない、という形にすることで、twm や icewm や WindowMaker など、GNOME等のメニューとは直接関係ないウィンドウマネージャを使用しているときに、deskto-file-utils に依存せずにすむようになります。%post if [ -x %{_bindir}/update-desktop-database ] ; then %{_bindir}/update-desktop-database %{_datadir}/applications fi %postun if [ -x %{_bindir}/update-desktop-database ] ; then %{_bindir}/update-desktop-database %{_datadir}/applications fi
他のファイルと同じように %filesの部分に入れておきます。
%files %{_datadir}/applications/hoge.desktop
BuildRequires で desktop-file-utils を指定します。
BuildRequires(install,check): desktop-file-utils
III.13.2. Emacs Lisp のパッケージ
Emacsen には emacsen-common というパッケージがあり、 インストールされている Emacsen の FLAVOR の情報や、 FLAVOR ごとに、その FLAVOR で byte compile された Emacs Lisp パッケージのリストを管理するという仕組みがあります。
この仕組みを用いることで以下のようなことが可能となっています。
- パッケージのインストール時に、すでにインストールされている Emacsen の FLAVOR ごとにそれぞれ byte compile して elc ファイルを作成する。
- パッケージのアンインストール時に、すべての FLAVOR からパッケージの elc ファイルを削除する。
- Emacsen の FLAVOR のインストール時、アンインストール時に、その FLAVOR で byte compile する、FLAVOR で byte compile した elc を削除する。
この仕組みを利用するために、Emacs Lisp のパッケージでは以下のようなことをしておきます。
%installタグの部分では byte compile していない el ファイルを %{_datadir}/emacs/site-lisp/%{name} 以下にインストールします。
Source2 や Source3 などに byte-compile と install を行うためのスクリプトAと、 byte-compile してできた elc ファイルを削除するためのスクリプトBを用意します。 インストールに使える Makefile 等がある場合は %installタグの部分で %{_datadir}/emacs/site-lisp/%{name} 以下に Makefile 等をインストールしておき、 スクリプトの中から利用できるようにします。
install 用のスクリプトAでは、 Emacsen の FLAVOR に応じて %{_datadir}/FLAVOR/site-list/%{name}/ 以下に bytecompile した elc ファイルをインストールするようにします。
uninstall 用のスクリプトBでは、 Emacsen の FLAVOR に応じてスクリプトAでインストールした elc ファイルを削除するようにしておきます。
-
%installタグの部分で次のようにして、スクリプトAとスクリプトBをインストールします。
スクリプトA,B はそれぞれ /usr/lib/emacsen-common/packages/install/ , /usr/lib/emacsen-common/packages/remove/ に、 %{name} という名前でインストールされます。 これによって、スクリプトA,B は、Emacs の FLAVOR がインストール、アンインストールされた時に実行されるようになります。%_installemacsenscript %{name} %{SOURCE2} %_removeemacsenscript %{name} %{SOURCE3}
%files の部分でそれぞれのスクリプトを記述しておきます。
%{_libdir}/emacsen-common/packages/install/%{name} %{_libdir}/emacsen-common/packages/remove/%{name}
-
%postタグの部分は次のように記述しておきます。 if [ "$1" = 数字 ]; then ; fi は、インストール時、アップグレード時、アンインストール時、それぞれで違う動作をさせるためのものです。付録 A - RPMパッケージをつくるときの注意を参照してください。
%post # # bytecompile and install # if [ "$1" = 2 ]; then %_emacsenPackageRemove %{name} fi %_addemacsenlist %{name} %_emacsenPackageInstall %{name} %preun if [ "$1" = 0 ]; then %_emacsenPackageRemove %{name} %_removeemacsenlist %{name} fi
%_emacsenPackageInstall と %_emacsenPackageRemove は スクリプトA,B を実行するためのマクロです。
%_addemacsenlist と %_removeemacsenlist は、インストール済み Emacs Lisp パッケージのリストにパッケージを登録する、削除するというマクロです。
%_installemacsenscript, %_removeemacsenscript, %_emacsenPackageRemove, %_addemacsenlist, %_removeemacsenlist の行の次の行は、空行にしておかないとエラーとなるようです。
III.13.3. alternatives を利用するパッケージ
alternatives については update-alternatives による標準コマンドの切り替え にまとめられています。
alternatives に登録する場合には %post と %preun で次のようにします。
%post if [ "$1" = "1" ]; then %{_syssbindir}/update-alternatives --install リンク名 総称名 選択候補 優先度 fi %preun if [ "$1" = "0" ]; then %{_syssbindir}/update-alternatives --remove 総称名 選択候補 fi
Provides と Requires を指定します。
Provides: 総称名 リンク名 Requires: update-alternatives Requires(post,preun): %{_syssbindir}/update-alternatives
Provides の リンク名 については、無くても問題はありませんが、%files には書かれないファイルなので、Provides に書いておいたほうがよいと思います。
%post での登録と %preun での削除は、インストール時とアンインストール時だけに必要で、アップグレード時に実行してしまうと問題があるので、"$1" が 1 の場合(インストール時)と 0 の場合(アンインストール時)だけ処理するように if 文 にしておきます。
%post での処理を、パッケージのアップグレード時にも行ってしまうと、パッケージのインストール後にユーザが優先度を変更していた場合、それを無視してパッケージ側で優先度を勝手に変更してしまうことになります。
新規パッケージではなく、既存のパッケージの %post,%preun に update-alternatives の処理を追加する場合には、次のようにするとよいかもしれません。
%post if [ "$1" = "1" ]; then if [ "`%{_sysbindir/update-alternatives --list '総称名' | grep -c 'リンク名'`" = "0" ]; then %{_syssbindir}/update-alternatives --install リンク名 総称名 選択候補 優先度 fi fi %preun if [ "$1" = "0" ]; then %{_syssbindir}/update-alternatives --remove 総称名 選択候補 fi
%triggerin と %triggerpreun と %preun を用いることで、他のパッケージが持っているファイルを alternatives で登録するようなパッケージを作ることもできます。
Provides: 総称名 リンク名 Requires: update-alternatives Requires(preun,triggerin,triggerpreun): %{_syssbindir}/update-alternatives %preun if [ "$1" = "0" ]; then %{_syssbindir}/update-alternatives --remove-all 総称名 fi %triggerin -- 対象となるパッケージ if [ "$1" = "1" ]; then echo triggerin scriptlet by %{name} start %{_syssbindir}/update-alternatives --install リンク名 総称名 選択候補 優先度 echo triggerin scriptlet by %{name} end fi %triggerpreun -- 対象となるパッケージ if [ "$1" = "0" ]; then echo triggerpreun scriptlet by %{name} start %{_syssbindir}/update-alternatives --remove 総称名 選択候補 echo triggerin scriptlet by %{name} end fi
III.13.4. GConf2を利用するパッケージ
GConf2を設定の保存に利用しているアプリケーションの場合、通常、make installの途中でデフォルトの設定値が記述されたファイルをGConf2に登録しようとします。
しかし、このタイミングでGConf2への登録を行うとRPMパッケージ化の際にエラーを吐きますし、RPMパッケージをインストールしてもGConf2には何も登録されません。
この様なアプリケーションをパッケージ化する場合は、以下のようにSPECファイルを記述してGConf2への登録のタイミングを制御する必要があります。
-
%installセクションのmake installの前後を以下のように記述します。
export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 make install unset GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL
これでmake install時にGConf2への登録が省略されます。
-
%postセクションに以下の記述を追加します。
export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-install-rule %{_sysconfdir}/gconf/schemas/package.schemas > /dev/null
packageの部分は、適切な名前(ワイルドカード使用可)に置き換えてください。
-
%preunセクションに以下の記述を追加します。
if [ $1 = 0 ]; then export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source` gconftool-2 --makefile-uninstall-rule %{_sysconfdir}/gconf/schemas/package.schemas > /dev/null fi
これは、削除される前の .schemas ファイルを利用しますので%postunセクションでは駄目です。
III.13.5. ライブラリのパッケージングポリシー
- III.13.5.1. staticライブラリを収録しない
- III.13.5.2. libtoolライブラリを収録しない
III.13.5.1. staticライブラリを収録しない
Vine Linuxでは従来、staticライブラリ(*.a)を-develサブパッケージに収録していました。しかし、以下の理由から今後は原則としてstaticライブラリをパッケージに収録しないこととします。
- あるライブラリにバグ、セキュリティホールなどが発見された場合にそれをリンクしているパッケージを追跡することが難しい
- staticリンクした場合、ライブラリの問題でアプリケーション全体の再ビルドが必要となる
ただし、明確な理由によりstaticライブラリを必要とする場合は、メインパッケージや -devel サブパッケージに収録するのではなく、-static サブパッケージを作成して収録してください。
III.13.5.2. libtoolライブラリを収録しない
従来、一部のパッケージで Libtool で使われる .la ファイル (ライブラリアーカイブ、擬似ライブラリ)がパッケージに収録されていました。しかし、以下の理由から今後は原則としてパッケージには収録しないこととします。
- Linux などの場合では .la ファイルを使わずとも .so に情報が内包されているため、.la ファイルは必要ではない
- 間違った情報がはいっていることもあり、それが原因で問題がおこる場合がある
- .la があったりなかったりという状態が混在すると、ライブラリを見つけられない場合が発生する