Безопасно ли устанавливать Homebrew и Macports на одну и ту же машину?

Question

На моем iMac установлены MacPorts с достаточным количеством установленных портов.

Тем не менее, я заинтересован в том, чтобы попробовать Homebrew, поскольку слышал о нем много хорошего и потому, что заметил, что он содержит более свежие версии нескольких инструментов, которые я использую.

Но могут ли они сосуществовать на одном компьютере или мне нужно сначала полностью удалить MacPorts?

Кроме того, если они могут быть установлены одновременно, будут ли они полностью независимы друг от друга? Одной из особенностей Homebrew является то, что он не переустанавливает новые версии вещей, которые уже включены в систему (например, python). Это также распространяется на то, что он не устанавливает версии вещей, которые уже поддерживаются MacPorts?

Что произойдет, если я впоследствии удалю MacPorts?

Answer 1

Они не будут хорошо сосуществовать вместе. Apple gcc ищет в /usr /local некоторые вещи. Это означает, что компиляция macports может найти то, чего не ожидал портер. Посмотрите списки рассылки и ошибки macports для примеров того, что можно найти в /usr /local.

Answer 2

Я дал другой ответ на аналогичный вопрос:

Homebrew вызовет проблемы при сборке программного обеспечения из исходного кода, если оно установлено в /usr /local. Это значение по умолчанию, что является плохим выбором, так как этот путь находится в пути поиска по умолчанию для компиляторов и других инструментов. Поэтому сборки из другого программного обеспечения для упаковки могут получить неправильную зависимость, используя версию Homebrew вместо своей собственной.

Несколько лет назад, в самом начале проекта, даже MacPorts использовал /usr /local. Но оказалось, что не сотрудничать с другими инструментами, как это задокументировано в их FAQ. К сожалению, разработчики Homebrew не хотели слышать о предыдущем опыте и игнорировали такие факты ...

Как правило, лучше всего придерживаться одного инструмента, чтобы избежать всех проблем. MacPorts делает все возможное, чтобы исправлять любые путевые пути, например, к /sw, который используется Fink. Так что обычно это работает, но установка чего-либо в /usr /local определенно вызовет проблемы.

[...]

Answer 3

Раньше я думал, что беспокойство по поводу того, что инструменты сборки Gnu сделают из /usr/local было на грани параноика. Инструменты сборки ожидают, что там будет много чего: в старые добрые времена перед менеджерами пакетов (я шучу) мы компилировали все, что угодно, в /usr/local . Но в то время как Autoconf обычно обнаруживает проблемы, сложность сборки многих проектов с открытым исходным кодом действительно вызывает проблемы, и эти проблемы могут быть трудно устранить, когда вы сталкиваетесь с трудностями.

Но риск проблем с тем, что Autoconf найдет что-то, чего не должно быть в /usr/local должен быть сбалансирован из-за неудобств, связанных с обслуживанием, имеющих две, три или четыре разные копии Perl, Tcl и Ruby, каждая с разным охватом своих разные библиотеки пакетов. Неприятно.

Так как мой опыт работы с MacPorts и Fink, как правило, был раздражением, вызванным именно этим, и в какой-то момент переключился на компиляцию старомодного пути в /usr/local , я был рад видеть, что Homebrew не связывался с этим. Я пытался настроить MacPorts для установки в /usr/local , но MacPorts делает все возможное, чтобы сделать это трудным. Я понимаю, что мотивация состоит в том, чтобы облегчить себе жизнь, когда имеешь дело с криками о помощи в их списке рассылки и баг-трекере: имейте в виду, что, хотя мы должны уважать усилия сборщиков-добровольцев и относиться к их драгоценному времени удобство отладки - не единственный вид простоты, который влияет на вас как пользователя.

Homebrew, по крайней мере, в этом отношении, делает все так, как раньше, и MacPorts старается не вмешиваться. Если вы готовы задокументировать, какие пакеты вам нужны, с помощью Homebrew, а также очистить и переустановить /usr /local в случае затруднений, вы всегда можете вернуться в случае, если что-то пойдет не так. И как только вы поймете, что проблемы в /usr /local обычно не несут в себе риска нанести непоправимый ущерб вашим машинам, вы можете чувствовать себя более свободными, чтобы рисковать.

Я просто отмечу, насколько хуже упаковка в OSX, чем во FreeBSD: Apple, похоже, не особо заботится о удобстве использования своего подсистемы BSD, потому что это проблема, с которой они могут помочь.

Answer 4

Согласно MacPorts FAQ:

Обратите внимание, что начиная с 2.3.0, MacPorts может автоматически скрывать /usr /local (и все другие файлы, от которых порт не зависит) от систем сборки портов. Эта функция называется режимом трассировки и активируется путем предоставления флага -t для порта, например

sudo port -t install <portname>

Это актуально, потому что согласно странице установки Homebrew:

Одна из причин, по которой Homebrew работает по отношению к конкурентам, заключается в том, что мы рекомендуем установить в /usr /local. Выберите другой префикс на свой страх и риск!

Поэтому, имея небольшой личный опыт, я предполагаю, что всегда использование флага -t для установок MacPort должно предотвратить большинство проблем, связанных с сосуществованием MacPorts и Homebrew в одной и той же системе. Чтобы ответить на ваш последний вопрос: я не вижу причин, по которым удаление MacPorts могло бы вызвать проблемы.

Answer 5

При установке homebrew на компьютер, где я годами использую порты, вот что я могу прочитать:

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

Быть осторожен!

Answer 6

Решение sudo port -t ... webappzero должно помочь. Если честно, я работаю с Fink, MacPorts и Homebrew одновременно, с уважением к MacPorts (пока что в любом случае), и использую только два других для установки вещей, которые я не могу получить от MacPorts. Таким образом, я столкнулся с очень немногими трудностями, даже до того, как изучил трюк с port -t . Если вы пытаетесь использовать несколько менеджеров пакетов для поддержки сложных сред разработки и серверов, вы, вероятно, по крайней мере испытываете дискомфорт. Выберите один и избегайте других, но для чего-то, в чем вы отчаянно нуждаетесь от них, и поставьте главный на пути раньше.

Если то, что я слышал, правда о том, что Apple собирается запретить установку чего-либо в /usr /, отличную от собственной Apple (или, может быть, они уже делают это в El Crapitan, которую я избегаю "повышать" до более проблемы с ним решены), я полагаю, что это уменьшит проблему после того, как Homebrew по умолчанию использует что-то другое - согласны ли мы с жестким подходом Apple или нет.

В конце концов, мне нравится идея ограничить собственные порты Apple своим собственным деревом, я просто хочу, чтобы это не было /usr /. Я бы предпочел, чтобы они использовали /System /bin / и т.д., И т.д., Чтобы изолировать свои собственные вещи, чтобы мне было проще обойти их с помощью современного программного обеспечения, поддерживаемого сообществом.