アカウント名:
パスワード:
ナニゲに {Free,Open,Net}BSDの Ports って、自分で Makefileをなどをいじることによって、自分の好みに応じた状態のソフトウェアをインストールできるというような楽しみや利便性があって、それはそれで非常にいいことだとは思う。 こんどは Debian のパッケージ管理の方針が取り入れられるとなると、アップデートしそこなっているパッケージのアップデートが半ば自動的におこなえるとか、その辺がありがたく思える。
本当はBSD の中心的なディストリビューションの部分が rpm またはそれ以上のパッケージ管理のシステムの元で管理が行えれば私
パッケージの自動管理は聞こえは魅力的です。しかし、パッケージ間の依存性に閉路ができてしまった場合の問題をあまりにnegletしすぎています。
例えば、Cyrus SASLはその認証用データベースとしてLDAPを利用することができます。したがって、OpenLDAPに依存させることができます。一方、OpenLDAPはその認証手段としてCyrus SASLを用いることができます。もしここでOpenLDAPをCyrus SASLに依存させた場合、依存性を両方とも満たすようにパッケージをmakeして欲しいわけです
言わんとするところはわかりますけど。
それを全然やってくれないのでどうしても「パッケージ管理システム == toy system」というイメージになってしまいます。
つーのは極論の類に思えますね。楽に適用できる部分はパッケージで楽して、パッケージでうまく管理できないとこは自分でmakeして/usr/localに放り込んでおけば実用上何の問題もないので。toyでも何でも、便利で楽できるならそれでよし。聞こえだけじゃなく、日常の管理の上でもとっても魅力的です。ただ、魅力的だからといって、それで全てを解決しようとは思わない。ただ、どうせいずれも必要なものなら、ややこしい依存なんぞすっとばして、全部まとめた自前のパッケージ作っちゃうかもしれませんね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
パッケージ管理が便利になる(?) (スコア:1)
ナニゲに {Free,Open,Net}BSDの Ports って、自分で Makefileをなどをいじることによって、自分の好みに応じた状態のソフトウェアをインストールできるというような楽しみや利便性があって、それはそれで非常にいいことだとは思う。 こんどは Debian のパッケージ管理の方針が取り入れられるとなると、アップデートしそこなっているパッケージのアップデートが半ば自動的におこなえるとか、その辺がありがたく思える。
本当はBSD の中心的なディストリビューションの部分が rpm またはそれ以上のパッケージ管理のシステムの元で管理が行えれば私
依存性の循環を真正面から解いて欲しい (スコア:2, 興味深い)
パッケージの自動管理は聞こえは魅力的です。しかし、パッケージ間の依存性に閉路ができてしまった場合の問題をあまりにnegletしすぎています。
例えば、Cyrus SASLはその認証用データベースとしてLDAPを利用することができます。したがって、OpenLDAPに依存させることができます。一方、OpenLDAPはその認証手段としてCyrus SASLを用いることができます。もしここでOpenLDAPをCyrus SASLに依存させた場合、依存性を両方とも満たすようにパッケージをmakeして欲しいわけです
Re:依存性の循環を真正面から解いて欲しい (スコア:1)
言わんとするところはわかりますけど。
つーのは極論の類に思えますね。楽に適用できる部分はパッケージで楽して、パッケージでうまく管理できないとこは自分でmakeして/usr/localに放り込んでおけば実用上何の問題もないので。toyでも何でも、便利で楽できるならそれでよし。聞こえだけじゃなく、日常の管理の上でもとっても魅力的です。ただ、魅力的だからといって、それで全てを解決しようとは思わない。ただ、どうせいずれも必要なものなら、ややこしい依存なんぞすっとばして、全部まとめた自前のパッケージ作っちゃうかもしれませんね。