--- Begin Message ---
----ここから----
五十嵐＠青学です。
みなさん、お騒がせしてもうしわけありませんでした。建設的な意見をという
ことで、遅ればせながら、考えていたことを書かせてもらいたいと思います。
1) dselect LANG=JP
dselectを使って、system全体をinstallしなおすのは、(少なくとも僕にとっ
ては)なかなか骨のおれる作業でした。「ドキュメントはほしいから、全部チェッ
クしちゃえ」と、安易にドキュメント全体をチェックしたら、英語と日本語以
外のドキュメントもinstallされちゃって、「あっちゃー」と思ったんです。
ですから、LANG=JPと先に決定されているなら、「ドキュメント全体を選択す
る」というオプション以外に、「日本語と英語のドキュメント全部を選択する」
という選択肢を有効にしてくれるようであれば、うれしいと思いました。
より具体的にというのであれば、パッケージのitとか、jp等の単語にたいして、
検索をして、LOCALE固有のパッケージがあれば、「LOCALE=JP( JAPANESE + C
)」みたいなグループを生成すればいいと思いました。ただ、dselectのsource
を読んでいないので、偉そうなことは言えないんです。ごめんなさい。
それから、Debian-JP 2.0 のCDを購入しまして、Debianを使っているんですが、
「本家に吸収されている」日本語関係のパッケージは、逆にDebian-JPだけに
集中させた方が良いのではないかと、思いました。
そうすれば、installの時に、debianのCDからは、英語環境だけをinstallし
(これであれば、dselectのdescriptionを読まなくても、手軽にinstallできる
と思います)あとから、Debian-JPのCDから日本語環境をinstallするという作
業が、行えると思います。もしかしたら、すでに、そういう構造になっている
かも知れません。ちょっと確認していないので、ごめんなさい、よくわからな
いのですが、そうなるといいなと、思いました。
つまり、Slack/RH + PJE のような形です。
もしくは、以前MLに流れていたような気もするのですが、TurboLinuxの様に、
「これ一枚で日本語環境は完璧だ」という CDを作ってくれるとうれしいと思
います。
2) /usr/....の問題。
阿南さんとの私信(公開されてしまいましたが)の中で交わしたんですが、
install先を選べるといいと、思いました。
たとえばgccは、2.8.1, 2.7.2.3, egcs-1.03, egcs-1.1b, egcs-snapと、思い
付くだけでもこれだけ考えられます。ぼくは、C++を使うことがあるのですが、
/usr以下にegcs-1.1bを入れると、templete等も含め、C++の比較的新しい機能
が使えるのがうれしい(実は、snapshotのgcjの方がうれしいんですが)のです
が、Linuxのkernelがmakeできなくなるなどの、問題もあります。僕の場合は、
手動でmakeしているので、install先を変えることで解決しています。
.tcshrcの中で、
setenv COMMON_PATH $PATH
setenv STABLE_GCC2_PATH /usr/local/gcc2/bin:$COMMON_PATH
setenv EGCS_PATH /usr/local/egcs/bin:$COMMON_PATH
setenv EGCS_SNAP_PATH /usr/local/egcs-snap/bin:$COMMON_PATH
alias gccenv "setenv PATH $STABLE_GCC2_PATH"
alias egcsenv "setenv PATH $EGCS_PATH"
alias egcssnapenv "setenv PATH $EGCS_SNAP_PATH"
setenv PATH /usr/local/egcs-snap/bin:$COMMON_PATH
としています。また、.emacsのなかでhookを作り、いくつかのモードから、
compileするときだけ、(setenv foo bar)を使って、PATHを変更しています。
また、先日研究室のUNIXにemacs-20.3をinstallしたんですが、たまたまその
先生は、emacs-19.34のlispディレクトリを、/usr/gnu/share/emacs/以下につ
くっていたので、見事に、emacs-20.3とコンフリクトしました。つまり、
configureをかけた時に、emacs-19.34用のsite-lispディレクトリ
(/usr/gnu/share/emacs/site-lisp)をデフォルトのload-pathに含められてし
まい、customizeなんかが、誤動作してしまったのです。結局、installしてし
まってからミスに気付き、src/paths.hから、emacs-19.34用のsite-lispをは
ずして再コンパイルすることで解決しました。
こんなとき、debianのパッケージで、emacsをinstallしたら、大変だろうなぁ
と思いました。個人の一台のPCにdebianをinstallしている分には、問題ない
と思うんですが、僕の研究室のように、/usr/gnu/binをNFSして複数のアーキ
テクチャのマシンで使い分けたり、/usr/gnu/shareを複数のアーキテクチャで
共有していたりしたら、どうなるんだろうと思ったんです。
ぼくのアイディアとしては、FreeBSDのportsのパクリみたいなんですが(^^;例
えば、src/paths.hに依存しないソースをcompileしてしまい、packageに.cと.
oを混在させておき、install前の作業(site-init.el(だったかな?)とか
src/paths.hとか）を済ませてから、makeを動かすというものです。
binaryを直接いじって、path情報を書き換えるのは、大変だと思うので....。
debian policyの中だけにとどまらずに、他のOSと共存できるような環境を作
れるようなdselectがあると、いいなと思いました。
また、dselectのアイディアは、すばらしいと思うので、いっそのことjavaな
んかで実装して、複数のアーキテクチャで動くdselectというのもおもしろい
と思いました。
Sunとか、Win32とかでもdselectが使えると。それは、きっとDebian/GNU
Linuxではないんでしょうが、Debianなシステムを作ることができるのではな
いかと思います。それがいいことか、悪いことかはわかりませんが、もしjava
版を作るのであれば、喜んでお手伝いしたいと思います。
こんなところです。
何かありましたら、お手数ですが、hiro@xxxxxxxxxxxxxxxxxxxxxxまで、メー
ル頂けるとうれしいです。
Hirotaka Igarashi
--- End Message ---