Ubuntu LinuxからMacに移行したばかりで、すべてが新しく、多くのことを再学習しています。

Linuxでは、ソフトウェアパッケージを管理するための優れたapt-getがありました。 Macで別の方法をグーグルで検索し、MacPorts、Fink、Homebrewについて見つけました。

このコンピューターを主にRubyonRailsアプリケーションの開発に使用します。

では、違いは何ですか。それら？良い面と悪い面はどちらですか？どれが最もよく維持され、より多くのパッケージがありますか？

コメント

  • 実際の質問に一致するようにタイトルを編集しました。ほとんどのStackExchangeサイトでは、”最高の”を求める質問が嫌われています。
  • なぜ必要なのですかこれらのうち’ t ruby ‘の宝石で十分ですか？
  • 重複がない理由の詳細については’常に悪い： apple.stackexchange.com/questions/11461/ … 他にもいくつかの選択肢があります
  • 自分で使用したことはありませんが、 pkgin との比較も役立つでしょう。

回答

間違いなく自作。私はFinkから始めて、MacPorts（より幸せ）、そしてHomebrew（はるかに幸せ）に切り替えました。それぞれを使用する理由は次のとおりです（必要に応じてプロリスト）：

Fink

  • Aptベース-Debianベースの場合は自宅にいるように感じます環境
  • バイナリパッケージ-パッケージはバイナリとして利用できるため、コンパイル時間が長くなりません。実際には、事前にコンパイルされたバイナリは常に古く、システム用にコンパイルする必要があることがわかりました。

MacPorts

  • 自作とは異なり、将来変更される可能性のあるMacOSライブラリに依存しません。
  • / opt / localにすべてをインストールします
  • 素敵なバリアントシステムビルドをカスタマイズできるa>
  • 簡単で直感的なポートファイル、独自のポートファイルを追加することもできます
  • PowerPCバージョンを含むTigerに戻るOSXとmacosの多くのバージョンをサポートしています。 その他の回答

自作

  • OSXに付属するものを最大限に活用します。 FinkまたはMacPorts。小さなRubyベースのツールをインストールするためだけにrubyとライブラリを最初からビルド/インストールする必要はありません。
  • /usr/local
  • ルートアクセスなしでインストール
  • インストールされたすべてのパッケージは、独自のセラーにきれいにサンドボックス化されているため、ビンや人などからのシンボリックリンクだけで、システム全体に漂遊ファイルを保存します。
  • 独自の数式ファイルを作成するためのガイドと自動化があります。 （つまり、パッケージ記述子）
  • rubyで記述され、すべての式は簡潔なrubyスクリプトです
  • バイナリがプリコンパイルされているためインストールが速くなります

pkgin

  • バイナリがプリコンパイルされているためインストールが速くなります
  • / opt / pkg /にインストールされているものすべて
  • pkgsrcコミュニティとJoyentに支えられています
  • NetBSD、DragonFly BSD、Solaris、Debian、Mac OS X、Minixで動作することが知られています

https://pkgsrc.joyent.com/install-on-osx/

http://pkgin.net/

コメント

Answer

MacPorts

Mac OS Xからの独立性が高いため、MacPortsはすでに存在するシステムライブラリとソフトウェアの多くを無視します。 Mac OS Xで利用可能で、代わりに独自のものをプルします。これは、インストールするユーティリティに大きなライブラリとソフトウェアのセットが必要な場合は遅くなる可能性があります。

ただし、インストールしたパッケージは、Appleのシステムアップデート/アップグレードの影響を受けにくいため、この種の選択の方が安全です。手順。

自作

既存のMacOS Xにインストールされているパッケージへの依存度が高いため、パッケージのインストールが高速化され、冗長なライブラリが最小限に抑えられます。

しかし、インストールされたパッケージが壊れている可能性があるnAppleのシステムアップデート/アップグレードのため。

したがって、これらは2つの異なる種類のトレードオフです。

また、Homebrewが / usr / local デフォルトでは、一部の人々はこれを嫌います unix-traditionと競合し、すでに何か（MySQLなど）をインストールしている場合は問題が発生する可能性があります。）

これらの違いは別として、これら2つが提供できるパッケージを考慮して、MacPorts / Homebrewが既にインストールされているかどうかを次の2つのコマンドで確認できます。これにより、現在提供されているパッケージが表示されます。 

port list | wc -l brew search | wc -l

MacPortsにはHomebrewよりもはるかに多くのパッケージがあることがわかります。

（2016年5月13日の19399対3583）

コメント

  • パッケージ数の違いについてのコメントとして：Homebrewには、独自のパッケージシステム（rubygems /）を持つプログラミング言語用のパッケージは含まれていません。 pip / cpan…）または間違いなくより適切なOS Xインストーラーが利用可能なソフトウェア（MacTeX）。また、重複した古いバージョンはデフォルトのリポジトリにはありませんが、代替の tap リポジトリに含まれています。これをmacportsと比較してください。macportsには、含まれているすべてのPythonバージョンのIPythonポートが含まれています。これは、macportsのパッケージ数を自然に増やすという別の哲学です。
  • 優れたリンクです！ terrychay.com/article/macports-vs-homebrew.shtml ありがとうございます！
  • @YaOz、確かに自作を変更して何かを使用することができます/usr/local以外ですか？
  • @Pacerier /usr/local/以外は「サポートされていない」または「推奨されていない」と思います。

回答

少なくとも2014年後半頃、本当のように思える自分の考えをいくつか追加するだけです。 。

数年前の時点で、自作はマインドシェアの点で間違いなく優位に立っています。 「MacPortsが全世界を引き寄せる」対「Homebrewはあなたがすでに持っているものを利用する」ということのために、Homebrewでどれほど幸せかについて話している人々がいるブログがたくさんあります。

しかし、IMO、MacPortsは数年前とは別の獣です。私が最初にOS Xに切り替えたとき、&はMacPortsを使用していましたが、MPの哲学は確かに苛立たしいものでした。ほとんどすべてがソースから構築されたためです。新規インストールは特に苦痛/時間がかかりました。しかし、過去1年ほど、純粋に私自身の印象に基づくと、MPパッケージの90％がバイナリであるようです&なので、インストールは実際には非常に高速です。私が収集したところによると、Homebrewも「ボトル」でこの方向に進んでいますが、現時点でHB経由でインストールするもののほとんどはソースからコンパイルされるという印象を受けます。

したがって、反対意見を提供するだけであれば、MacPortsは実際には「より速い」ようです。最近のption。ただし、MPに関するほとんどの人々の意見は、2011年から2012年頃の経験に基づいているようです。&はこれを実際には考慮していません。私は通常のHBユーザーではないので（そして両方を並べて使用するのはかなり苦痛です）、これを一粒の塩と一緒に取ってください。

HBにはおそらく「勝つ」という利点があると思います。長期的には「戦争」

  • HBはすべてRubyですが、MacPortsとそのパッケージ式はTCLで書かれていますが、これは必ずしも人気のあるスクリプト言語ではありません。独自のポートファイルを作成するのは非常に簡単です。
  • HBはGitHub &をベースにしているため、MacPortsは独自のSVNリポジトリをどこかにホストしているのに対し、新しい貢献者にははるかに歓迎されているようです。これは基本的に、私が思う両方のプロジェクトの年齢の違いを反映していると思います。
  • 前述のように、一般的なコンセンサスは、MacPortsがHB &に取って代わられたということです。間違って、それはそれに向かってより多くの人々を引き付けます。

そうでなければYaOZl & kLyは、sudo、依存関係などの点で主な違いをかなりうまくカバーしました。私 MacPortsは、他のプログラムが/opt/localにあることを期待していない、root権限でインストールされているなどの点で頭痛の種になることがあります& MacPortsと一緒にインストールしないのが一般的に最適なものがいくつかあります（例： RailsはMacPorts経由でインストールできますが、Rubyの通常のGem管理経由でインストールしないのはおかしいでしょう）。それ以外は、私は「独自の小さな世界を構築するというMacPortsの哲学の大ファンです&パッケージ化されたOSXライブラリに依存していません-それが機能するとき、そしてほとんどすべてが機能するとき非常にシンプルです。これがパッケージマネージャーに本当に必要なことです。そして、前述したように、現時点では、ほとんどの設定をすばやく行うことができます。

その一部が役に立ったことを願っています。

コメント

  • “前述のように、MacPortsはHB

は、正しいか間違っているかを問わず、より多くの人々を引き付けます。” …これは非常に表面的な発言のように感じます…人気があることと品質を提供することは同じではなく、2番目が”最初のものに取って代わられることを意味するものではありません。

  • MacPortsは現在Githubを使用しています。 guide.macports.org/#project.github を参照してください：” MacPortsプロジェクトはGit分散バージョン管理システムを使用していますプロジェクト全体のコードを管理します。マスターリポジトリはGitHubでホストされています。 MacPortsシステム自体、MacPortsポート、そして今読んでいるガイドのGitHubリポジトリを含む、ほぼすべてのプロジェクトコードとドキュメントの公開リポジトリを維持しています。”

    • 回答

    他の回答（これまでのところ）が言及していないように見えるのは、MacPortsは、macOSのレガシーバージョンを優れた方法でサポートしています。Homebrewは、現在AppleがサポートしているOSのみをサポートしています。これは通常、最後の3つのリリースを意味します。たとえば、2020年8月の時点で、Catalina、Mojave、HighSierraのみがHomebrewと互換性があります。

    対照的に、MacPortsはTiger（！）にインストールでき、プロジェクトはソフトウェアを保持するための特別なパッチを維持しています可能な限り作業します。また、新しいバージョンのmacOSから古いバージョンにシンボルをバックポートする”レガシーサポート”ライブラリも維持しています。コンパイル中にこのライブラリにリンクすると、あらゆる種類の新しいソフトウェアが古いシステムで突然動作する可能性があります！

    したがって、古いバージョンのmacOSを実行している場合、またはAppleの有効期限を過ぎた現在のOS、それは間違いなくMacPortsを採用する理由です。

    回答

    醸造は完全にスムーズに使えるので、短所がわかりません。 MacPortsのいくつかの欠点：

    最初の2つのポイントについて非常に人気のある質問がいくつかあります。

    コメント

    • これは私の経験でしたImageMagickを10.6にインストールします。brewは非常に簡単でしたが、’ JP2デリゲートを含めます。 imagemagick.org/script/binary-releases.php
    • brewとmacportsにはXcodeコマンドラインツールが必要なので、ここでも同じです。
    • @Mark I ‘意味がわかりませんが、Xcodeがなくてもbrewは完璧に機能しました。
    • あなた’ brew および MacPorts用のコンパイラが必要です。これは、Xcodeコマンドラインツールを介してインストールできます。 Xcode アプリケーションは必要ありません。
    • ファイアウォールの背後にあるときに同期するのがいかに醜いのか忘れてしまいました…そうです！

    コメントを残す

    メールアドレスが公開されることはありません。 * が付いている欄は必須項目です