3.3. syspaths サブパッケージの提供
Software Collection のパッケージを使用するには、ユーザーは従来の RPM パッケージを使用する場合とは異なる特定のタスクを実行する必要があります。たとえば、別の場所にインストールされたバイナリーを見つけるために、
PATH、LD_LIBRARY_PATH などの環境変数を変更する scl enable 呼び出しを使用する必要があります。systemd サービスの代替名を使用する必要もあります。一部のスクリプトは、/usr/bin/mysql など、完全なパスを使用してバイナリーを呼び出すこともできます。その結果、これらのスクリプトは Software Collection で機能しない可能性があります。
上述の問題に対処するための推奨ソリューションは、syspaths サブパッケージを使用することです。基本的な概念は、ユーザーがベースシステムのインストールに影響を及ぼさずに、異なるバージョンの同じパッケージを使用できるようにすることですが、Software Collection パッケージを従来の RPM パッケージであるかのように使用するオプションを使用すると、Software Collection を簡単に使用できるようになります。
オプションの syspaths サブパッケージ (rh-mariadb102-syspaths など) は、標準パス (通常は
/usr/bin) にインストールされるシェルラッパーおよびシンボリックリンクを提供します。つまり、syspaths サブパッケージのインストールを選択すると、ユーザーがベースシステムのインストールを意図的に変更し、一度に複数のバージョンの同じパッケージをインストールし、実行する必要のないユーザーに適した syspaths サブパッケージになります。これは特にデータベースを使用する場合です。
syspaths サブパッケージを使用すると、Software Collection パッケージでスクリプトを調整する必要がなくなり、スクリプトを簡単に使用できるようになります。syspaths サブパッケージは、ベースシステムインストールのパッケージと競合するため、従来のパッケージを syspaths サブパッケージとともにインストールすることはできません。懸念される場合は、コンテナーベースの技術を使用して、ベースシステムのインストールから syspaths サブパッケージを分離することを検討してください。
3.3.1. syspaths サブパッケージの命名
syspaths サブパッケージの概念を使用する各 Software Collection には、通常 syspaths サブパッケージが複数含まれています。syspaths サブパッケージは、ラッパーまたはシンボリックリンクで提供できるファイルとともに、各パッケージで利用できます。
その上には、software_collection_1 という名前の Software Collection メタパッケージがあります。ここで software_collection_1-syspaths、は Software Collection の名前になります。この software_collection_1-syspaths サブパッケージには、Software Collection が含まれる他の syspaths サブパッケージが必要です。これにより、software_collection_1-syspaths サブパッケージをインストールすると、その他の syspaths パッケージがすべてインストールされます。
たとえば、software_collection_1-package_1 パッケージに含まれるバイナリーファイル
binary_1 と、software_collection_1-package_2 パッケージに含まれるバイナリーファイル binary_2 のラッパーを含めたい場合は、software_collection_1 Software Collection に以下の 3 つの syspaths サブパッケージを作成します。
software_collection_1-syspaths software_collection_1-package_1-syspaths software_collection_1-package_2-syspaths
3.3.2. syspaths サブパッケージに含まれるファイル
syspaths サブパッケージに組み込むのに適したファイルは、ユーザーが対話するバイナリーのシェルラッパーです。
以下は、software_collection_1 に含まれるバイナリーファイルの
binary_1 のラッパーの例です。これは、/opt/rh/software_collection_1/root/usr/bin/binary_1 にあります。
#!/bin/bash source scl_source enable software_collection_1 exec "/opt/rh/software_collection_1/root/usr/bin/binary_1" "$@"
/usr/bin/binary_1 にこのラッパーをインストールする場合は、scl enable software_collection_1 を付けなくても binary_1 コマンドを実行できます。/usr/bin/ にインストールされているラッパーは正しい環境を設定し、/opt/provider/%{scl} ファイルシステム階層とともに配置されるターゲットバイナリーを実行します。
3.3.3. syspaths Wrapper の制限
syspaths ラッパーがシェルスクリプトであるため、ユーザーはターゲットバイナリーと同様にラッパーを使用してすべてのタスクを実行できないことを意味します。たとえば、gdb を使用してバイナリーをデバッグする場合、
/opt/provider/%{scl} はラッパーシェルスクリプトでは機能しないため、gdb ファイルシステム階層を指定するフルパスを使用する必要があります。
3.3.4. syspaths サブパッケージのシンボリックリンク
バイナリーファイルのラッパー以外に、
/opt、/etc/opt/、または /var/opt/ ディレクトリー以外のインストールに適したファイルが多数存在するため、syspaths サブパッケージで提供できます。たとえば、データベースファイル (通常は /var/opt/provider/%{scl} に配置) へのパスを作成して、/var/lib/ にあるシンボリックリンクを簡単に検出できます。ただし、一部のシンボリックリンクでは、ベースシステムインストールの従来の RPM パッケージ名が競合する可能性があるため、元の名前で /var/lib/ にインストールしないことが推奨されます。
シンボリックリンク
/var/lib/software_collection_1-original_name または同様の名前を付けることが推奨されます。ログファイルの場合は、推奨される名前は /var/log/software_collection_1-original_name または同様の名前になります。名前自体は重要ではないことに注意してください。ここでの設計目標は、これらのファイルを /var/lib/ または /var/log/ ディレクトリーで簡単に検索することです。
設定ファイルにも同じように適用されるゴールは、シンボリックリンクを
/etc ディレクトリーで簡単に検出することです。
3.3.5. 接頭辞のないサービス
systemd および SysV init サービスは、デーモンサービスとのユーザー対話の例です。通常、サービスの起動時にコマンド scl enable に追加する必要はありません。サービスには、クリーンな環境で設計が開始されるためです。ただし、ユーザーは正しいサービス名を使用する必要があります。通常は、Software Collection 名 (例:
rh-mariadb102-mariadb) で始まる名前になります。
syspaths サブパッケージを使用すると、適切な syspaths サブパッケージがインストールされている場合は、
mariadb、mongod、postgresql などの従来のサービス名を使用できます。これを行うには、従来のサービスファイルを参照するシンボリックリンク名に Software Collection 名を含めずに、シンボリックリンクを作成します。
たとえば、
/etc/rc.d/init.d/software_collection_1-service_1 ファイルが通常提供する software_collection_1 Software Collection のサービス _1 は、以下のシンボリックリンクを作成して service_1 としてアクセスできます。
/etc/rc.d/init.d/service_1 -> /etc/rc.d/init.d/software_collection_1-service_1
systemd ユニットファイルの場合は、以下のようになります。
/usr/lib/systemd/system/service_1 -> /usr/lib/systemd/system/software_collection_1-service_1
