かなりの数のポートがインストールされたMacPortsをiMacにインストールしています。
ただし、Homebrewを試すことに興味があります。Homebrewについては多くの良い話を聞いたし、使用しているいくつかのツールの最新バージョンが含まれていることに気付いたからです。
しかし、2つは同じマシン上で共存できますか、それとも最初にMacPortsを完全にアンインストールする必要がありますか?
また、2つのcanを同時にインストールした場合、それらは互いに完全に独立していますか? Homebrewの機能の1つは、システムに既に含まれているもの(Pythonなど)の新しいバージョンを再インストールしないことです。これは、MacPortsによって既に保守されているバージョンのものがインストールされない場合にも適用されますか?
その後MacPortsをアンインストールするとどうなりますか?
それらはうまく共存しません。 Apple gccは、/ usr/localでいくつかのことを探します。これは、Macportsコンパイルが、ポーターが予期しないものを見つける可能性があることを意味します。/で見つかったものの例については、Macportsのメールリストとバグを参照してください。 usr/local。
私は 別の答え を同様の質問に与えました:
Homebrewが/ usr/localにインストールされている場合、ソースからソフトウェアをビルドするときに問題が発生します。これはデフォルトです。これは、このパスがコンパイラーや他のツールのデフォルトの検索パスにあるため、不適切な選択です。したがって、他のパッケージングソフトウェアからのビルドは、独自のバージョンではなくHomebrewのバージョンを使用して、誤った依存関係を取得する可能性があります。
数年前、プロジェクトのごく初期には、MacPortsでさえも/ usr/localを使用していました。しかし、FAQに記載されているように、他のツールと連携しないことが判明しました。残念ながら、自作の開発者は以前の経験について聞きたくなく、そのような事実を無視しました...
一般に、すべての問題を回避するために、通常は1つのツールのみを使用することをお勧めします。 MacPortsは、ハーコード化されたパスにパッチを適用するために最善を尽くしています。 Finkが使用する/ swに。したがって、通常は機能しますが、/ usr/localに何かをインストールすると、間違いなく問題が発生します。
[…]
私は、Gnuビルドツールが/usr/local
をどのように作成するかについての心配が偏執狂に陥っていると考えていました。ビルドツールexpectそこには多くのものが存在します。パッケージマネージャーの前の古き良き時代(冗談ですが)、/usr/local
にコンパイルしました。しかし、Autoconfは通常問題を解決しますが、多くのオープンソースプロジェクトの純粋なビルドの複雑さは問題を引き起こし、問題が発生したときにこれらの問題を元に戻すのが難しい場合があります。
ただし、Autoconfが/usr/local
の下に置くべきではないものを見つける際の問題のリスクは、Perl、Tcl、Rubyの2つ、3つ、または4つの異なるコピーがあり、それぞれが異なるカバレッジを持っているというメンテナンスの煩わしさについてバランスを取る必要があります。異なるパッケージライブラリ。不快。
MacPortsとFinkでの私の経験は、通常、まさにこれによって引き起こされた憤慨であり、ある時点で、昔ながらの方法で/usr/local
へのコンパイルに切り替えたので、Homebrewがそれをいじっていなかったことを嬉しく思いました。 MacPortsを/usr/local
にインストールするように設定してみましたが、MacPortsはそれを難しくしてしまいます。メーリングリストやバグトラッカーで助けを求める叫びに対処するときの動機は、自分自身の生活を楽にすることだと理解しています。デバッグの利便性は、ユーザーとしてあなたに影響を与える単純なものだけではありません。
Homebrewは、少なくともこの点で、以前と同じ方法で処理を行い、MacPortsは干渉しないようにしています。 Homebrewで必要なパッケージを文書化し、問題が発生した場合は/ usr/localをワイプして再インストールしてもかまわない場合は、問題が発生した場合にいつでも元に戻すことができます。また、/ usr/localの問題が通常はマシンに永続的な損傷を与えるリスクを伴わないことに気づいたら、リスクを取ることを自由に感じるかもしれません。
OSXでのパッケージングがFreeBSDよりもはるかに悪いことに注意します。Appleは、そのBSDサブシステムの使いやすさを気にしているようには見えません。
MacPorts FAQ によると:
2.3.0以降、MacPortsは/ usr/local(およびポートが依存しない他のすべてのファイル)をポートのビルドシステムから自動的に隠すことができることに注意してください。この機能はトレースモードと呼ばれ、ポートに-tフラグを指定することでアクティブになります。
Sudo port -t install <portname>
Homebrew Installation Pageによると、これは関連しています:
Homebrewが競合他社に比べてうまく機能する理由の1つは、/ usr/localにインストールすることをお勧めするためです。あなたの危険で別の接頭辞を選んでください!
したがって、個人的な経験はほとんどありませんが、MacPortのインストールに常に-tフラグを使用すると、MacPortsとHomebrewが同じシステムで共存することによるほとんどの問題を防ぐことができると私は考えています。最後の質問に答えます。MacPortsをアンインストールすると問題が発生する理由はわかりません。
私が何年もの間ポートを使用してきたコンピューターに自作をインストールしている間、これは私が読むことができるものです:
Warning: You have MacPorts or Fink installed:
/opt/local/bin/port
This can cause trouble. You don't have to uninstall them, but you may want to
temporarily move them out of the way, e.g.
Sudo mv /opt/local ~/macports
注意してください!
webappzeroのSudo port -t ...
ソリューションが役立ちます。正直に言うと、私はFink、MacPorts、Homebrewをすべて同時に実行し、MacPortsを無視して(とりあえず今のところ)、MacPortsからは取得できないものをインストールするために他の2つのどちらかのみを使用しています。 port -t
トリックを学ぶ前であっても、私はこの方法でいくつかの困難に遭遇しました。ただし、複数のパッケージマネージャーを使用して複雑な開発環境とサーバー環境を維持しようとしている場合は、少なくとも不快な世界にいることでしょう。 1つを選択し、他のものは避けますが、必死に必要なもののために、メインのものをパスの前に置きます。
AppleがApple以外のものを/ usr /にインストールすることを禁止するつもりである(または、おそらく彼らがすでにEl Crapitanでそれを行っている) Appleの強引なアプローチに同意するかどうかにかかわらず、Homebrewがデフォルトで他の何かを使用するようにデフォルト設定すると、問題が緩和されると思います。
結局、私はApple自身のポートをそれ自身のツリーに制限するという考えが好きです、それが/ usr /でなければいいのですが。彼らは/ System/bin /などを使って自分のものを分離したいので、コミュニティが管理する最新のソフトウェアで簡単にバイパスできます。