MacPorts vs. Fink vs. Homebrew [дублікат]


39

На це питання вже є відповідь тут:

Я завжди використовував MacPorts для встановлення та підтримки моїх компіляторів GCC та інших програм. Тепер я чув про Fink та Homebrew. Здається, ці дві утиліти набирають позиції в спільноті Mac, але я не розумію різниці між ними.

У чому головна відмінність MacPorts, Fink від Homebrew? Чи є якась різниця в якості чи продуктивності?


3
Є також Рудікс .
lhf

4
Це старе питання відповідає на ваші потреби?
bmike

Відповіді:


30

Фінк був навколо принаймні з 2001 року Фінк і MacPorts менеджери пакетів , які хочуть бути «ортогональними» до системи, тобто, вони встановлюють свою власну версію python, perl, бібліотеки, компілятори і т.д. у власних дерев (/ SW для Fink, / opt / local для MacPorts). Причиною цього є те, що вони не контролюють, що Apple робить зі своїм програмним забезпеченням, і вона періодично ламала речі, коли Apple оновлювала свої речі.

Як я розумію, Homebrew хоче бути більш "інтегрованим" із системою, використовує бібліотеки, які надає Apple, і встановлює свої речі в /usr/local/binінші стандартні папки. Я думаю, це означає, що вибір програмного забезпечення обмежений у програмі Homebrew, я не можу уявити, що з ним можна було б встановити KDE, але я цього не пробував.

Один момент для Fink проти MacPorts: кілька років тому проект Fink надав бінарні пакети; тобто ви можете завантажити та встановити пакунки, не складаючи їх самостійно. Його менеджер пакунків все ще має таку здатність, тільки там не було доступних бінарних файлів тривалий час. Не знаю, чи це тим часом змінилося.

Отже, коротко: без двійкових речей Фінк і МакПортс дуже схожі. У них повинно бути більше пакетів, ніж у Homebrew, тоді як Homebrew повинен займати менше місця на диску з причин, про які я говорив вище. Щодо якості: я ніколи не встановлював Homebrew, а між Fink та MacPorts, як правило, я віддаю перевагу тому, який я зараз не використовую.

Тож якщо ви задоволені MacPorts, просто залишайтеся з ним.

PS Причина, чому я ніколи не пробував Homebrew, полягає в тому, що я використовую деякі попередньо складені пакети. Зазвичай вони також встановлюються у / usr / local / bin тощо, що просто кричить за неприємності.


Я думав, що ви повинні помилитися з KDE, але досить впевнений, що це правда. Колись у нього були пакети, але, мабуть, є щось про спосіб побудови KDE, що є несумісним з ієрархією Homebrew. Сподіваємось, це буде виправлено якийсь день.
echristopherson

1
@echristopherson Так у KDE був колись? Сюрприз для мене. Але KDE здається досить крихким, я одного разу встановив його за допомогою Fink, і під час наступного оновлення вся установка зіпсувалася; тож можна було б сподіватись, що це ще крихкіше з домашньою мовою. Але якщо вони колись зрозуміють, я повертаю все, що я сказав.
Персиваль Улісс

4
Встановлення домашнього мовлення в / usr / local є тією ж причиною, яку я також не використовую. Дотримуючись традиційної філософії Unix, тільки я повинен розміщувати речі в / usr / local .. Менеджер пакунків повинен керувати деяким іншим префіксом.
Джейсон

Особисто я використовую MacPorts, але востаннє я перевірив (що, як і раніше), у Fink була доступна значно більша колекція пакетів.
HairOfTheDog

1
@Jason Це справедливо і для однієї користувальницької машини? Щойно я встановив Homebrew, і сподіваюся, що не пошкодую. Мені не дуже зрозуміло, як Apple обробляє root та користувачів, які мають права адміністратора. Я єдиний користувач у своїй системі.
Газиз

8

Я б сказав, що головні відмінності:
Провіденс, результат та спосіб розподілу.

Найважливішою деталлю для вас буде перевірити, чи обрана вами система містить пакунки (програми) для потрібного програмного забезпечення. Кількість пакетів приблизно: 19к Macports, 22k Fink, 3k Homebrew, 10k pkgsrc.

  • Макпорти , колишні порти Дарвіна, схоже, є системою портів у стилі BSD, як pkgsrc, який отримує джерело, виправляє його, будує та встановлює. Якщо він дуже схожий на pkgsrc, він зробить це за допомогою скриптів оболонки. Раніше покладався на інструменти, надані Xcode, але це почало створювати проблеми, тому тепер може також завантажувати gcc. Крім того, там є кілька двійкових пакетів, але ви, можливо, не знайдете останню версію для вашої системи кожен раз. Він прийшов з Дарвіна, Apple BSD з відкритим джерелом на основі ядра OS X, яке припинило розповсюдження. Він встановлює пакети, до /opt/localяких, ймовірно, не зачіпатимуться інші інсталяційні пакети чи оновлення системи.
  • Фінк , повторно: зяблики, що є предметом дослідження Чарльза Дарвіна, - це система пакетів, заснована на Debian Package Manager, що означає, що вона використовує використання, dpkgі apt-getголовна перевага полягає в тому, що ви можете надійно знаходити бінарні пакунки .. припускаючи, що у вас є пакет вище сховище, яке містить двійкові файли для вашої поточної версії ОС. Він також вийшов з бази користувачів Дарвіна, але, мабуть, більш популярний серед тих, хто прийшов з Debian Linux [для mac або PPC], шукаючи трохи стабільнішої апаратної підтримки ... поки це тривало. Він встановлює пакети в /swз причини неперезаписування або перезапису того, що можуть встановити інші інсталятори. Також щось про шляхи пошуку компілятора і типово PATHмістять за замовчуванням /usr/local/bin.
  • Homebrew - це свого роду система портів за концепцією, але написана в рубіні. Він не походить із окремого світу ОС і призначений для користувачів Mac OS X (інші ретельно використовуються і тестуються тим же самим). Станом на середину 2014 року він намагається скласти кожен пакет (вони називають їх формулою), хоча декілька доступні у двійковій формі, що називається пляшками, і ви можете зробити сховище пляшок, щоб поділитися у вашій соціальній групі, якщо ви схильні до напівприйняття -стандартність ланцюжків інструментів для вас і вашого друга (для інших систем). З іншого боку, він створює, використовуючи стільки бібліотек, скільки ви, мабуть, вже отримали від Apple. Я думаю, що вам не потрібен Xcode, щоб він працював у більшості випадків, але він "підтримує та рекомендує" його. Ви можете встановити кожен елемент у своєму власному префіксі,/usr/localЯ думаю, що це було запущено і є останнім часом, ніж інші. Особисто я виявив, що я користувався цим найбільше, тому що мені рідко потрібні взаємозалежні пакунки, і мені незрозуміло, наскільки добре Mac homebrew підтримує це. Homebrew має на меті змусити вас використовувати більш відповідні менеджери пакунків для програмного забезпечення, яке походить від щільно зв'язаного менеджера, наприклад, cpan, gems тощо.
  • pkgsrc буде доступний для Mac OS X, має бінарні пакети та надходить від NetBSD, який підтримує його і, в свою чергу, базується на портовій системі FreeBSD. NetBSD був настільки орієнтований на портативність в архітектурах, що, мабуть, найкраща портова система кандидатів почала підтримувати й інші платформи, які вона має. У моєму описі він схожий на Macport, але я його не використовував (крім NetBSD), і я думаю, що він встановлюється, /але пакує і підтримує пакети в /pkg. Можливо, багато пакетів (наприклад, 12k), а деякі 20% можуть не створити, або, остання версія джерела може не виправити останній підтримуваний патч. Ось чому бінарні пакети є моїм уподобанням у таких системах.

Я також використовував perlbrew, який є своєрідною домашньою мовою perl, додатки, вбудовані в perl, і деякі залежності. Це здебільшого хороший спосіб підтримувати кілька версій perl, і це зручно заперечує потребу в інших більш загальних пакетних системах (за своїм призначенням). Але звичайно це також має cpan та cpanminus .

Ви можете знайти схожі менеджерів для вашої власної міні-середовищі (наприклад , vundle для Vim, або дорогоцінний камінь рубін, НПМ для Node.js, pypm або піп для пітона, гоу вбудований go install... і т.д.?)


Кількість пакетів вводить в оману, оскільки Homebrew навмисно не включає певні класи пакунків - детальніше див. На apple.stackexchange.com/questions/32724/…
Dan Dascalescu

5

Fink і MacPorts є прямими конкурентами у встановленні ортогональної системи. Фінк втратив чималі позиції для MacPorts кілька років тому. Я не зовсім впевнений, чому зараз, але MacPorts впорався майже з усім краще.

У нас менше причин для ортогональної установки зараз, коли Mac OS X виростив менш шалені штани. Brew був отох створений для того, щоб краще інтегруватися з Mac OS X, роблячи його легшою вагою і менш ортогональною, а також тому, що Rubyist переписує все.

На практиці MacPorts трохи складніше, але MacPorts майже завжди працює, тоді як Brew простіший, але швидше за все, врізавшись в цегляну стіну.

Задайте собі це питання:

  • Чи використовуєте ви багато інструментів екосистеми Linux?
  • Вам потрібні кілька версій?
  • Чи багато експериментуєте з новими інструментами?
  • Використовуєте математичні / наукові засоби / бібліотеки чи інші незвичайні інструменти?

Будь-які відповіді "Так" дозволяють вибрати MacPorts. Якщо ви встановите порівняно мало та звичайні пакети, Brew витрачається менше, але Brew також не впорається зі складнощами. Заварюйте забруднення, /usr/localякі, можливо, захочете і для ручних установок. Насправді є більш детальні аргументи для MacPorts, але знову ж таки вони, ймовірно, не застосовуються, якщо ви відповіли "ні".

І навпаки, якщо ви відповіли "так", але ваша основна машина працює під управлінням Linux, а ваш Mac - це лише іграшка, на якій працює мінімальне програмне забезпечення для Linux, то насправді ви можете зробити краще з Brew.


2

Але як зауваження, нічого, що стосується Apple OS X, не встановилось би в / usr / local / bin. Вони використовують / usr / lib, / usr / bin за лаштунками та фреймворками, упаковуються в / Library / Frameworks, а речі, які ви встановлюєте самостійно за допомогою звичайного Unix ./configure, make, make install will use / usr / local / bin тощо , а такі утиліти, як MacPorts, використовуватимуть / opt / та, можливо, пакетні рамки для вашого персонального ~ / Бібліотека / Frameworks /.

Моя рекомендація - залишатися з MacPorts, якщо це те, до чого ви звикли. Основна відмінність полягає в тому, що MacPorts використовує систему, яка більше нагадує справжню реалізацію дерева портів Unix / BSD з портами FreeBSD, тоді як Fink використовує додатки, що переносяться з архівів Linux Debian, і використовує ту ж систему менеджера пакунків, що і Linux Debian.

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