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

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

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 は、インストール時、アップグレード時、アンインストール時、それぞれで違う動作をさせるためのものです。Chapter 9, 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 の行の次の行は、空行にしておかないとエラーとなるようです。

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