Могут ли pkgsrc, Homebrew, Fink и MacPorts мирно сосуществовать?

2904
hpy

Я слышал, что некоторые люди любят использовать Fink и Macports, так как некоторые пакеты существуют в одном, а не в другом.

Недавно у меня были проблемы со сборкой и запуском таких пакетов, как GRASS и Digikam с MacPorts, и я начал искать альтернативы.

Просто интересно: будут ли сосуществовать и работать вместе pkgsrc и Homebrew?

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

Спасибо!

6

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

7
raimue

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

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

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

Я не знаю pkgsrc достаточно, чтобы сказать, действительно ли он затронут таким же образом, но я думаю, что эта проблема относится и к нему.

Похоже, в MacPorts нет открытых ошибок для дигикам или травы . Вы должны сообщить им о своих проблемах непосредственно с новыми билетами, чтобы получить помощь.

Суть Homebrew заключается в установке библиотек и программ, * не * включенных в OS X. MacPorts не любил использовать `/ usr / local`, потому что MacPorts устанавливает много дублирующих библиотек, которые уже включены в OS X, и не делал хочу иметь дело со странностями, если пользователи установили одну и ту же библиотеку в `/ usr / local`. Он также хотел изолировать всю свою систему от всего остального. MacPorts и Homebrew придерживаются разных принципов в этом отношении. Сказать, что Homebrew - это плохо, потому что он устанавливает программное обеспечение в `/ usr / local`, все равно, что сказать * не использовать` / usr / local` вообще *, что глупо. mipadi 14 лет назад 2
Нет, в начале MacPorts использовал системные библиотеки. Но это невозможно было обслуживать при поддержке нескольких версий OS X, поэтому политика была изменена, чтобы полагаться только на собственные библиотеки. Совет не использовать `/ usr / local`, если вы также используете MacPorts, имеет смысл. Путь находится в пути поиска компиляторов по умолчанию и не может быть удален. raimue 14 лет назад 3
Разве MacPorts не устанавливает собственные пути поиска, игнорируя `/ usr` и` / usr / local`? MacPorts, очевидно, не ищет `/ usr` при поиске библиотек, так как в любом случае устанавливает свои собственные копии. mipadi 14 лет назад 0
Невозможно игнорировать / usr и / usr / local. Эти пути поиска жестко закодированы в компиляторе. raimue 14 лет назад 1
Хорошо, я должен перефразировать это: MacPorts сначала не проверяет свое собственное дерево? (В противном случае нет смысла дублировать библиотеки.) С другой стороны, важно отметить, что Homebrew не устанавливает дублирующиеся библиотеки _at all_; он даже не установит дублированную версию Autoconf. Если для определенной формулы требуется более новая версия дубликата библиотеки, она установит ее в режиме «только кеги», то есть поместит ее в `/ usr / local / Cellar` вместо` / usr / local / lib`. Homebrew очень старается не устанавливать вещи, которые могут нарушить ручную компиляцию. mipadi 14 лет назад 1
* Невозможно игнорировать / usr и / usr / local * - это значения по умолчанию, которые прямо переопределяются опциями. @mipadi прав. Charles Stewart 13 лет назад 0
Нет, они не могут быть отменены. Вы можете добавить другие пути, но они всегда будут в конце пути поиска. Если вы не понимаете этого, вы должны понять, насколько сложна проблема, и либо углубиться в это, либо просто довериться нам. raimue 13 лет назад 4
Raim: Вы можете уведомить людей о своих ответах, поставив перед их именем достаточно @, например @Charles. LDFLAGS = -Z удалит / usr и / usr / lib из значений по умолчанию ld, хотя я вижу, что вы правы - некоторые пакеты Macports, непонятно, вернут их прямо в путь поиска: https: //trac.macports .org / ticket / 23400 (посмотрите на вызов gcc). Если бы я заботился о Macports, я бы назвал это ошибкой, но я просто добавлю это в список причин, почему я нахожу Macports менее терпимым, чем Homebrew и Fink. Charles Stewart 13 лет назад 0
1
GDP2

Это правда, смешивание менеджеров пакетов может вызвать головную боль. Но я использую и Homebrew, и MacPorts, и это работает, потому что у меня есть небольшое количество пакетов в Homebrew. Единственное, что у меня есть, это программы для конечных пользователей, которые (пока) не доступны в MacPorts. Например: gist, dashingи sqldiff. Если вы сводите вещи к минимуму в одном или другом диспетчере пакетов, головные боли становятся менее вероятными.

Правда, единственное обоснование для этого - когда вам нужен пакет, который недоступен в данном менеджере пакетов. Лично я обнаружил, что MacPorts имеет подавляющее большинство программ, которые мне нужны, и он гораздо более зрелый, чем Homebrew, множеством способов. В него также легче вносить вклад, с менее строгими правилами и хорошим языком сценариев (Tcl, который на самом деле так же хорош, как Ruby). Есть много других преимуществ MacPorts по сравнению с Homebrew, но я остановлюсь здесь и закончу свою касательную.

Похожие вопросы