アカウント名:
パスワード:
-currentの方では、すでにperlなしでkernelが作れるようになっています。hintsを作るscriptがまだ残っていますが、kernelを作る時に使うものではありません。
また、この変更はMFCされません。4-stableは最後までperlつきです(多分「CDやDVDでは...」は本当はこういう意味?)。-currentでは近いうちにportsなどによってのみperlをinstallすることになります。
FreeBSD システムの側で面倒見てくれないの?
そんなこといったら、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)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
-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で何にもできないような期がするが
文化の違い? (スコア:1)
Re:文化の違い? (スコア:2, すばらしい洞察)
そんなこといったら、httpdなんて各OSの提供するportsやrpmとかで
インストールされるディレクトリパスが違うぞ。
linuxの場合ディスストリ毎にperlのパスも違うんじゃないか?
どれも同じパスでっていうならオリジナルソースから
インストールすればいいじゃん。
それなら各OS間の違いも吸収できるし
昨今のLinuxのそのいたせりつくせり状態は
堕落させるじゃなくて、
インストール放置猿 量産の温床な気がするんだが
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:文化の違い? (スコア: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:文化の違い? (スコア:0)
何かすりゃ、どっかに影響くらいでるだろうよ。
その対策をしても、それによって影響がでる。
さらに対策をしても影響がでる、（略）。
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 を信じたらいいものやら。
むずかしいところです。多分みんなそうまちがったことはいってないとして妥当なモデルをかんがえるしかないかしら。