パッケージ固有の作法等について

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タグの部分で

    %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
    
    のように処理します。 update-desktop-database コマンドがインストールされていなければ実行しない、という形にすることで、twm や icewm や WindowMaker など、GNOME等のメニューとは直接関係ないウィンドウマネージャを使用しているときに、deskto-file-utils に依存せずにすむようになります。

  • 他のファイルと同じように %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をインストールします。

    %_installemacsenscript %{name} %{SOURCE2}
    
    %_removeemacsenscript  %{name} %{SOURCE3}
    
    
    スクリプトA,B はそれぞれ /usr/lib/emacsen-common/packages/install/ , /usr/lib/emacsen-common/packages/remove/ に、 %{name} という名前でインストールされます。 これによって、スクリプトA,B は、Emacs の FLAVOR がインストール、アンインストールされた時に実行されるようになります。

    %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ライブラリを収録しない

Vine Linuxでは従来、staticライブラリ(*.a)を-develサブパッケージに収録していました。しかし、以下の理由から今後は原則としてstaticライブラリをパッケージに収録しないこととします。

  • あるライブラリにバグ、セキュリティホールなどが発見された場合にそれをリンクしているパッケージを追跡することが難しい
  • staticリンクした場合、ライブラリの問題でアプリケーション全体の再ビルドが必要となる

ただし、明確な理由によりstaticライブラリを必要とする場合は、メインパッケージや -devel サブパッケージに収録するのではなく、-static サブパッケージを作成して収録してください。

III.13.5.2. libtoolライブラリを収録しない

従来、一部のパッケージで Libtool で使われる .la ファイル (ライブラリアーカイブ、擬似ライブラリ)がパッケージに収録されていました。しかし、以下の理由から今後は原則としてパッケージには収録しないこととします。

  • Linux などの場合では .la ファイルを使わずとも .so に情報が内包されているため、.la ファイルは必要ではない
  • 間違った情報がはいっていることもあり、それが原因で問題がおこる場合がある
  • .la があったりなかったりという状態が混在すると、ライブラリを見つけられない場合が発生する