アカウント名:
パスワード:
ナニゲに {Free,Open,Net}BSDの Ports って、自分で Makefileをなどをいじることによって、自分の好みに応じた状態のソフトウェアをインストールできるというような楽しみや利便性があって、それはそれで非常にいいことだとは思う。 こんどは Debian のパッケージ管理の方針が取り入れられるとなると、アップデートしそこなっているパッケージのアップデートが半ば自動的におこなえるとか、その辺がありがたく思える。
本当はBSD の中心的なディストリビューションの部分が rpm またはそれ以上のパッケージ管理のシステムの元で管理が行えれば私
パッケージの自動管理は聞こえは魅力的です。しかし、パッケージ間の依存性に閉路ができてしまった場合の問題をあまりにnegletしすぎています。
例えば、Cyrus SASLはその認証用データベースとしてLDAPを利用することができます。したがって、OpenLDAPに依存させることができます。一方、OpenLDAPはその認証手段としてCyrus SASLを用いることができます。もしここでOpenLDAPをCyrus SASLに依存させた場合、依存性を両方とも満たすようにパッケージをmakeして欲しいわけです
あの... それって思いっきり閉路ができてるんですけど。正しくは
openldap-cyrus-sasl depends cyrus-sasl cyrus-sasl-openldap depends openldap
ではないですか?
一部のpackageはこのような命名規則で問題を回避しているように見えます(ほかにはlocalized softwareなど)。しかし、今度はopenldap-cyrus-saslとopenldapを同時にインストールした場合に問題が生じます。複数のpackageが同じ名前のfileを参照してしまいます。全てのfileが同一内容ならばreference count、全て異なるならばhash値などで管理できます。しかし、現実には中身が
一部のpackageはこのような命名規則で問題を回避しているように見えます(ほかにはlocalized softwareなど)。しかし、今度はopenldap-cyrus-saslとopenldapを同時にインストールした場合に問題が生じます。
PC-Unixのように(自分でmakeするような)packageが存在しないSolarisの方が実際には管理が楽になってしまっているのです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
パッケージ管理が便利になる(?) (スコア: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)
cyrus-sasl-openldap depends openldap-cyrus-sasl
とか別パッケージ同士にすれば駄目です? そういう話ではない?
どっちかというと依存関係の閉路と言うよりはバリエーションの増加によるパッケージメンテナの管理コストの増大が
問題になるだけではないかと。あとポリシーで問題になる可能性はあるかな。
toy system だと思
package化の真の目的 (スコア:1)
あの... それって思いっきり閉路ができてるんですけど。正しくは
ではないですか?
一部のpackageはこのような命名規則で問題を回避しているように見えます(ほかにはlocalized softwareなど)。しかし、今度はopenldap-cyrus-saslとopenldapを同時にインストールした場合に問題が生じます。複数のpackageが同じ名前のfileを参照してしまいます。全てのfileが同一内容ならばreference count、全て異なるならばhash値などで管理できます。しかし、現実には中身が
Re:package化の真の目的 (スコア:1)
パッケージの依存関係をインストール時に両パッケージ解決すればいいですよね。同時に両パッケージを持ってきて、インストール時に依存関係が互いに解消していることを確認しつつ一つのプロセス内で処理すれば済むと思います。Debian だとどう処理してましたっけ? こういう閉路は負荷でしたでしょうか? > 識者
deb でも rpm でも普通は conflicts を定義します(fooがfoo-barと conflict する場合には foo が入っていて foo-bar をinstallするとfooは先に削除される)し、deb の場合は異なるパッケージが同じファイルを上書き・削除する場合にはエラーないし警告になります。
Solaris ってパッケージが存在すると思うんですけど。
Sunfreeware.com(jp site) [sut.ac.jp]
など。お世辞にも優れたパッケージシステムとは思えませんが、そもそも pkgadd コマンドが存在しますよね。
そもそもパッケージで管理するのが楽かどうかはやりたいこととパッケージの形態に寄る問題であって、make だけで解決するのはインストール時はともかく、remove や upgrade の際に共有しているライブラリを不用意に削除したり上書きしたりする危険性から逃れられません。