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

35225
Rich

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

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

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

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

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

68

6 ответов на вопрос

22
Mark

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

Я только очень бегло посмотрел на homebrew, но если вы изменили место установки homebrew по умолчанию с / usr / local на что-то вроде / opt / homebrew / usr / local, можно ли избежать этой проблемы? Babu 14 лет назад 4
@Babu - Согласно Brew, вы должны [действовать с осторожностью] (https://github.com/mxcl/homebrew/wiki/Installation#wiki-fn4) Peter Ajtai 12 лет назад 0
@babu - возможно, но будут проблемы с тем, какой из homebrew или macports является первым для пути, а другой выбирает эти исполняемые файлы, и я подозреваю, что порты любой системы не полностью протестированы с использованием другого пути Mark 12 лет назад 0
17
raimue

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

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

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

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

[...]

Похоже, можно также установить homebrew в `~ / .homebrew`. Будет ли он по-прежнему мешать работе MacPorts, если он там установлен? Behrang 12 лет назад 0
Любое другое место, кроме / usr / local, должно быть в порядке. raimue 12 лет назад 0
Хорошо ли будут сосуществовать MacPort и Homebrew, если установить Homebrew в / opt / local, где установлен MacPort? Adam L. S. 10 лет назад 0
Вам не следует устанавливать другое программное обеспечение вручную в / opt / local, если MacPorts там уже установлен. Это определенно помешает, когда вы поместите туда файлы, которые не известны MacPorts, что приведет к конфликтам при установке портов. raimue 10 лет назад 1
8
Charles Stewart

Раньше я думал, что беспокойство по поводу того, из чего будут делать инструменты сборки 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, потому что это проблема, с которой они могут помочь.

Ну, мой вопрос задается с точки зрения тупого пользователя, который просто использует менеджер пакетов, чтобы "получить материал". Нет никакой уверенности в том, что я смогу «немного разобраться в себе, если что-то пойдет не так». Тем не менее, в любом случае upvote за дополнительные разъяснения. Спасибо! Rich 13 лет назад 0
MacPorts как веские основания не использовать / usr / local, см. Http://trac.macports.org/wiki/FAQ#defaultprefix raimue 13 лет назад 1
@Raim: веские причины для них - это в значительной степени компромисс между их удобством отслеживания ошибок и простотой установки на компьютере пользователя. Я забочусь о последнем. Charles Stewart 13 лет назад 3
Количество вещей, которые могут пойти не так, потому что кто-то (или что-то) установил копию $ lib в `/ usr / local`, бесконечно. Архитектуры, версии, настроенные функции и флаги, частичные установки, устаревшие установки с проблемами безопасности, а также и и будут вызывать проблемы. Конечно, продолжайте, если вы знаете, что делаете, но не сообщайте об ошибках. Опыт показывает, что люди в любом случае регистрируют ошибки, и именно поэтому существует режим трассировки (`-t`, см. Ниже) и почему избегание` / usr / local` является рекомендацией по умолчанию. neverpanic 9 лет назад 0
@neverpanic - Мое мнение о рисках компиляции всего в / usr / local изменилось с тех пор, как я написал этот ответ, в основном потому, что сложность сборки типичных проектов с открытым исходным кодом просто растет, а проблемы Autoconf не облегчаются разобраться: по крайней мере, «граничить с параноиком» несправедливо. Мне все еще не нравится подход Macports «собственная частная вселенная сборки», и он заслуживает того, чтобы подчеркнуть, что простота взаимодействия со списком рассылки - не единственная простота, о которой должен беспокоиться конечный пользователь. Я добавлю предостережения к своему ответу. Charles Stewart 9 лет назад 0
5
webappzero

Согласно MacPorts FAQ :

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

sudo port -t install <portname> 

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

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

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

Имейте в виду, что вы будете страдать от значительного снижения производительности. Но в целом это должно работать практически во всех случаях. neverpanic 9 лет назад 0
Спасибо за указание на это предостережение @neverpanic. Я предполагаю, что указанное снижение производительности влияет только на время установки порта и никак не влияет на характеристики времени выполнения установленного порта. Правда? webappzero 9 лет назад 0
Правильный. Это только предотвращает проблемы во время сборки, но не проблемы во время выполнения (но они очень редки). neverpanic 9 лет назад 0
На практике я не запомнил это требование всегда использовать флаг трассировки. Поэтому я не рекомендую эту практику другим, если вы не уверены, что будете использовать -t последовательно. webappzero 9 лет назад 0
Если вы не хотите его помнить, вы можете написать скрипт-оболочку или псевдоним оболочки (но помните о взаимодействии между псевдонимами sudo и shell), чтобы всегда передавать его вам. Обратите внимание, что Эль-Капитан в настоящее время нарушает режим трассировки. Я работаю над обходным путем. neverpanic 9 лет назад 0
4
plang

При установке 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 

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

1
S. McCandlish

webappzero's sudo port -t ... solution should help. To be honest, I run with Fink, MacPorts and Homebrew all at once, with deference to MacPorts (for now anyway), and only using either of the other two to install things I can't get from MacPorts. I've run into very few difficulties this way, even before learning the port -t trick. If you're trying to use multiple package managers to maintain complex development and server environments, though, you're probably in a for a world of discomfort at least. Pick one, and avoid the others but for something you desperately need from them, and put the main one earlier in the path.

If what I'm hearing is true about Apple going to forbid things to install into /usr/ other than Apple's own (or maybe they're already doing that in El Crapitan, which I'm avoiding "up"grading to until after more problems with it are resolved), I suppose that will mitigate the issue after Homebrew defaults to using something else – whether we agree with Apple's heavy-handed approach or not.

In the end, I like the idea of confining Apple's own ports to its own tree, I just wish it wasn't /usr/. I'd rather they'd used /System/bin/, etc., etc., to isolate their own stuff, so I could bypass it with up-to-date, community-maintained software more easily.