Які плюси та мінуси для MacPorts, Fink та Homebrew?


154

Я просто переходжу з Ubuntu Linux на Mac, і все нове, і я багато чого вивчаю.

У Linux у мене був відмінний підхід для управління програмними пакетами. Я шукав альтернативу на Mac і дізнався про MacPorts, Fink та Homebrew.

Цей комп’ютер я буду використовувати в першу чергу для розробки додатків Ruby on Rails.

Отже, в чому полягають відмінності між ними? Які є наслідки і недоліки? Який з них найкраще підтримувати та має більше пакетів?


5
Я відредагував ваш заголовок, щоб він відповідав вашому справжньому питанню. На більшості сайтів Stack Exchange запитання "найкращих" нахмурені.
Loïc Wolff

1
Чому вам потрібне, що жодне з цих дорогоцінних каменів не буде достатньо?
Марк

Докладніше про те, чому дублікати не завжди погані: apple.stackexchange.com/questions/11461/… також є ще кілька альтернатив
cregox

Ніколи не використовував його сам, але, можливо, корисне також порівняння з pkgin .
Денніс

Відповіді:


118

Однозначно домашній. Я почав з Fink, потім перейшов на MacPorts (щасливіший), потім Homebrew (набагато, набагато щасливіший). Це мої причини використання кожного (список профі, якщо ви хочете):

Фінк

  • Apt-based - почувайтеся як вдома, якщо ви родом із середовища, що базується на Debian
  • Бінарні пакунки - пакунки доступні у вигляді бінарних файлів, тому немає тривалого часу компіляції. Практично, хоча я виявив, що попередньо складені двійкові файли завжди застаріли, і мені довелося збирати речі для моєї системи в будь-якому випадку
  • Гідний вибір пакетів

MacPorts

  • Найбільший вибір пакетів / портів
  • Як правило, дуже сучасний
  • Приємна система варіантів, яка дозволяє налаштувати збірку
  • Прості та інтуїтивно зрозумілі портові файли

Домашня мова

  • Дуже сучасний
  • Максимальне використання того, що поставляється з OS X. На відміну від Fink або MacPorts, він не вимагає від вас змайструвати / встановлювати рубіни та бібліотеки з нуля, просто встановити невеликий інструмент на основі Ruby.
  • Встановлення в /usr/localтак не потребує змін у PATHбудь-якому місці
  • Все, що належить користувачеві, тому жоден пакет ніколи не потребує потенційно ризикованого кореневого доступу для встановлення
  • Кожен встановлений пакунок знаходиться в чистому піску у власному підвалі, щоб у вас не було бродячих файлів по всій вашій системі, а лише посилання на смітник, man тощо.
  • Смішно легко створювати власні файли формул (тобто дескриптори пакетів)
  • Оскільки ви з фона рубіну, ще одним плюсом є те, що все написано в рубіні, а всі формули - прості сценарії з рубіном

pkgin

  • Дуже сучасний
  • Швидше встановлюється через попередньо складені бінарні файли
  • Все, що встановлено в / opt / pkg /
  • підкріплений спільнотою pkgsrc та Joyent
  • Відомо, що працює над NetBSD, DragonFly BSD, Solaris, Debian, Mac OS X, Minix

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

http://pkgin.net/


33
Зауважте, що для домашньої заварки ви можете стверджувати, що "Встановлення в / usr / local" та "використання того, що поставляється з OS X" - це проблеми - це дві основні причини, коли я використовую іншу систему упаковки
Марк

5
Зважаючи на те, що / usr / local / bin не стоїть за замовчуванням на Mac OS X, вам, звичайно, доведеться змінювати свій PATH - вам доведеться це зробити лише один раз, оскільки Brew ставить у цьому місці посилання на все нове Бункери він встановлює (за винятком "тільки кег", але тут шум).
Terry N

4
@Mark Яку систему упаковки ви віддаєте перевагу?
Девід Молес

5
@ jedd.ahyoung Я віддаю перевагу макпортам, який ставить в / opt / local (фінк ставить в / sw)
Марк

5
Я маю згоду з @ GDP2. Я новий користувач Mac від Linux. До розробників пива дуже погано ставляться. Чи можете ви повірити, що в github пивоваріння є лише 13 питань, коли я публікую цей коментар? Вони не хочуть слухати користувачів. Вони не хочуть жодних питань. Вони просто ігнорують будь-які проблеми, які ви відкрили, і негайно їх закрили. Я ніколи не бачу такого ставлення в жодному з проектів github. Як новий користувач, я вже кілька місяців використовую пивоваріння, і сьогодні я думаю про перехід на інший і знайшов це питання. Досвід використання пивоваріння - це найгірший, який я мав у своєму житті
sgon00

57

MacPorts

Це більш незалежно від Mac OS X, це означає, що MacPorts просто ігнорує багато системних бібліотек та програмних засобів, які вже доступні в Mac OS X, і натомість витягне власну , що може бути повільніше, коли встановлена ​​утиліта вимагає певного набору великих розмірів бібліотеки та програмне забезпечення.

Але такий вибір є більш безпечним, оскільки встановлені вами пакети менше впливають на процедуру оновлення / оновлення системи Apple.


Домашня мова

Він більше залежить від існуючих встановлених пакетів Mac OS X, тому це прискорить встановлення пакетів і мінімізує надмірні бібліотеки.

Але ризик встановлених пакетів може бути порушений через оновлення / оновлення системи Apple.

Отож, це два різновиди компромісу.

Крім того, Homebrew за замовчуванням переймає / usr / local , де деяким людям це не подобається, оскільки це якимось чином суперечить традиції Unix і може спричинити проблеми, якщо ви вже що-небудь там встановили (MySQL тощо)


Крім цих відмінностей, враховуючи пакети, які ці два можуть запропонувати, ви можете перевірити за допомогою цих двох команд, якщо у вас вже встановлено MacPorts / Homebrew, які показують вам ті пакети, які вони надаються:

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

І ви дізнаєтесь, що у MacPorts є набагато більше пакетів, ніж Homebrew.

(19399 проти 3583 13 травня 2016 року)


17
Як зауваження щодо різної кількості пакунків: Homebrew, безумовно, не включає пакети для мов програмування, які мають власну систему упаковки (rubygems / pip / cpan…), або програмне забезпечення, для якого, можливо, більш відповідний інсталятор OS X (MacTeX) . Крім того, дублікати та старіші версії не містять репо за замовчуванням, але включають в альтернативні репозиційні торки. Порівняйте це з макпортами, які, наприклад, містять порт IPython для всіх включених версій Python. Це якась інша філософія, яка, природно, збільшує кількість пакунків у макпортах.
Дебільські

2
Відмінне посилання! terrychay.com/article/macports-vs-homebrew.shtml Дякую!
Джефф Берджес

@YaOz, Звичайно, ви можете змінити домашню мову, щоб використовувати щось інше, ніж /usr/local?
Pacerier

41

Тільки щоб додати деякі мої власні думки, які здаються справді-іш приблизно в кінці 2014 року.

Домашня мова, як і пару років тому, безумовно, має перевагу в плані розуму. Ви знайдете багато блогів з людьми, які говорять про те, наскільки щасливішими вони з Homebrew - зазвичай через те, що "MacPorts тягне в усьому світі" проти "Homebrew використовує те, що у вас вже є".

Однак IMO, MacPorts - це інший звір зараз, ніж це було пару років тому. Коли я вперше перейшов на OS X і використовував MacPorts, філософія MP справді неприємна, тому що майже все було побудовано з джерела. Нова установка була особливо болісною / повільною. Однак за останній рік або близько того, виходячи виключно з моїх власних вражень, здається, що 90% пакетів MP - це бінарні файли, тож установка насправді дуже швидка. З того, що я збираю, Homebrew також рухається в цьому напрямку за допомогою «Пляшок», але у мене складається враження, що більшість речей, які ви встановлюєте через HB в цей момент часу, будуть зібрані з джерела.

Отже, якщо тільки запропонувати виправдовувальну думку, MacPorts, здається, насправді є "швидшим" ​​варіантом в наші дні. Однак, здається, думка більшості народних депутатів базується на досвіді близько 2011-12 років і навіть не враховує це. Візьміть це з зерном солі, хоча я не є звичайним користувачем HB (і його досить болісно використовувати обидва поряд).

Я думаю, що HB має переваги, які означають, що він, ймовірно, "виграє війну" у довгостроковій перспективі

  • HB - це все Ruby, тоді як MacPorts та його формули пакунків написані в TCL, що .... не зовсім популярна мова сценаріїв. Це сказало, що це досить чортово просто, щоб створити власний портфель.
  • HB базується на GitHub і, таким чином, здається набагато привітнішим для нових учасників, тоді як MacPorts розміщує своє власне сховище SVN десь на мою думку - що, в основному, відображає різні епохи обох проектів, які я думаю.
  • Як вже згадувалося, загальний консенсус полягає в тому, що MacPorts витіснив HB &, правильно чи неправильно, що привертає до нього більше людей.

Інакше YaOZl & kLy досить добре висвітлили головну різницю щодо судо, залежностей тощо. Особисто я вважаю, що MacPorts іноді призводить до деяких головних болів з точки зору інших програм, не очікуючи, що щось буде /opt/local, все, що встановлюється з дозволом на root тощо. MacPorts, але ви будете шалені, щоб не встановлювати його за допомогою звичайного управління Gem Ruby). Крім цього, хоча я великий шанувальник філософії MacPorts будувати свій власний маленький світ і не покладатися на якусь попередньо упаковану бібліотеку OS X - коли вона працює, і це, в основному, все просто мертво. Що саме ви хочете від менеджера пакунків. І як я вже згадував, в цей момент часу його досить чортово швидко встановити більшість речей.

Сподіваюся, що щось із цього було корисним.


"Як згадувалося, загальний консенсус полягає в тому, що MacPorts витіснив HB &, правильно чи неправильно, що привертає до нього більше людей". ... це здається дуже поверхневим твердженням ... популярність проти надання якості не є однаковою і аж ніяк не означає, що друге "витісняється" першим.
Дмитро Зайцев

3

Для мене Brew був абсолютно рівним, тому я не можу розповісти про його мінуси. Деякі недоліки MacPorts:

Є кілька дуже популярних питань щодо перших двох пунктів.


Це мій досвід встановлення ImageMagick на 10.6; варити було дуже просто, але не включав делегата JP2. imagemagick.org/script/binary-releases.php
Немо

2
варити та макпорти просто вимагають інструментів командного рядка Xcode, щоб вони були такими ж.
Марк

@Mark Я не впевнений, що ти маєш на увазі, але заварка працювала для мене ідеально без Xcode.
Немо

2
Вам знадобиться компілятор для пива та MacPorts, який можна встановити за допомогою інструментів командного рядка Xcode. Ви не будете потребувати Xcode додатку .
nohillside

1
Я забув, як потворно синхронізувати цю річ, коли за брандмауером ... поступається!
rogerdpack
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.