アカウント名:
パスワード:
ナニゲに {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値などで管理できます。しかし、現実には中身が同じfileもあれば異なるfileもあります。そのような情報はどこに記述するんでしょうか? 個々のpackage? それはそれでやりたがる人がいるかどうか...
実際、わたしはpackageを導入することのメリットに本質的な疑問を感じています。というのは、PC-Unixのように(自分でmakeするような)packageが存在しないSolarisの方が実際には管理が楽になってしまっているのです。最初に述べた、依存性の閉路を作る可能性のあるsoftwareはたいていautoconfを利用しています。したがって、config.status(皆さん使ってますよね?)に残った前回のconfigurationを必要な依存性に応じて再定義すれば、後はmakeの順序を考えるだけで問題が解けてしまいます。最初の例ならば、例えば
となるわけです。packageがこれを機械的に導出し、しかるべき手順をとってくれればpackage数が減らせてpackage管理者が助かりますし、ユーザも自分の指定した機能をどおりにmakeできるのでうれしいわけです。逆にそれができないならば、make順序の制約が不必要に狭すぎるpackageを使うのはかえって損になってしまいます。
一部のpackageはこのような命名規則で問題を回避しているように見えます(ほかにはlocalized softwareなど)。しかし、今度はopenldap-cyrus-saslとopenldapを同時にインストールした場合に問題が生じます。
PC-Unixのように(自分でmakeするような)packageが存在しないSolarisの方が実際には管理が楽になってしまっているのです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
パッケージ管理が便利になる(?) (スコア: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 だと思うかどうかはその人次第ですね。私はパッケージ無いと面倒で死にますけど。
現実には必要な機能があるかないかで使うかどうかを判断するだけなので、neglect と言うか
使うメリットでメリットを天秤にかけるだけだと思ってます。
package化の真の目的 (スコア:1)
あの... それって思いっきり閉路ができてるんですけど。正しくは
ではないですか?
一部のpackageはこのような命名規則で問題を回避しているように見えます(ほかにはlocalized softwareなど)。しかし、今度はopenldap-cyrus-saslとopenldapを同時にインストールした場合に問題が生じます。複数のpackageが同じ名前のfileを参照してしまいます。全てのfileが同一内容ならばreference count、全て異なるならばhash値などで管理できます。しかし、現実には中身が同じfileもあれば異なるfileもあります。そのような情報はどこに記述するんでしょうか? 個々のpackage? それはそれでやりたがる人がいるかどうか...
実際、わたしはpackageを導入することのメリットに本質的な疑問を感じています。というのは、PC-Unixのように(自分でmakeするような)packageが存在しないSolarisの方が実際には管理が楽になってしまっているのです。最初に述べた、依存性の閉路を作る可能性のあるsoftwareはたいていautoconfを利用しています。したがって、config.status(皆さん使ってますよね?)に残った前回のconfigurationを必要な依存性に応じて再定義すれば、後はmakeの順序を考えるだけで問題が解けてしまいます。最初の例ならば、例えば
となるわけです。packageがこれを機械的に導出し、しかるべき手順をとってくれればpackage数が減らせてpackage管理者が助かりますし、ユーザも自分の指定した機能をどおりにmakeできるのでうれしいわけです。逆にそれができないならば、make順序の制約が不必要に狭すぎるpackageを使うのはかえって損になってしまいます。
Re:package化の真の目的 (スコア:1)
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 の際に共有しているライブラリを不用意に削除したり上書きしたりする危険性から逃れられません。