アカウント名:
パスワード:
ナニゲに {Free,Open,Net}BSDの Ports って、自分で Makefileをなどをいじることによって、自分の好みに応じた状態のソフトウェアをインストールできるというような楽しみや利便性があって、それはそれで非常にいいことだとは思う。 こんどは Debian のパッケージ管理の方針が取り入れられるとなると、アップデートしそこなっているパッケージのアップデートが半ば自動的におこなえるとか、その辺がありがたく思える。
本当はBSD の中心的なディストリビューションの部分が rpm またはそれ以上のパッケージ管理のシステムの元で管理が行えれば私
>ただただ私的に BSD で気に入らないのが /{etc,bin,sbin,usr/{sbin,bin,lib,share}} あたりのファイルが単に tar とか pax とかでインストールされて、 あとは放置プレイされていることなのです。
うーん, このあたりは*BSDではベースシステム(この概念はLinux distributionには無いですね)なので, cvsupでソースを更新してmake world(慎重にするならmake buildworld, kernel再作成, make install worldですが)とmergemasterで一式まとめて足並みそろえてメンテナンスできるので, それほど問題には感じていません. この点むしろ*BSDの方がソース指向なのかもしれません. 特に更新で問題が発生した場合にCVSと組み合わせて, 一定の位置まで戻すことが比較的簡単にできるのは大きいように思えます.
ただ, FreeBSD等でもベースシステムのバイナリパッチの必要性は認識されていて現在開発中です. もっとも, 実際に戻し機能付きのバイナリパッチパッケージシステム(HP-UXです)を使った経験では, 前バージョンのモジュールを保存しておく領域がかなり必要になって, パーティション切りの計画が狂ってしまったことが何回か有りますので痛しかゆしというところでしょうか.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
パッケージ管理が便利になる(?) (スコア:1)
ナニゲに {Free,Open,Net}BSDの Ports って、自分で Makefileをなどをいじることによって、自分の好みに応じた状態のソフトウェアをインストールできるというような楽しみや利便性があって、それはそれで非常にいいことだとは思う。 こんどは Debian のパッケージ管理の方針が取り入れられるとなると、アップデートしそこなっているパッケージのアップデートが半ば自動的におこなえるとか、その辺がありがたく思える。
本当はBSD の中心的なディストリビューションの部分が rpm またはそれ以上のパッケージ管理のシステムの元で管理が行えれば私
Re:パッケージ管理が便利になる(?) (スコア:2, 参考になる)
>ただただ私的に BSD で気に入らないのが /{etc,bin,sbin,usr/{sbin,bin,lib,share}} あたりのファイルが単に tar とか pax とかでインストールされて、 あとは放置プレイされていることなのです。
うーん, このあたりは*BSDではベースシステム(この概念はLinux distributionには無いですね)なので, cvsupでソースを更新してmake world(慎重にするならmake buildworld, kernel再作成, make install worldですが)とmergemasterで一式まとめて足並みそろえてメンテナンスできるので, それほど問題には感じていません. この点むしろ*BSDの方がソース指向なのかもしれません. 特に更新で問題が発生した場合にCVSと組み合わせて, 一定の位置まで戻すことが比較的簡単にできるのは大きいように思えます.
ただ, FreeBSD等でもベースシステムのバイナリパッチの必要性は認識されていて現在開発中です. もっとも, 実際に戻し機能付きのバイナリパッチパッケージシステム(HP-UXです)を使った経験では, 前バージョンのモジュールを保存しておく領域がかなり必要になって, パーティション切りの計画が狂ってしまったことが何回か有りますので痛しかゆしというところでしょうか.