At Mon, 05 Sep 2005 21:16:07 +0900, M. Takeyama(takezou) wrote:

M. Takeyamaです。

On Mon, 05 Sep 2005 12:23:29 +0200 Takashi Iwai wrote:

...

...

今井です。

[...]

...

...

例えばFTP版+市販のWnn8とかだとWnn8が浮くというか、別枠に なってしまいますし....。 /etc/X11/xim.d以下のファイルはIMのパッケージ本体とは 別個にそれぞれ別パッケージとして用意するかIMサポートパッケージ みたいな形で一つにまとめてしまうってのはどうでしょうか。

うーん、まとめる理由が理解できないのですが。 そもそも外部パッケージはサポート対象外ですし、別パッケージに全てまとめ てしまうと別の弊害が出ます。 例えば Wnn8用のファイルを含めてしまって、その後非コンパチな Wnn9 が出 た場合などですね。 今井さんのイメージしているのは、aaa_base みたいな感じで 日本語環境特有(特にIM関係)のパッケージを１まとめに出来ないか？ ということだと思います。 /etc/X11/xim.d/ja/50-scim -> ../scim /etc/X11/xim.d/ja/60-uim -> ../uim /etc/X11/xim.d/ja/70-kinput2-canna -> ../kinput2-canna /etc/X11/xim.d/ja/71-kinput2-wnn -> ../kinput2-wnn

？？ 何故にまとめる必要が？

...

…といっても、サードパーティのパッケージに関して、SUSE 側で対処できる 話ではないのですが。 wnn8は、あくまで１つの例で、Freeな tcode, anthy, skkとかは ディストロ(openSUSE)でやって欲しいということだと思います。

これらは各パッケージに入ってますけど、何か不都合があるのでしょうか？ xim.d/* ファイルは、対応する IM がインストールされていて初めて意味があ ります。同様のシステムで言えば、例えば、ある init script がそのサービ スがインストールされていないのに存在していたら、変ですよね？ -- Takashi Iwai ALSA Developer - www.alsa-project.org

At Mon, 05 Sep 2005 21:47:50 +0900, M. Takeyama(takezou) wrote:

...

...

今井さんのイメージしているのは、aaa_base みたいな感じで 日本語環境特有(特にIM関係)のパッケージを１まとめに出来ないか？ ということだと思います。 /etc/X11/xim.d/ja/50-scim -> ../scim /etc/X11/xim.d/ja/60-uim -> ../uim /etc/X11/xim.d/ja/70-kinput2-canna -> ../kinput2-canna /etc/X11/xim.d/ja/71-kinput2-wnn -> ../kinput2-wnn

？？ 何故にまとめる必要が？ まとめると違った意味で大変さが増す面もあることは理解して いますし、メンテナーさん、開発者からはどうして？ 　ということも理解できます。 ＃単なるユーザからは、１つに出来ないの？ ＃出来たら、ハッピーになれそう。　　ぐらいの提案です。(感覚的な)

もし一つのパッケージに入っていると： 1. 新しい IM を追加または変更するたびに、xim.d 統一パッケージをリビル 　ドする必要がある 2. 起動オプションが変更された場合など、パッケージに非互換性が生じた場 　合に対処できない 　例えば、xim.d 統一パッケージをアップデートすると、そのパッケージでは 　以前の IM パッケージで使用できなくなります。 3. 各 IM スクリプトでインストールされているかどうかのより厳密なチェッ 　クを行う必要があるため、起動が重くなる といった問題が生じます。このため、一つにすると、逆にアンハッピーになり ます。

...

xim.d/* ファイルは、対応する IM がインストールされていて初めて意味があ ります。同様のシステムで言えば、例えば、ある init script がそのサービ スがインストールされていないのに存在していたら、変ですよね？ まあ、まあ。そうなんですけど。 メンテナーさんがそこらあたりうまく考えてくれるかも というような期待があるわけです。(多分)

起動スクリプトというのは、実際、インストールするプログラムに非常に依存 するものですから、本来同じパッケージから提供されるべき物ですね。 先の、「サードパーティのパッケージに SUSE から提供できない」云々はそう いうことです。 メンテナンス対象外ですから、メンテナも存在しない、という理屈です。 -- Takashi Iwai ALSA Developer - www.alsa-project.org

At Mon, 5 Sep 2005 22:59:24 +0900, Masaru Imai wrote:

今井です。

なんか全然伝わってないですね.....。 多分私の話の持って行き方が悪かったのかな....。

専用パッケージにしたばっかりに本来、外に任せる事ができたはずの事や、 必要なかった作業までSUSEで対応しなければいけなくなって最悪の場合、 手に負えなくなる可能性もあるんじゃないかということです。

えーと、専用パッケージというのはどういう意味でしょうか？

例えばそれぞれのパッケージに入っている制御スクリプトに問題があった場合 とか、その修正のためだけに制御スクリプトの入っているパッケージを再配布 するのと制御スクリプトのパッケージだけ配布するのとではかなり差が出ると 思うのですが....。

これが問題の部分です。 本質的に、制御スクリプトとパッケージは謂わば一心同体なのですよ。 それをばらして配布するのは、大きなリスクを伴います。

20個のパッケージがあってその制御スクリプトの不具合のために20個の全体 パッケージを再配布するのと

うーん、SUSEβ版ならともかく、制御スクリプトが「全て」不具合になる、と いう仮定が可能性の低いものだと思うのですが…。

制御スクリプトのパッケージ１個再配布もしくは20個それぞれのパッケージの 制御スクリプトパッケージだけ再配布

とかだと差が出るんじゃないかなと。

この可能性と、サードパーティ側のアップデートによる非互換性の可能性とで は、どちらが大きいと思いますか？

まあパッケージを提供する側からすると実感されない可能性もありますが。 辛いのは多分提供された側ですが。

ですから、件の問題は、システム根本の部分 (xim.d/*) とは無関係でしょう。 今回の問題は、「製品版の Wnn8 をインストールしたら xim.d/* が入ってな いので、デフォルトで起動できない」というものですよね。 要は製品版の Wnn8 用の xim.d/* スクリプトをどこから調達するか、という 点に尽きると思います。 現在は、xim.d/* は対応するパッケージが個々にインストールしますが、今井 さんの提唱しているのは、「全ての xim.d/* (製品版 Wnn8 用を含む) を一つ のパッケージとして SUSE から提供すべき」ですね。 これは Wnn8 の問題を解決するため「だけ」の手段としては、非効率なわけで す。先に述べたように、統一パッケージというアイディア自体に、様々な問題 が載っているのですから。 xim.d/* のメカニズムは、本来、外部からの追加を容易にするように導入され たものです。SUSE 側では、製品版 Wnn8 に対応した起動スクリプトは提供で きませんので、これは外から持ってくる必要があります。 このときに、手動であれ、自動であれ、ファイル一つコピーして SuSEconfig を走らせれば OK、というはずなのです。 -- Takashi Iwai ALSA Developer - www.alsa-project.org

月曜日 05 9月 2005 22:05、Takashi Iwai さんは書きました:

...

...

...

？？ 何故にまとめる必要が？

まとめると違った意味で大変さが増す面もあることは理解して いますし、メンテナーさん、開発者からはどうして？ 　ということも理解できます。 ＃単なるユーザからは、１つに出来ないの？ ＃出来たら、ハッピーになれそう。　　ぐらいの提案です。(感覚的な)

もし一つのパッケージに入っていると：

1. 新しい IM を追加または変更するたびに、xim.d 統一パッケージをリビル 　ドする必要がある 2. 起動オプションが変更された場合など、パッケージに非互換性が生じた場 　合に対処できない 　例えば、xim.d 統一パッケージをアップデートすると、そのパッケージでは 　以前の IM パッケージで使用できなくなります。 3. 各 IM スクリプトでインストールされているかどうかのより厳密なチェッ 　クを行う必要があるため、起動が重くなる

といった問題が生じます。このため、一つにすると、逆にアンハッピーになり ます。

...

...

xim.d/* ファイルは、対応する IM がインストールされていて初めて意味があ ります。同様のシステムで言えば、例えば、ある init script がそのサービ スがインストールされていないのに存在していたら、変ですよね？

まあ、まあ。そうなんですけど。 メンテナーさんがそこらあたりうまく考えてくれるかも というような期待があるわけです。(多分)

起動スクリプトというのは、実際、インストールするプログラムに非常に依存 するものですから、本来同じパッケージから提供されるべき物ですね。 先の、「サードパーティのパッケージに SUSE から提供できない」云々はそう いうことです。 メンテナンス対象外ですから、メンテナも存在しない、という理屈です。

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 今井 優 mail: maimai@coral.ocn.ne.jp web: http://www10.ocn.ne.jp/~masimai/ web: http://mforce3-slp.blog.ocn.ne.jp/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- For additional commands, email: suse-linux-ja-help@suse.com

今井です。 SUSE LINUXとは関係ないのですがこのスレッドの根本に関わりそうなので....。 2つの考えを同時に書いた場合、書いた本人が重きをおいてる方は通常どちら として書くべきなんでしょう。 私の場合、前の方の考えが最重要で後の方は次点的でどっちかというとどうでも 良いという様な考えということで書いてますが.....。 このスレッド読むとどうも前者ほっぽっておかれて後の方の考えが、書いた本人の 本心であるかの様な捉え方されてるので、自分でも何が何だか訳判らなくなって るんですけど.....。 Wnn8の件もあくまでも説明のための例として上げただけに過ぎず文章の中での 比重としては最も軽く、読み飛ばしてもらっても良いようなところだったんだけど、 そのためもあって「例えば」と入れたのだけれど、やっぱり書き方が悪かったという事 なのか....。 -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 今井 優 mail: maimai@coral.ocn.ne.jp web: http://www10.ocn.ne.jp/~masimai/ web: http://mforce3-slp.blog.ocn.ne.jp/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

At Tue, 6 Sep 2005 01:01:08 +0900, Masaru Imai wrote:

今井です。

月曜日 05 9月 2005 23:30、Takashi Iwai さんは書きました:

...

ですから、件の問題は、システム根本の部分 (xim.d/*) とは無関係でしょう。

今回の問題は、「製品版の Wnn8 をインストールしたら xim.d/* が入ってな いので、デフォルトで起動できない」というものですよね。 要は製品版の Wnn8 用の xim.d/* スクリプトをどこから調達するか、という 点に尽きると思います。

現在は、xim.d/* は対応するパッケージが個々にインストールしますが、今井 さんの提唱しているのは、「全ての xim.d/* (製品版 Wnn8 用を含む) を一つ のパッケージとして SUSE から提供すべき」ですね。

だれもそんなことは考えてませんしそういった提案をしたつもりもありません。 というかそういうのはすぐ破綻するのは目に見えてますから。

了解です。

...

これは Wnn8 の問題を解決するため「だけ」の手段としては、非効率なわけで す。先に述べたように、統一パッケージというアイディア自体に、様々な問題 が載っているのですから。

うーんやっぱり誤解の原因はそこですか。 上にも書きましたけど「全てのxim.d/*を一つのパッケージとしてSUSEから提供せよ」 と言ったつもりは微塵もありません。 というかそれを実行してしまったらメンテナンスが大変じゃないですか。

そうですね。

「個別にパッケージを作ることでパッケージの数等が増大してメンテナンスに困るようで あれば、個別ではなくまとめるのも仕方のないことですけど」くらいのつもりだったんで すが。

うーむ、この理由付けを推論するのは難しいです :-)

「あくまでもIMのパッケージ作るならこういう形で」という基本スタンスをパッケージ版 なりのパッケージで身を持って示せば良いのではということなのですけれど....。 SUSE用のIM制御用スクリプトまで含んだカスタム化されたパッケージを用意する 必要はなくて、IM制御用スクリプトは別パッケージとして用意してね位の方針を 実際に形にして提供したらどうかというつもりだったんですが。

確かに制御スクリプトまで含んだパッケージでやれば簡単です。 簡単ですが、SUSEのパッケージ内で完結してる場合は良くても、完結しなかった 時に制御スクリプトが入っているかとか、その他もろもろの判断を全て使う側にさ せてしまうとそれこそ混乱の元ではないのですか？

それがパッケージングの難しい点ですね。特にサードパーティの場合はそうな ります。 そもそも LSB がまだ定義されていないような分野での制御スクリプトは、OS にとても依存する話ですので、先に述べたように一つのパッケージで済まそう とすると、色々と無茶が出てきます。 これを避けるには、OS 固有の設定ファイルや制御スクリプトをサブパッケー ジにするか、%post などで動的に見分けて処理するか、といった必要が生じま す。 今回の件に関して言えば、%post で処理するのがユーザ側にとって一番楽な手 法でしょう。メンテナンスからいえば、どっちもどっちか。

外部から持ってきたパッケージにはSUSE用の制御スクリプト入ってないので 制御スクリプトのパッケージを別途調達するか、自分でサンプルを元に制御ス クリプトのパッケージを作成してインストールしてください。

とした方がまだ混乱しないで済むかと思いましたし。

基本的にそういう方針です。

現状だとサンプルを得るために「本来なら使わないので不要な」パッケージを インストールしてやらないと参考にならないのは判るかと思いますが。 AというIMとBというIMには依存関係がまったくなくて、Aのパッケージに制御ス クリプトが入ってない場合、 AというIMパッケージをインストールするためにBというIMパッケージインストール してAのパッケージへの流用終わったらBというIMパッケージをアンインストール しなければならないわけですが。 一台のマシンで一回だけインストールならまだましですが....。

すみません、ここら辺の具体的な話が全然スレッドに登ってきてないのが、混 乱の一要因だと思うのですが…。もう少し具体的な例を挙げて頂けませんか？ 別に、パッケージのインストールは不必要だけれども、xim.d/* のテンプレー トが欲しい、ということであれば、/etc/X11/xim.d/none がデフォルトで入っ てますので、流用は可能です。 まぁ、もっと具体的な例とか、解説する文書が必要だ、というのには賛成です が。

...

xim.d/* のメカニズムは、本来、外部からの追加を容易にするように導入され たものです。SUSE 側では、製品版 Wnn8 に対応した起動スクリプトは提供で きませんので、これは外から持ってくる必要があります。 このときに、手動であれ、自動であれ、ファイル一つコピーして SuSEconfig を走らせれば OK、というはずなのです。

これを単純化したいがための事だったんですが.....。 というか基本的にPRMのデータベース上にエントリの存在しないファイルを できるだけ無くすためにも IMのパッケージ+そのIMの制御スクリプトのパッケージ

と組み合わせる事で減らせるかなと思ったんですけど.....。

それで減らせると思いますよ。 ただ、「IM の制御スクリプトのパッケージ」を誰が出すか、というのは未解 決ですけれども。つまり、提案の件は誰に向けて書かれたものなのかが、いま いちはっきりしていなかったので。 -- Takashi Iwai ALSA Developer - www.alsa-project.org

今井です。 火曜日 06 9月 2005 22:40、Masaru Imai さんは書きました:

しても制御スクリプト単体のパッケージはルール違反なので配布できない」 制御スクリプト単体のパッケージはバイナリrpmパッケージの形では配布 できないという様に訂正しておきます。 nosrc.rpmパッケージの形ではやってやれない事はないので。 --

今井 優
mail: maimai@coral.ocn.ne.jp
web:  http://www10.ocn.ne.jp/~masimai/

今井です。 火曜日 06 9月 2005 23:13、Takashi Iwai さんは書きました:

原則として、ですね。 もちろん、きちんと管理されている限りは、別々でも構わないのです。 例えば、Requires タグで対応するサブパッケージを必須として、パッケージ 間でバージョン＆リビジョンチェックを行う、といった処置ですね。

色々と考えてたんですが、原則ルールをやぶりたくない（やぶれない) 様な私にはSUSELINUX用のパッケージを作る事自体が不可能であると いう事も判ったので、この話題については終わりにしたいと思います。 -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 今井 優 mail: maimai@coral.ocn.ne.jp web: http://www10.ocn.ne.jp/~masimai/ web: http://mforce3-slp.blog.ocn.ne.jp/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

M. Takeyamです。 ＃ちょっとだけレス。 On Tue, 06 Sep 2005 18:06:32 +0200 Takashi Iwai wrote:

...

今井です。

...

色々と考えてたんですが、原則ルールをやぶりたくない（やぶれない) 様な私にはSUSELINUX用のパッケージを作る事自体が不可能であると いう事も判ったので、この話題については終わりにしたいと思います。

えーと、原則もルールも、もちろん SUSE のオフィシャルパッケージとして出 す場合は、という前提条件が付きます。 iwaiさんが言われるように、別に過度に自己抑制をする 必要はないのでは。

私の場合、自分意志や考えを相手に正しく伝える為に パッケージを作った方が良い場合があるのではないかと思います。 openSUSEのポリシーとして「パッチを作成して送る。」 ということが貢献することの１つとして明記されています。 あたり前といえばあたり前のことですが... http://www.opensuse.org/index.php/How_to_participate メンテナー(開発者)は、メールで情報をやり取りするより パッチ(ソースコード)やspecファイルやパッケージの情報を交換 をすることにより、より具体的なイメージできて、問題の本質 を理解できたり、問題点がすぐわかる。 　といったケースがあるのではないかと思います。 ＃まあ、音楽家は、言葉が通じなくてもいっしょに音楽を演奏すると ＃コミニュケーションが出来てしまうということでしょうか。

ですから、「SUSE LINUX 用のパッケージ」が、「SUSE オフィシャルの物」、 という意味であれば、「NO」です。 そうではなくて、個人で SUSE に「対応」したようなものを作る場合には、別 に私が何かを強制する権利もありませんので、是非、ご自由に作成して下さい。 このスレッドで書かれた事項は、それをアップストリームに出す際の指標にで もして頂ければ、というところです。 ちなみなんですが... 自分のパッケージを「SUSE オフィシャルの物」とする方法論として、 openSUSEのメンテナー(公式)になるという手があると思いますが、 手続きとかはどこかに明記されていたでしょうか？ ＃SUSE linuxの知識があるとか、ビルド(rpm, srpm)の知識があるとか ＃他のメンテナーとコミニュケーション(英語で)が取れるとか ＃技能もそれなりに要求されると思いますが... ＃(ピチ、ピチの(日本の)若いもんが挑戦してくれればと思います。)

--- M. Takeyama __________________________________ Take an action against poverty http://pr.mail.yahoo.co.jp/whiteband/

M. Takeyamaです。 ＃雑談モード On Wed, 07 Sep 2005 10:26:44 +0200 Takashi Iwai wrote:

...

ちなみなんですが... 自分のパッケージを「SUSE オフィシャルの物」とする方法論として、 openSUSEのメンテナー(公式)になるという手があると思いますが、 手続きとかはどこかに明記されていたでしょうか？

具体的な案は、まだ正式には決定していないと思います。 SL10.0 が出た後に、随時解決していくと思いますよ。 そうですか。(ありがとうございます。)

ちなみに、SUSE のbugzillaをみたら SUSE Linux 10.1のタグが 出来ていたので、SL 10.0RC1は、出来あがっていて(公開待ち) SL10.0のリリース最終段階に入ったんだろうと推測しています。 http://www.opensuse.org/index.php/Roadmap

＃(ピチ、ピチの(日本の)若いもんが挑戦してくれればと思います。) という文言(私の過去発言)の想定している風景として...

・親子で、openSUSE のパッピーハッキング。 子供が openSUSEのメンテナー(公式)で、親の送った パッチを却下したりすることがあったり。 ・夏休みの自由研究に「openSUSEの○○○研究」とかがあったり。 ・「中学、高校の期末試験、入試試験なんで、ちょっと間 　　メンテナーを変わってくれない」って会話があったり。 　　　・ 　　　・ 　　　・ openSUSEのメンテナー(公式)の資格として、基本的には、年齢、 性別、国籍などで差別しない。 メンテナーとしての能力だけで決まって欲しいですね。 ＃現実的には、選抜とかがなかなか難しいでしょうけどね。 ＃今までのディストロとかオープンソースコミニュティでの実績とかがないと --- M. Takeyama __________________________________ Take an action against poverty http://pr.mail.yahoo.co.jp/whiteband/

At Mon, 5 Sep 2005 22:28:13 +0900, Masaru Imai wrote:

今井です。

月曜日 05 9月 2005 21:25、Takashi Iwai さんは書きました:

...

...

今井さんのイメージしているのは、aaa_base みたいな感じで 日本語環境特有(特にIM関係)のパッケージを１まとめに出来ないか？ ということだと思います。 /etc/X11/xim.d/ja/50-scim -> ../scim /etc/X11/xim.d/ja/60-uim -> ../uim /etc/X11/xim.d/ja/70-kinput2-canna -> ../kinput2-canna /etc/X11/xim.d/ja/71-kinput2-wnn -> ../kinput2-wnn

？？ 何故にまとめる必要が？

やっぱり「製品を作る側」と「製品を使う側」の差ですかね。 作る側としてはパッケージ内に含まれているものだけで済ませてもえらえばいいだけ の事なので別に専用パッケージになってようが問題ないし、パッケージも分けずに済 むわけですから。

使う側からすれば外部から取り込んだパッケージを使いたいと思う時もあるわlけで そういう時に専用パッケージでないとまともに動かない場合、 取り込もうとしたパッケージの方がウェイト高くて急いでいる場合など、プラットホーム (OS)の方を放棄するなんて事にもなるわけですが....。

ですから、この点は「統一パッケージ」とは何の関係もないのです。 統一パッケージにしようがしまいが、xim.d をサポートしない外部のパッケー ジをインストールした時点ですでに終わっているわけでして。 私自身は、追加の xim.d パッケージ自体に反対するものではありません。 「統一」したパッケージには全く意味がない、とは思いますが。

...

xim.d/* ファイルは、対応する IM がインストールされていて初めて意味があ ります。同様のシステムで言えば、例えば、ある init script がそのサービ スがインストールされていないのに存在していたら、変ですよね？

私の考えているところからすれば ximd-develなりximd-examples用意してそちらにそれらのファイルを入れておけば 良いのでは？と思うんですが....。

そうなのですが、誰がこれを書いて、パッケージング、テストして、さらに管 理するか、という問題が生じますし、このパッケージをどのタイミングでイン ストールするのか、といった問題も生じます。 前者は openSuSE でだれかが責任を持って管理してくれれば、解決、となるの でしょうけれども、後者はちょっと面倒。パッケージ依存性だけでは無理です し。 もしくは、オムロンさんが Wnn8 の rpm に xim.d を追加するか、スクリプト を添付してくれれば全て丸く収まるのですが…。 -- Takashi Iwai ALSA Developer - www.alsa-project.org

At Mon, 5 Sep 2005 23:09:38 +0900, Masaru Imai wrote:

今井です。

月曜日 05 9月 2005 22:50、Takashi Iwai さんは書きました:

...

もしくは、オムロンさんが Wnn8 の rpm に xim.d を追加するか、スクリプト を添付してくれれば全て丸く収まるのですが…。

オムロンさんがそれをすると、SUSEのパッケージ内の構成と一貫性が崩れる、 他のディストリ用のパッケージとの違いが生じるのでまた別の問題を引き起こ す訳ですが。

そもそも、この分野は LSB がまだ定義されていないのですから、一つのパッ ケージで全てをカバーしよう、というのが難しい点でしょう。(無理とは言い ませんが。) SUSE 内との一貫性が、具体的に何を指しているのか不明なのですが、 /etc/X11/xim ファイルを無理矢理上書きしようとするとどうしても問題は出 てきます。これはどのディストリビューションでもどのバージョンでも同じで しょう。これをやったら、そもそも間違い。必ずしわ寄せが出てきます。 ですから、それこそ xim.d/* ファイルだけを持つ wnn8-ximd-suse.rpm といっ た追加パッケージ、または ATOK の様に追加スクリプトを用意すればよいだけ の話では？追加パッケージですから、オンライン提供で構わないですし。

苦労して梱包の終わった荷物に、追加して何か送ろうとした場合の行動を 考えてみればおのずと答えが見えてくるかと....。

少なくとも梱包開ける、元々の荷物とは別の手段で送るのは避けたいと思う のではないかと....。

これを、逆の立場 (SUSE が送出側) で見てみて下さい。 「統一 xim.d/* パッケージ」が非効率的なことが分かると思います。 -- Takashi Iwai ALSA Developer - www.alsa-project.org