オレの愛用しているエディタであるJed、Mailerのmutt、NewsReaderのslrnは、すべてがこのS-Langライブラリを使用している。というかS-Langの画面制御の上に各種機能を実装しているのだ。
GUIのみならず、CUIな管理・設定ツール(どっちも大して使い易いとは思わんが)を備え、管理が容易になった(というかRedHat社がそう思ってるだけって気も)と言われるRedHatでは、インストーラをはじめとして、CUIなツールのほとんどが、S-Langを使っている。パッケージの名前で○○configという類はほとんどが依存していることと思う。
だが、この赤帽に最初から含まれているS-Langは、日本語に対応していない上に、実はだいぶ古いのだ。version
0.99.38というバージョンだが、実際にオレが普段使っている日本語対応のS-Langのバージョンはversion 1.2.2J053と呼ばれている。従来、S-Langは単品で日本語に対応してきたワケではなく、それを使用している上位アプリであるJedやmuttやslrnといったものを日本語に対応させる上で、必要な改造が下位層のS-Langに対して行われてきたといった感じで、かつてはJed用S-Langやslrn用S-Langなどと、同じライブラリ内でバージョンやリビジョンごとのの実装が異なる、という状況があったのだが、最近になってついにそれらが統合され、Jed、mutt、slrnで一つのS-Langライブラリを共用できるようになった。
それまでは、JedはJedで、Jed用のlibslangをstatic linkし、muttはmuttでそれ用のlibslangをstatic linkして、などとやっていたのが、共通のlibslang.soをdynamic linkするだけでよくなったのだ。 これはやはりshared libraryの方を使いたいよねぇ。
だが、ここで普通にS-Langをパッケージ化してしまうと困ったことに、赤帽にもともと入っているS-Langのパッケージと当然ながらコンフリクトしてしまう。もとのS-Langを使っているパッケージなど、どうせオレ的にはほとんど使わない、いりもしない管理ツールなので、そっちをサクサクと消してから、日本語化された新しいS-Langを入れればいいようなもんだが、妙にたくさんのパッケージが依存していて消すのも面倒なほどだし、いつ宗旨変えして使いたくなるやも知れぬ。
--force --nodepsオプションなどを付けてブチ込んでもいいのだが、そうするとS-Langのパッケージについて二つの異なるバージョンが混在してしまうことになり、今後、日本語対応S-Langをアップデートするにも面倒が付きまとうことになる。
というわけで、日本語対応なS-Langのパッケージはパッケージの名前自体を変えてしまい、コンフリクトが起きないようにしてしまった。こうして作ったパッケージを、パッケージ置き場に置いておいた。
こうすることで、もともと入っているlibslang.so.0.99.38というshared libraryと、日本語に対応したibslang.so.1.2.2というshared libraryを共存させることができるようになる。日本語対応S-Langはまだまだバージョン・アップが続くだろうが、その時でもslang_jpパッケージを作り直してrpm -Uvhなどで入れ替えるだけなので簡単だ。もともと入っている妙な(失礼)CUIの管理ツールも使い続けられるしね。
ただ、これですべでコンフリクトが避けられるわけではなくて、shared libraryとして単に使っているだけなら問題はないのだが、S-Langを使うjedやmutt、slrnなどをmakeするためには、開発環境としてのヘッダ・ファイルなどを含むslang_jp-develのパッケージをしなければならない。そうすると、/usr/include/slangの下にヘッダ・ファイルが展開されてしまうし、めったに使わないとはいえ、static libraryはibslang.aと同じ名前なのでやはりコンフリクトしてしまうのだ。
まぁオレ的には古いほうのS-Langをどうこうしようなどという気はサラサラないので、slang-devel-0.99.38はとっとと捨てて、slang_jp-devel-1.2.2の方を入れてあるのは言うまでもない。が、JRPMなどでの議論を経た合意事項などというものでもなく、都合が悪いから単に名前を変えただけだったりするので、誰にでも勧められるというワケでもない(笑)
| メール | 戻る |