パスワードを忘れた? アカウント作成
6440 story

GentooのPortageをOpenBSDとFreeBSD に 68

ストーリー by Oliver
好きなものでミックスジュース 部門より

ababincho曰く、"OpenBSD Journal記事により。Gentoo LinuxPortageを、OpenBSDFreeBSD移植する試みがはじまっています。/ で tarball を展開してインストールするようです。/etc/make.conf が競合するのではないかと思うのですが、どうなんでしょう?"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2003年09月01日 13時07分 (#389218)
    Portupgrade の話題が [slashdot.org]。

    合わせて読みませう。
  • by Anonymous Coward on 2003年09月01日 13時20分 (#389225)
    最近だな、portage と portsの比較が、
    いつのまにか portage と Makefileの比較になってる人を
    たまに見かけるんだな。
    Makefileと比較すんなら.ebuildファイル。

    このことは、逆に言えば、
    「ディストリビューションのパッケージ管理」とは別に
    「パッケージの記述法(automake/autoconfな世界のお約束)」
    にも、そろそろ大幅な改良が起こりうるかもな、
    てな妄想に繋がって、興味深いというか怖いというか。

    そういう大変化には、若輩ゆえ出会ってないんですが、
    どんなもんなんでしょ。

    #意味なくAC
    • by Dubhead (1033) on 2003年09月01日 14時55分 (#389264) ホームページ 日記
      Vimで有名なBram Moolenaar氏が、makeやパッケージ管理を統合するようなソフトを作り始めてますね。ページはこちら [a-a-p.org]。
      親コメント
    • 結局、「まともな」パッケージングをする上ではパッケージシステムだけでは
      限界があるんですよね。
      各ソフトがモジュラリティについて考慮してくれないと、
      依存関係が大きくなりすぎることがある。
      こういうのは、ビルドシステムも含めた全体のコンポーネント化の
      仕組みがないと解決が困難なのは事実でしょうね。
      • by SteppingWind (2654) on 2003年09月01日 18時10分 (#389335)

        いや, それ以前に「パッケージ」と言う呼び方で一くくりにするには, カーネルモジュールやライブラリみたいなプリミティブな物からinstant-workstationみたいな環境セットと言ったほうがよさそうな物まで, あまりにも階層が違う物が有るわけで. 他にもパッケージ間の衝突なんて問題もあるので, 一筋縄ではいかないと思います.

        思うに, パッケージ管理についてもOS的な階層化と各階層毎のインターフェイスの定型化, それにVM的な環境の分離といったことが必要になるのではないでしょうか? FreeBSDなら標準でjailが使えるので, こういったパッケージ管理の構造化を試してみるのも面白いかもしれませんね.

        親コメント
        • > パッケージ管理についてもOS的な階層化と各階層毎のインターフェイスの定型化

          結局のところ、それが「コンポーネント化」(の一部分)なんですね。

          > それにVM的な環境の分離といったことが必要になるのではないでしょうか?
          > FreeBSDなら標準でjailが使えるので, こういったパッケージ管理の
          > 構造化を試してみるのも面白いかもしれませんね.

          VM というか、インターフェースの世代の問題で、一つのコンポーネントの
          世代の異なる複数の版を同一システム内
          • by G7 (3009) on 2003年09月02日 3時58分 (#389544)
            >> パッケージ管理についてもOS的な階層化と各階層毎のインターフェイスの定型化
            >結局のところ、それが「コンポーネント化」(の一部分)なんですね。

            ここらへんは、インターフェース「される(?)」対象物を
            はっきり一種類(ただし抽象的だが)の「オブジェクト」なるものに
            絞ってしまったオブジェクト指向に、一日の長が有るように思います。

            卑近なところでいえばJavaかな。Javaの*.class(とそれの集まりである*.jar)ファイルとか。
            C言語(アセンブラ?)ベースのリンクシステムより格段に扱いが楽になってる。
            あれが扱い易いのは、まず最初に扱「われる」ものの性質をきっちり(使いやすい形に)決めてしまったから、だよね。

            #Javaの「1クラス=1ファイル」という思い切りは、なかなか慧眼だと思う。
            #1クラス=1ファイルということは、複数のファイルを実行時より前に結合することを敢えて諦めるという意味でもある。
            #クラスファイルどうしが「くっつく」ことが無いから、常に単体の単位で扱えるので、問題が複雑化しにくい。
            #また、クラスという論理単位とファイルという物理単位を常に一致させると、管理がし易い。

            で、オブジェクト指向のオブジェクトやクラスと比べると、
            Unix(やその他のありがちなOS)でいうところのプログラムやライブラリの切り分け単位は、
            ちとばっかり曖昧模糊としていて、扱いにくいです。
            だから、それの束ね方の問題であるところのパッケージも、なかなかすっきりしない…

            #MakeよりAntのほうが良いと言われても、XMLだとどうもピンと来なくて困ってるG7
            #たしかにMakeそのものはかなりヤラシイが。

            >> それにVM的な環境の分離といったことが必要になるのではないでしょうか?
            >VM というか、インターフェースの世代の問題で、一つのコンポーネントの
            >世代の異なる複数の版を同一システム内に同居させなければならない、

            コンポーネントって、
            実行時の仮想マシン(プロセス含む)同士の関連のさせかたの問題として捉える文脈も見かけるし、
            一方でコンパイル&結合時のライブラリ同士の関連のさせかたの問題として捉える文脈も見かけます。

            どっちが正統&正当なのかは俺はよく判りません。どっちもありなのかな…

            ># それをやろうとしたのが ActiveX ではある。

            Unixより後の世代のOSは、きっとどれも(期待と誇張を含むが)、
            そういう方向性を打ち出してるような気がする。

            ただし、失敗することも有るけどね。
            例えば、なまじ綺麗に部品化できるもんだから、悪辣なプログラムを綺麗に部品化して配布してしまってたり、
            悪辣な部品を配布されてしまったり(=ウイルス?ワーム?)ということも出来るようになってしまう。
            こういう仕組みをOS(特にNetworkつき)に導入する場合は、以前以上にセキュリティとかには気をつけた基本設計が要求されるようです。

            #自作のScript言語の中ならばアクセス制御が欲しいとは思わないが、この仕組みがそのままOSになっても良いとは、ちょっと思えない…
            親コメント
  • by Anonymous Coward on 2003年09月01日 17時09分 (#389321)
    pythonよりruby萌えなのでportupgrade使い続けるかな~。
typodupeerror

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

読み込み中...