Cosa sono i pro e i contro per MacPorts, Fink e Homebrew?


154

Sto solo migrando da Ubuntu Linux a Mac, e tutto è nuovo e sto riapprendendo molte cose.

Su Linux ho avuto l'ottimo apt-get per gestire i pacchetti software. Ho cercato su Google un'alternativa su Mac e ho scoperto MacPorts, Fink e Homebrew.

Userò questo computer principalmente per sviluppare applicazioni Ruby on Rails.

Quindi, quali sono le differenze tra loro? Quali sono gli aspetti positivi e negativi? Quale è meglio gestito e ha più pacchetti?


5
Ho modificato il tuo titolo per farlo corrispondere alla tua vera domanda. Sulla maggior parte dei siti di Stack Exchange, le domande che chiedono "il migliore" sono disapprovate.
Loïc Wolff,

1
Perché hai bisogno di una di queste gemme non sarà sufficiente?
user151019

per saperne di più sul perché i duplicati non sono sempre cattivi: apple.stackexchange.com/questions/11461/… anche lì ci sono alcune altre alternative
cregox,

Non l'ho mai usato da solo, ma forse sarebbe utile anche un confronto con pkgin .
Dennis,

Risposte:


118

Sicuramente homebrew. Ho iniziato con Fink, poi sono passato a MacPorts (più felice), quindi a Homebrew (molto, molto più felice). Questi sono i miei motivi per utilizzare ciascuno (un elenco di professionisti se vuoi):

Fink

  • Basato su Apt - sentiti come a casa se vieni da un ambiente basato su Debian
  • Pacchetti binari: i pacchetti sono disponibili come binari, quindi non richiedono tempi di compilazione lunghi. Praticamente però ho scoperto che i binari precompilati erano sempre obsoleti e dovevo comunque compilare roba per il mio sistema
  • Buona selezione di pacchetti

MacPorts

  • La più grande selezione di pacchetti / porte
  • Generalmente molto aggiornato
  • Bel sistema di varianti che ti consente di personalizzare la build
  • File delle porte facili e intuitivi

homebrew

  • Molto aggiornato
  • Massima valorizzazione di ciò che viene fornito con OS X. A differenza di Fink o MacPorts, non richiede di creare / installare ruby ​​e librerie da zero solo per installare alcuni piccoli strumenti basati su Ruby.
  • Installa in /usr/localcosì non è necessario che tu modifichi da PATHnessuna parte
  • Tutto di proprietà dell'utente, quindi nessun pacchetto ha mai bisogno di un accesso root potenzialmente rischioso per l'installazione
  • Ogni pacchetto installato è sandbox pulito nella propria cantina in modo da non avere file vaganti su tutto il sistema, solo collegamenti simbolici da bin, man, ecc.
  • Ridicolmente facile creare i tuoi file formula (es. Descrittori di pacchetti)
  • Dato che provieni da un background rubino, un altro vantaggio è che tutto è scritto in ruby ​​e tutte le formule sono semplici script ruby

pkgin

  • Molto aggiornato
  • Installazioni più veloci grazie ai binari precompilati
  • Tutto installato in / opt / pkg /
  • supportato dalla community di pkgsrc e Joyent
  • Noto per funzionare su NetBSD, DragonFly BSD, Solaris, Debian, Mac OS X, Minix

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

http://pkgin.net/


33
Nota che per la birra fatta in casa puoi sostenere che "Installa in / usr / local" e "sfruttamento di ciò che viene fornito con OS X" sono problemi - sono i due motivi principali per cui utilizzo un altro sistema di confezionamento
user151019

5
Dato che / usr / local / bin non si trova nel percorso predefinito di Mac OS X, devi sicuramente modificare il tuo PERCORSO, devi solo farlo una volta, poiché brew inserisce in quel punto i collegamenti a tutti i nuovi si installa (tranne i "solo fusti", ma qui è rumore).
Terry N

5
@ jedd.ahyoung Preferisco i macports che inseriscono / opt / local (fink mette in / sw)
user151019

5
Sfortunatamente, l'homebrew sembra rifiutare sempre di più alcuni casi d'uso e API al punto che i manutentori esprimono un palese disprezzo per gli utenti. Macports sembra un'alternativa migliore poiché questa tendenza sembra pervadere l'homebrew in modo inquietante. Homebrew, un tempo, era tutto per aiutare l'utente, ma lentamente si è allontanato da quello.
PIL2

5
Sono d'accordo con @ GDP2. Sono un nuovo utente Mac di Linux. Gli sviluppatori della birra hanno un atteggiamento molto negativo. Riesci a credere che ci siano solo 13 problemi nel github di brew quando sto postando questo commento? Non vogliono ascoltare gli utenti. Non vogliono alcun problema. Ignorano semplicemente tutti i problemi che hai aperto e li hanno chiusi immediatamente. Non vedo mai un simile atteggiamento in nessuno dei progetti di github. Come nuovo utente, ho usato brew per alcuni mesi e oggi sto pensando di passare a un altro e ho trovato questa domanda. L'esperienza sull'uso della birra è la peggiore della mia vita finora
sgon00

57

MacPorts

È più indipendente da Mac OS X, questo significa che MacPorts ignorerà molte delle librerie di sistema e dei software che sono già disponibili in Mac OS X e ne estrarrà una propria , che potrebbe essere più lenta quando l'utilità che installi richiede un set di grandi dimensioni biblioteche e software.

Ma questo tipo di scelta è più sicuro perché i pacchetti installati sono meno influenzati dalla procedura di aggiornamento / aggiornamento del sistema di Apple.


homebrew

Dipende maggiormente dai pacchetti installati di Mac OS X esistenti, quindi questo accelera l'installazione dei pacchetti e minimizza le librerie ridondanti.

Ma il rischio è che i pacchetti installati possano essere interrotti a causa dell'aggiornamento / aggiornamento del sistema di Apple.

Quindi, questi sono i due diversi tipi di compromesso.

Inoltre, Homebrew prende il comando / usr / local per impostazione predefinita, con il quale ad alcune persone non piace questo perché in qualche modo è in conflitto con la tradizione unix e potrebbe causare problemi se hai già installato qualcosa (MySQL, ecc.)


A parte queste differenze, considerando i pacchetti che questi due possono offrire, puoi verificare con questi due comandi se hai già installato MacPorts / Homebrew, che ti mostra i pacchetti attualmente forniti:

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

E scoprirai che MacPorts ha molti più pacchetti di Homebrew.

(19399 vs 3583 del 13 maggio 2016)


17
Come osservazione sul diverso numero di pacchetti: Homebrew decisamente non include pacchetti per linguaggi di programmazione che hanno il loro sistema di packaging (rubygems / pip / cpan ...) o per software per cui è disponibile un programma di installazione OS X probabilmente più appropriato (MacTeX) . Inoltre, i duplicati e le versioni precedenti non si trovano nel repository predefinito ma includono in repository di tocchi alternativi . Confronta questo con macports, che, ad esempio, contiene una porta IPython per tutte le versioni di Python incluse. È una specie di filosofia diversa che aumenta naturalmente il numero di pacchetti nei macport.
Debilski,


@YaOz, sicuramente potresti cambiare l'homebrew per usare qualcos'altro /usr/local?
Pacerier

41

Solo per aggiungere alcuni dei miei pensieri che sembrano veri almeno alla fine del 2014.

L'homebrew, un paio di anni fa, ha sicuramente il sopravvento in termini di condivisione della mente. Troverai molti blog con persone che parlano di quanto siano più felici con Homebrew - di solito a causa dell'intero "MacPorts tira in tutto il mondo" vs "Homebrew fa uso di ciò che già hai".

Tuttavia, IMO, MacPorts è una bestia diversa ora rispetto a un paio d'anni fa. Quando sono passato per la prima volta a OS X e utilizzavo MacPorts, la filosofia di MP era davvero frustrante perché quasi tutto era costruito dalla fonte. Una nuova installazione è stata particolarmente dolorosa / lenta. Tuttavia, nell'ultimo anno o giù di lì, basato esclusivamente sulle mie impressioni, sembra che il 90% dei pacchetti MP siano binari e quindi l'installazione è davvero molto veloce ora. Da quello che raccolgo Homebrew si sta muovendo anche in questa direzione con "Bottiglie", ma ho l'impressione che la maggior parte delle cose che installi tramite HB in questo momento verranno compilate dalla fonte.

Quindi, se non altro per offrire un'opinione compensativa, MacPorts sembra attualmente essere l'opzione "più veloce". Tuttavia, le opinioni della maggior parte delle persone sui parlamentari sembrano basarsi su esperienze di circa 2011-12 o giù di lì e non ne tengono conto. Prendi questo con un po 'di sale, anche se non sono un normale utente di HB (ed è piuttosto doloroso usare entrambi fianco a fianco).

Penso che HB abbia dei vantaggi, il che significa che probabilmente "vincerà la guerra" nel lungo periodo

  • HB è tutto Ruby mentre MacPorts, e le sue formule di pacchetto, sono scritte in TCL che non è ... un linguaggio di scripting molto popolare. Detto questo, è dannatamente semplice creare il proprio portfile.
  • HB si basa su GitHub e quindi sembra molto più accogliente per i nuovi collaboratori, mentre MacPorts ospita il proprio repository SVN da qualche parte penso - che sostanzialmente riflette le diverse età di entrambi i progetti, suppongo.
  • Come accennato, il consenso generale è che MacPorts è stato sostituito da HB e, giustamente o erroneamente, attira più persone verso di esso.

Altrimenti YaOZl & kLy hanno coperto abbastanza bene la differenza principale in termini di sudo, dipendenze ecc. Personalmente trovo che i MacPorts a volte portano ad alcuni mal di testa in termini di altri programmi che non si aspettano nulla in essere /opt/local, cose installate con permessi di root ecc. E ci sono alcune cose che in genere non sono installate con MacPorts (ad esempio è possibile installare Rails tramite MacPorts ma saresti pazzo a non installarlo tramite la normale gestione Gem di Ruby). Oltre a questo, anche se sono un grande fan della filosofia MacPorts di costruire il suo piccolo mondo e non fare affidamento su una libreria OS X preconfezionata - quando funziona, e soprattutto lo fa, tutto è semplicissimo. Che è quello che vuoi davvero da un gestore di pacchetti. E come ho già detto, a questo punto nel tempo è abbastanza dannatamente veloce impostare la maggior parte delle cose.

Spero che un po 'di quello sia stato utile.


"Come accennato, il consenso generale è che MacPorts è stato sostituito da HB e, giustamente o erroneamente, attira più persone verso di esso". ... questa sembra un'affermazione molto superficiale ... essere popolare e fornire qualità non è la stessa cosa e non implica affatto che il secondo sia "sostituito" dal primo.
Dmitri Zaitsev, il

3

Brew è stato completamente liscio per me da usare, quindi non sono in grado di parlarne. Alcuni svantaggi di MacPorts:

Ci sono molte domande molto popolari sui primi due punti.


Questa è stata la mia esperienza con l'installazione di ImageMagick su 10.6; la preparazione è stata molto semplice, ma non includeva il delegato JP2. imagemagick.org/script/binary-releases.php
Nemo,

2
brew e macports richiedono solo gli strumenti della riga di comando Xcode, quindi lo stesso qui.
user151019,

@Mark Non sono sicuro di cosa intendi, ma brew ha funzionato perfettamente per me senza Xcode.
Nemo,

2
Avrai bisogno di un complier per brew e MacPorts, che può essere installato tramite Xcode Command Line Tools. Non avrai bisogno dell'applicazione Xcode .
Nohillside

1
Ho dimenticato quanto sia brutto sincronizzare quella cosa quando dietro un firewall ... yikes!
rogerdpack,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.