アカウント名:
パスワード:
-currentの方では、すでにperlなしでkernelが作れるようになっています。hintsを作るscriptがまだ残っていますが、kernelを作る時に使うものではありません。
また、この変更はMFCされません。4-stableは最後までperlつきです(多分「CDやDVDでは...」は本当はこういう意味?)。-currentでは近いうちにportsなどによってのみperlをinstallすることになります。
FreeBSD システムの側で面倒見てくれないの?
自分でFreeBSDでサーバーを立ててる人に対してなら「そのぐらいやれよ」でもいいと思います。でもホスティングサービスで /usr/bin/perl と決め打ちした cgi を置いて使ってる人に「設置した人が勝手に直すだろ」では可哀想な気も。やはり symbolic link ぐらい張ってあげないと...
# >>でもホスティングサービスで /usr/bin/perl と # >>決め打ちした cgi を置いて使ってる人に # >>「設置した人が勝手に直すだろ」 # わざわざそこで引用切らなくても... ^^;;; # なんて事はどうでもいいんですが。
>というか、perlのパスを書き換えることもできないような人が >掲示板を設置しているのは、ちょっとどうかと思う私は駄目?
いや、駄目ではないと思います。 私も知ってて欲しいと思います。 でもそれは「emailを使うならRFC2822ぐらい目を通しておいたほうがいいじょ」という程度の意味で「RFC2822を理解してない奴はemailを出すな」とまで言う気はないのと同じです。あくまで第三者としての希望(期待かな?)。
# 逆にちょとどうかと思われる人が可哀想だと思う私は駄目？ :-)
テキストファイルの 1 行目を書き換える「作業」自体はそれほど困難だとは思いませんので念の為。特に perl script を多少でも知ってる人なら全然困難ではないでしょうね。
ただ cgi を設置してる人全てがそうだとは思ってないだけです。perl を知らないでも設置だけなら出来たりします。(実際にそうしてる人を知ってます) そしてそういう人は仮にレンタルサーバー会社が「perlのpathを変更しました」と告知しても修正出来ないかもしれないので可哀想だと思っただけです。
<余談> html なんて知らなくても自分のサイトを作り、perl を知らなくても cgi script を持ってくる事が出来るご時世ですからねぇ。便利な世の中になったと言うか、不便な世の中になったと言うか...</余談>
私は「RFC2822を理解しろ」とも「パスを書き換えられるようにしろ」とも主張してないのに...
あくまで「/usr/bin/perl が知らぬ間に /usr/local/bin/perl になると対処できない人が可哀想だね」と言ってるだけで ^^; もちろん私の下手な日本語を読んでそう考えてるのを理解しろとは言いませんが ^^;;;
# はい、まともな日本語も書けないくせに文句を言っても # ノイズになるだけなのでこれ以上言い訳なんてしません ^^;
堕落できるところは堕落する Linux と、そうでない BSD の文化の違いでしょうか。
個人的には、2.4系カーネルで
今回の一件はあくまでFreeBSD-current、すなわち今年の末頃を予定している開発ブランチからの次期リリース版でのお話です。Linuxで言えば2.5系カーネル。そこのところ、お間違えなきよう。
そんなこといったら、httpdなんて各OSの提供するportsやrpmとかで インストールされるディレクトリパスが違うぞ。 linuxの場合ディスストリ毎にperlのパスも違うんじゃないか? 昨今のLinuxのそのいたせりつくせり状態は
昨今のLinuxのそのいたせりつくせり状態は
けっきょく、Linux は「いたれりつくせり」なのか、 そうでないのか、どっちだと思っているのですか?
ぼくの意見について言えば、Linux 全般を知っているわけではないのに 「Linux」という言葉を使ったのがまずかったです。 少なくとも、Debian では、たとえば /usr/doc から /usr/share/doc にドキュメントを移動させるという作業を何年もかけてやっていますが、 いまだに、/usr/doc/* -> /usr/share/doc/* へのシンボリックリンクを 提供しつづけています。将来的に廃止されるかどうかは分かりませんが。 そういうことを念頭に置いています。 ちなみに、ディストリ毎 (あるいは OS 毎) に違う、というのは問題にしていません。 バージョンアップの際に変更作業が必要かどうか、というのが 視点ですので。もし OS 間の互換性ということを問題にするなら、 各種 Linux ディストリの間だけでなく、それらと各種 BSD の間の互換性ということも問題になってくるでしょう。
インストール猿ですが、 本質的なところで設定が必要なものは、 Linux でも BSD でも変わらないはずです。 むしろ、本質から外れたところ (/usr/bin から /usr/local/bin に変わったので変更作業が必要だ) に気を使わなくていいとすれば、それだけの時間と注意力を ほかの本質的な部分に割り当てることも可能になります。
apache などのサーバを、デフォルトでインストールするか、 とか、インストールするだけで 何らかのデフォルト設定で動作させるべきかどうか、とか、 そのデフォルト設定の内容がどうか、ということは、 インストール猿対策上、重要なことではあるでしょう。 そして、この点については、BSD な人々の Linux に対する批判は当たっていることが多いと思います。 が、いまはその話題ではありません。 というか、/usr/bin から /usr/local/bin に変更するときにシンボリックリンクを張るなどのことをしない、 ということで、インストール猿対策になっているとお考えでしたら、 それは間違っているのではないかと思います。
Linuxのファイルの置き場所についての話をするなら、 まずFHS [pathname.com]を読み、 その上で、あるディストリビューションが(それが表明している)FHS対応の 内容について指摘を行うのがよいでしょう。
FreeBSD システムにおける Perl のパスが変更になったから、 「ユーザが勝手に作成した」perl スクリプトの変更が余儀なくされている、 というのがいまの状況でしょう。
FreeBSD としてはシステムから Perl を切り離したから、もう Perl の面倒は見ません、 各自の自助努力でやってください、 ということなら、それはそれでありでしょう。 ただその場合、「いま」システムの一部とされているものが、 将来もシステムの一部でありつづけるとの信用を犠牲にしているわけですが。 (Perl の次には何がシステムから削除されるのだろうか...)
まあ、/usr/bin/perl から /usr/local/bin/perl という、どちらも「ありえる」パス同士の変更だから、 いいのかも。/usr/bin/perl から /usr/oreno/katteda/perl だったら、そうもいかないけど。
「すべからく」に「全て」の意味はありません。
どの ac を信じたらいいものやら。 というか、どれとどれが同一人物?
えーと、一回/usr/bin/perlをいれたんだからそれを提供しつづけるべきだというの ならperlのバージョンアップもできなくなっちゃいます。perl4とperl5とperl5.6の 非互換性は如何ともしがたいですよね。
たしかにそれは問題になりますね。ただし、如何ともしがたい、 というほど難問でもなくて、たとえばバイナリは /usr/bin/perl4 とか /usr/bin/perl5 とかでインストールするようにして、 /usr/bin/perl -> /usr/bin/perl5 とかいうふうにリンクを張るようにして、 複数のバージョンの perl をインストールしようとするとどちらに symlink するかを尋ねてくるようにしておく、とか。 (後から入れたほうを優先、などの決め打ちでも構わないと思うけど)。
まあ、(Perl に対して) バージョンアップのときに仕様を変えるのはやめてほしいな、 という話もあるけど。
オプショナルで、/usr/bin/perlをインストールしてくれるものを提供した方が親切 ではあるでしょう。
そうですね。 perl の ports をインストールすると自動的に /usr/bin/perl -> /usr/local/bin/perl ができる、というのがいいかもね。
＃が、upgradeインストールしたら、どうせ/usr/bin/perlのこっちゃうからまあえ えやん、というのはだめか？
なるほど、そういうのが方法がありましたか... それでもいいですね。 (新規インストールのときにはたぶん問題にならないだろうし)。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
-currentでは (スコア:2, 参考になる)
-currentの方では、すでにperlなしでkernelが作れるようになっています。hintsを作るscriptがまだ残っていますが、kernelを作る時に使うものではありません。
また、この変更はMFCされません。4-stableは最後までperlつきです(多分「CDやDVDでは...」は本当はこういう意味?)。-currentでは近いうちにportsなどによってのみperlをinstallすることになります。
Re:-currentでは (スコア:1, すばらしい洞察)
ってぇことは、perlのpathは/usr/local/bin/perlに戻るわけですね。
#!/usr/bin/perlとしてしまったスクリプトファイルは全部書き換えが
必要なわけだ・・・またそれ用のツール作らにゃ。
Re:-currentでは (スコア:0)
だめ？
Re:-currentでは (スコア:0)
FreeBSD システムの側で面倒見てくれないの?
Re:-currentでは (スコア:0)
そのくらい何でもないじゃん…
そのくらいめんどくさがっていたら、
FreeBSDで何にもできないような期がするが
Re:-currentでは (スコア:1)
自分でFreeBSDでサーバーを立ててる人に対してなら「そのぐらいやれよ」でもいいと思います。でもホスティングサービスで /usr/bin/perl と決め打ちした cgi を置いて使ってる人に「設置した人が勝手に直すだろ」では可哀想な気も。やはり symbolic link ぐらい張ってあげないと...
Re:-currentでは (スコア:1, すばらしい洞察)
>決め打ちした cgi を置いて使ってる人に
>「設置した人が勝手に直すだろ」
とかだったら、ホスティングしている会社がsymlinkすればいいだけでないの?
それが嫌なら、告知を出せばすむでしょう。
というか、perlのパスを書き換えることもできないような人が
掲示板を設置しているのは、ちょっとどうかと思う私は駄目?
Re:-currentでは (スコア:0)
Re:-currentでは (スコア:1)
# >>でもホスティングサービスで /usr/bin/perl と
# >>決め打ちした cgi を置いて使ってる人に
# >>「設置した人が勝手に直すだろ」
# わざわざそこで引用切らなくても... ^^;;;
# なんて事はどうでもいいんですが。
>というか、perlのパスを書き換えることもできないような人が
>掲示板を設置しているのは、ちょっとどうかと思う私は駄目?
いや、駄目ではないと思います。 私も知ってて欲しいと思います。 でもそれは「emailを使うならRFC2822ぐらい目を通しておいたほうがいいじょ」という程度の意味で「RFC2822を理解してない奴はemailを出すな」とまで言う気はないのと同じです。あくまで第三者としての希望(期待かな?)。
# 逆にちょとどうかと思われる人が可哀想だと思う私は駄目？ :-)
Re:-currentでは (スコア:0)
テキストファイルの一行目付近をちょっと書き換えることの
どこが困難なんですか?
テキスト編集もできない人が掲示板設置しても
本当にその掲示板使えてるの?
Re:-currentでは (スコア:0)
Re:-currentでは (スコア:1)
テキストファイルの 1 行目を書き換える「作業」自体はそれほど困難だとは思いませんので念の為。特に perl script を多少でも知ってる人なら全然困難ではないでしょうね。
ただ cgi を設置してる人全てがそうだとは思ってないだけです。perl を知らないでも設置だけなら出来たりします。(実際にそうしてる人を知ってます) そしてそういう人は仮にレンタルサーバー会社が「perlのpathを変更しました」と告知しても修正出来ないかもしれないので可哀想だと思っただけです。
<余談>
html なんて知らなくても自分のサイトを作り、perl を知らなくても cgi script を持ってくる事が出来るご時世ですからねぇ。便利な世の中になったと言うか、不便な世の中になったと言うか...
</余談>
Re:-currentでは (スコア:0)
>perl を知らないでも設置だけなら出来たりします。(実際にそうて
>る人を知ってます) そしてそういう人は仮にレンタルサーバー会が
>「perlのpathを変更しました」と告知しても修正出来ないかもしれな
>いので可哀想だと思っただけです。
全然可哀想と思わないのですが…というかそんなの自業
Re:-currentでは (スコア:1)
私は「RFC2822を理解しろ」とも「パスを書き換えられるようにしろ」とも主張してないのに...
あくまで「/usr/bin/perl が知らぬ間に /usr/local/bin/perl になると対処できない人が可哀想だね」と言ってるだけで ^^; もちろん私の下手な日本語を読んでそう考えてるのを理解しろとは言いませんが ^^;;;
# はい、まともな日本語も書けないくせに文句を言っても
# ノイズになるだけなのでこれ以上言い訳なんてしません ^^;
Re:-currentでは (スコア:0)
その方が賢明です。
はっきり言って、あなたはユーザを甘やかしすぎで、
かつその人のスキルをあまく見過ぎです。
大体、自前でスクリプトを拾ってきて使用するのなら、
自己責任で対処して欲しいです。
それができない人はプロバイダが提供するCGIを利用すべきです。
「知らない間に…」というのは、たしかに一理ありますが、
健全なサービスを提供して
Re:-currentでは (スコア:0)
内容はいいんだが、日本語ちょっと変だぞ。
文化の違い? (スコア:1)
堕落できるところは堕落する Linux と、そうでない BSD の文化の違いでしょうか。
Re:文化の違い? (スコア:2, すばらしい洞察)
そんなこといったら、httpdなんて各OSの提供するportsやrpmとかで
インストールされるディレクトリパスが違うぞ。
linuxの場合ディスストリ毎にperlのパスも違うんじゃないか?
どれも同じパスでっていうならオリジナルソースから
インストールすればいいじゃん。
それなら各OS間の違いも吸収できるし
昨今のLinuxのそのいたせりつくせり状態は
堕落させるじゃなくて、
インストール放置猿 量産の温床な気がするんだが
Re:文化の違い? (スコア:1)
個人的には、2.4系カーネルで
- userlinkが動かねぇ
- ipchainsが使えねぇ
という話と何が違うのか判りません。もちろん、この2点に代替手段があるのは知ってます。でもperlの話だって一緒ですよ？perlでプログラム書く人の都合だけは、OSの開発者が考えてあげなきゃいけないものなんでしょうか？今回の一件はあくまでFreeBSD-current、すなわち今年の末頃を予定している開発ブランチからの次期リリース版でのお話です。Linuxで言えば2.5系カーネル。そこのところ、お間違えなきよう。
Re:文化の違い? (スコア:0)
Re:文化の違い? (スコア:0)
すぐに「文化」とか言い出すのに飽き飽きしてるのはワシだけかのぅ...
こーゆーことをいう輩は、まずその「文化」とやらを定義してください。
Re:文化の違い? (スコア:1, 興味深い)
堕落の中に「Linuxしか考えない」は入れないでほしいものだ。
「FHS準拠を前提に決め打ち」てのが増えている気がする。
特にGNOME物は、パスがハードコードされまくりでうんざりする。
(せっかくautoconfを使っているのによー)
最初のうちは地道にフィードバックしていたけど、ハードコード
されたものを生産するペースの方が速いからあきらめた。
(FreeBSD portsも、一括置換で対応してたりするよね)
Re:文化の違い? (スコア:2, すばらしい洞察)
けっきょく、Linux は「いたれりつくせり」なのか、 そうでないのか、どっちだと思っているのですか?
ぼくの意見について言えば、Linux 全般を知っているわけではないのに 「Linux」という言葉を使ったのがまずかったです。 少なくとも、Debian では、たとえば /usr/doc から /usr/share/doc にドキュメントを移動させるという作業を何年もかけてやっていますが、 いまだに、/usr/doc/* -> /usr/share/doc/* へのシンボリックリンクを 提供しつづけています。将来的に廃止されるかどうかは分かりませんが。 そういうことを念頭に置いています。 ちなみに、ディストリ毎 (あるいは OS 毎) に違う、というのは問題にしていません。 バージョンアップの際に変更作業が必要かどうか、というのが 視点ですので。もし OS 間の互換性ということを問題にするなら、 各種 Linux ディストリの間だけでなく、それらと各種 BSD の間の互換性ということも問題になってくるでしょう。
インストール猿ですが、 本質的なところで設定が必要なものは、 Linux でも BSD でも変わらないはずです。 むしろ、本質から外れたところ (/usr/bin から /usr/local/bin に変わったので変更作業が必要だ) に気を使わなくていいとすれば、それだけの時間と注意力を ほかの本質的な部分に割り当てることも可能になります。
apache などのサーバを、デフォルトでインストールするか、 とか、インストールするだけで 何らかのデフォルト設定で動作させるべきかどうか、とか、 そのデフォルト設定の内容がどうか、ということは、 インストール猿対策上、重要なことではあるでしょう。 そして、この点については、BSD な人々の Linux に対する批判は当たっていることが多いと思います。 が、いまはその話題ではありません。 というか、/usr/bin から /usr/local/bin に変更するときにシンボリックリンクを張るなどのことをしない、 ということで、インストール猿対策になっているとお考えでしたら、 それは間違っているのではないかと思います。
Re:文化の違い? (スコア:1)
簡単にいってしまうと既存のperl コードを走らせた時にエラー停止したとします。
その症状を診断できない人がコード書いてる現実は問題ですよね。
この原因をつくっているのはOS ではなく多くの入門書であろうと考えますが
「 perl 本体は、システムによって違いますがほとんどのシステムは
/bin/perl
/usr/bin/perl
/usr/local/bin/perl
のどこかにあります 」
ってのが多すぎる。
ドキュメントに関しては、オンラインドキュメントが基本ですが
そこに頼る必然性は無いわけで。
要するに、「これからのFreeBSD はperl が標準で入っていない」
というアピールが問題なのではないかと。
標準で無いモノのsymlink がOS インストール時に存在するのはナンセンスですし
インストール時にコレを作るのもユーザの好みの問題ですよね。
ほとんどのフリーウエアがそうであるように
インストール時にシステムに対してどのような変更がなされたかは
ユーザが自身が確認するモノではないでしょうか？
切り離したモノに対して簡便さや互換性を求める方がナンセンスに感じます。
Re:文化の違い? (スコア:0)
これは当初のシステムに含まれるファイルの変更ですよね。話題は「ユーザーが勝手に追加・作成したファイルの中」の #!/usr/bin/perl の記述への対応だった気がします。
Re:文化の違い? (スコア:0)
Linuxのファイルの置き場所についての話をするなら、
まずFHS [pathname.com]を読み、
その上で、あるディストリビューションが(それが表明している)FHS対応の
内容について指摘を行うのがよいでしょう。
Re:文化の違い? (スコア:1)
FreeBSD システムにおける Perl のパスが変更になったから、 「ユーザが勝手に作成した」perl スクリプトの変更が余儀なくされている、 というのがいまの状況でしょう。
Re:文化の違い? (スコア:1)
FreeBSD としてはシステムから Perl を切り離したから、もう Perl の面倒は見ません、 各自の自助努力でやってください、 ということなら、それはそれでありでしょう。 ただその場合、「いま」システムの一部とされているものが、 将来もシステムの一部でありつづけるとの信用を犠牲にしているわけですが。 (Perl の次には何がシステムから削除されるのだろうか...)
まあ、/usr/bin/perl から /usr/local/bin/perl という、どちらも「ありえる」パス同士の変更だから、 いいのかも。/usr/bin/perl から /usr/oreno/katteda/perl だったら、そうもいかないけど。
Re:文化の違い? (スコア:0)
違います。
Perl がデフォルトで含まなくなるだけでしょ。
なんか批判するところがずれてません?
Re:文化の違い? (スコア:0)
「Linuxしか考えない」
の極致の様な気もしますが。
すべからく UNIX 系の OS は Linux に合わせなければいけないとでも?
Re:文化の違い? (スコア:2, 参考になる)
Perlは何時から"FreeBSDのシステム"になったのでしょう。
便宜上同時にインストールしている『外部』ソフトウェアに過ぎないものが不要になったから外したよ、ってことでしょ？
だから
>「いま」システムの一部とされているものが、 将来もシステムの
> 一部でありつづけるとの信用を犠牲にしている...（略）
は、勝手に期待するな、って事で必要であればインストールし、不要であればそのままで良い、って事だと。
スクリプトの１行？
lnするにせよ、スクリプトを直すにせよ、それは管理者（運営者）の仕事であってＯＳディストリビュータの仕事では無いと思うのですが。
# 例えばHTMLはXHTMLでタグに大文字が使えない様に規定されたと
# 思いますが、何時までも「タグに大文字が使えるって信じてた」
# って言うのと同じ気が
Re:文化の違い? (スコア:1)
オプショナルで、/usr/bin/perlをインストールしてくれるものを提供した方が親切ではあるでしょう。
＃が、upgradeインストールしたら、どうせ/usr/bin/perlのこっちゃうからまあええやん、というのはだめか？
Re:文化の違い? (スコア:1)
> すべからく UNIX 系の OS は Linux に合わせなければいけないとでも?
待ってくれ、FHS は Linux 専用の標準ではないよ？
Unix-like operating systems についての標準なんだが。
(ちなみに Linux のディストリビューションの中には FHS に準拠しているものもあるし、
していないものもある)
# mishimaは本田透先生を熱烈に応援しています
Re:文化の違い? (スコア:1)
だったら、用が済んだら削除しておけばよかったでしょ。
そうでなければ「この perl は一般の用途で利用すべきではない」とか
ポリシーマニュアルに付け加えておくべき。
で、ポリシーにもない、削除もしなかったことを考えると、
当然その perl を一般に利用して欲しかったんだろう。
> # 例えばHTMLはXHTMLでタグに大文字が使えない様に規定されたと
> # 思いますが、何時までも「タグに大文字が使えるって信じてた」
> # って言うのと同じ気が
「大文字は XHTML では間違い、でも一応表示するよ」というブラウザと
「間違いなので XHTML を書き直さないと表示しないよ」というブラウザ、
一方のやり方が間違ってる、というものではないと思う。
＃ブラウザなら、「ページは表示されるが警告が出る」ということにして
＃ユーザに注意を促し、順次移行させる、という手段もあるかもしれないが…
# mishimaは本田透先生を熱烈に応援しています
Re:文化の違い? (スコア:0)
体面的にはそうだけど、事実上 Linux ディストリビュータが旗振り
してて、また採用はほぼ Linux に限られてる状態では、
「Linux の標準としての FHS」
と取られても仕方ないのではないですか?
ま、正確を期すなら
「すべからく UNIX
Re:文化の違い? (スコア:0)
しかし、策定段階や策定後に然るべき標準化団体とか
UNIXベンダ・コミュニティへの呼びかけはあったの？
というか、*本当に* Linux以外で受け入れ可能なもの？
Re:文化の違い? (スコア:0)
> そうでなければ「この perl は一般の用途で利用すべきではない」とか
> ポリシーマニュアルに付け加えておくべき。
つーことは gcc も make も sh も awk も消さなくちゃいけなく
なりますが?
Re:文化の違い? (スコア:0)
> 体面的にはそうだけど、事実上 Linux ディストリビュータが旗振り
というようなモノを*BSDが取り入れるわきゃありませんわな。
Re:文化の違い? (スコア:0)
Re:文化の違い? (スコア:0)
> 便宜上同時にインストールしている『外部』ソフトウェアに過ぎない> ものが不要になったから外したよ、ってことでしょ？
これまでは、カーネルをビルドするために必要だったんじゃないの？
大体、ユーザランドも配布の一部だから混乱しなくてイイ、とか
言ってんでしょ？
Re:文化の違い? (スコア:0)
システムから削除
Re:文化の違い? (スコア:0)
「すべからく」に「全て」の意味はありません。
Re:文化の違い? (スコア:0)
Re:文化の違い? (スコア:1)
> > 便宜上同時にインストールしている『外部』ソフトウェアに過ぎない
便宜上同時にインストールしただけのものじゃないよ、
その後ユーザが使うことも考えられてるよ、
と逆説的にいってるんでしょ。
> あるいは「使っちゃダメ。使いたいなら別途いれろ」になりますが、
それを言ってるのはこっちの発言 [srad.jp]。
# mishimaは本田透先生を熱烈に応援しています
Re:文化の違い? (スコア:1)
> UNIXベンダ・コミュニティへの呼びかけはあったの？
返す言葉もございません。が、
> というか、*本当に* Linux以外で受け入れ可能なもの？
それについては
Debian BSDのML [debian.org]で語られてたっぽい。
＃まだ結論まで読めてない。
# mishimaは本田透先生を熱烈に応援しています
Re:文化の違い? (スコア:0)
という意見に対してFHSを出したところに、どうしてこういう反応が来るのだろう。
Re:文化の違い? (スコア:1)
どの ac を信じたらいいものやら。 というか、どれとどれが同一人物?
Re:文化の違い? (スコア:1)
たしかにそれは問題になりますね。ただし、如何ともしがたい、 というほど難問でもなくて、たとえばバイナリは /usr/bin/perl4 とか /usr/bin/perl5 とかでインストールするようにして、 /usr/bin/perl -> /usr/bin/perl5 とかいうふうにリンクを張るようにして、 複数のバージョンの perl をインストールしようとするとどちらに symlink するかを尋ねてくるようにしておく、とか。 (後から入れたほうを優先、などの決め打ちでも構わないと思うけど)。
まあ、(Perl に対して) バージョンアップのときに仕様を変えるのはやめてほしいな、 という話もあるけど。
そうですね。 perl の ports をインストールすると自動的に /usr/bin/perl -> /usr/local/bin/perl ができる、というのがいいかもね。
なるほど、そういうのが方法がありましたか... それでもいいですね。 (新規インストールのときにはたぶん問題にならないだろうし)。
Re:文化の違い? (スコア:1)
これは、/usr/bin/perlがなくなりました、というときの作業とそうかわりないのではないでしょうか。
Re:文化の違い? (スコア:1)
> /usr/local/bin/perl に変更になるのではないのですか?
そうとはいいきれないところがあるということでしょう。
/pkg/binとか/opt/binがすきなひととかもいるし。
ただ、おおくのひとはpackages/portsのデフォルトである/usr/local/binにいれることになるでしょうね。
また、4系統でもperl5.6をつかってるひとは、5にアップグレードしても、/usr/local/bin/perl(とか/opt/bin/perl)とかのままパスはかわらないかもしれません。
> 今後も Perl のパス名は /usr/bin/perl なのですか?
そういう選択もできます。
> どの ac を信じたらいいものやら。
むずかしいところです。多分みんなそうまちがったことはいってないとして妥当なモデルをかんがえるしかないかしら。
Re:-currentでは (スコア:0)
できないなら素直にLinuxでも使ってくれ。
それがBSDの文化です。
Re:-currentでは (スコア:1, 興味深い)
ユーザコミュニティ的にはそれでその場は解決するし、それが
正解だけど、そこで止まったらBSDじゃないと思う。
ユーザの中から「なんでこんなに腐ってるんだ」と怒るのが出てきて、
改良案とパッチを引っ提げてデベロッパーデビュー、とならなきゃ。
# 今回のはPerlのパスの一件はあまりに些末な問題だけど。
Re:-currentでは (スコア:0)