Jakie są zalety i wady MacPorts, Fink i Homebrew?


154

Właśnie migruję z Ubuntu Linux na Maca, wszystko jest nowe i uczę się wielu rzeczy.

W systemie Linux miałem doskonałą apt-get do zarządzania pakietami oprogramowania. Poszukałem alternatywy dla Maca i znalazłem informacje o MacPorts, Fink i Homebrew.

Użyję tego komputera przede wszystkim do tworzenia aplikacji Ruby on Rails.

Jakie są między nimi różnice? Jakie są wady i zalety? Który jest najlepiej utrzymany i ma więcej pakietów?


5
Zredagowałem twój tytuł, aby pasował do twojego prawdziwego pytania. W większości witryn Stack Exchange nie ma pytania o „najlepsze”.
Loïc Wolff,

1
Dlaczego potrzebujesz któregoś z tych klejnotów ruby ​​nie wystarczy?
Mark

aby dowiedzieć się więcej o tym, dlaczego duplikaty nie zawsze są złe: apple.stackexchange.com/questions/11461/… także istnieje kilka innych alternatyw
cregox

Nigdy go nie użyłem, ale być może przydatne byłoby porównanie z pkgin .
Dennis

Odpowiedzi:


118

Zdecydowanie Homebrew. Zacząłem od Finka, potem przełączyłem się na MacPorts (szczęśliwszy), a potem Homebrew (dużo, dużo szczęśliwszy). Oto moje powody korzystania z każdego (lista pro, jeśli chcesz):

Mroczny typ

  • Oparte na Apt - poczuj się jak w domu, jeśli pochodzisz ze środowiska opartego na Debianie
  • Pakiety binarne - pakiety są dostępne jako pliki binarne, więc nie ma długich czasów kompilacji. Praktycznie jednak odkryłem, że skompilowane pliki binarne były zawsze nieaktualne i musiałem skompilować rzeczy dla mojego systemu
  • Przyzwoity wybór pakietów

MacPorts

  • Największy wybór pakietów / portów
  • Ogólnie bardzo aktualne
  • Fajny system wariantów, który pozwala dostosować kompilację
  • Łatwe i intuicyjne pliki portów

Homebrew

  • Bardzo aktualne
  • Maksymalne wykorzystanie tego, co jest dostępne w systemie OS X. W przeciwieństwie do Fink i MacPorts, nie wymaga budowania / instalowania Ruby i bibliotek od zera, tylko instalacja małego narzędzia opartego na Ruby.
  • Instaluje się w, /usr/localwięc nie trzeba PATHnigdzie modyfikować
  • Wszystko jest własnością użytkownika, więc żadne pakiety nigdy nie potrzebują potencjalnie ryzykownego dostępu do katalogu głównego, aby zainstalować
  • Każdy zainstalowany pakiet jest w piaskownicy czysto umieszczony w swojej piwnicy, więc nie masz zbłąkanych plików w całym systemie, tylko dowiązania symboliczne z bin, man itp.
  • Śmiesznie łatwe tworzenie własnych plików formuł (np. Deskryptorów pakietów)
  • Ponieważ jesteś z rubinowego tła, kolejnym plusem jest to, że wszystko jest napisane w rubinie, a wszystkie formuły są prostymi skryptami ruby

pkgin

  • Bardzo aktualne
  • Szybsza instalacja z powodu skompilowanych plików binarnych
  • Wszystko zainstalowane w / opt / pkg /
  • wspierane przez społeczność pkgsrc i Joyent
  • Znany do pracy na NetBSD, DragonFly BSD, Solaris, Debian, Mac OS X, Minix

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

http://pkgin.net/


33
Zauważ, że w przypadku domowego naparu można argumentować, że „instalowanie w / usr / local” i „wykorzystywanie tego, co jest dostarczane z OS X” to problemy - są to dwa główne powody, dla których używam innego systemu pakowania
Mark

5
Biorąc pod uwagę, że / usr / local / bin nie znajduje się w domyślnej ścieżce Mac OS X, z pewnością musisz zmodyfikować ŚCIEŻKĘ - musisz to zrobić tylko raz, ponieważ brew umieszcza w tym jednym miejscu linki do wszystkich nowych pojemniki, które instaluje (oprócz „beczek tylko”, ale tutaj jest hałas).
Terry N

4
@ Mark Który system pakowania preferujesz?
David Moles,

5
@ jedd.ahyoung Wolę Macports, który wprowadza / opt / local (Fink wstawia / sw)
Mark

5
Muszę się zgodzić z @ GDP2. Jestem nowym użytkownikiem komputera Mac z systemu Linux. Deweloperzy w brew mają bardzo złe podejście. Czy wierzysz, że w githubie napoju jest tylko 13 problemów, kiedy publikuję ten komentarz? Nie chcą słuchać użytkowników. Nie chcą żadnych problemów. Po prostu ignorują wszelkie problemy, które otworzyłeś i natychmiast zamknąłeś. Nigdy nie widzę takiego podejścia w żadnym projekcie github. Jako nowy użytkownik używam naparu od kilku miesięcy, a dziś myślę o przejściu na inny i znalazłem to pytanie. Doświadczenie z użyciem naparu jest najgorsze, jakie do tej pory miałem w życiu
sgon00

57

MacPorts

Jest bardziej niezależny od Mac OS X, co oznacza, że ​​MacPorts po prostu zignoruje wiele bibliotek systemowych i oprogramowania, które są już dostępne w Mac OS X, i zamiast tego wyciągnie własną , co może być wolniejsze, gdy instalowane narzędzie wymaga pewnego zestawu dużych biblioteki i oprogramowanie.

Ale ten wybór jest bezpieczniejszy, ponieważ na zainstalowane pakiety w mniejszym stopniu wpływa procedura aktualizacji / aktualizacji systemu Apple.


Homebrew

Jest bardziej zależny od istniejących zainstalowanych pakietów Mac OS X, więc przyspieszy to instalację pakietów i zminimalizuje zbędne biblioteki.

Ale ryzyko jest zainstalowane, pakiety mogą być zepsute z powodu aktualizacji / aktualizacji systemu Apple.

Są to dwa różne rodzaje kompromisu.

Ponadto Homebrew domyślnie przejmuje / usr / local , z czym niektórzy ludzie nie lubią tego, ponieważ w jakiś sposób jest on sprzeczny z tradycją unixową i może powodować problemy, jeśli już tam coś zainstalowałeś (MySQL itp.)


Oprócz tych różnic, biorąc pod uwagę pakiety, które te dwa mogą zaoferować, możesz sprawdzić za pomocą tych dwóch poleceń, czy masz już zainstalowany MacPorts / Homebrew, które pokazują pakiety, które obecnie zapewniają:

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

Przekonasz się, że MacPorts ma o wiele więcej pakietów niż Homebrew.

(19399 vs 3583 w dniu 13 maja 2016 r.)


17
Jako uwaga na temat różnej liczby pakietów: Homebrew zdecydowanie nie obejmuje pakietów dla języków programowania, które mają swój własny system pakowania (rubygems / pip / cpan…) lub dla oprogramowania, dla którego dostępny jest prawdopodobnie bardziej odpowiedni instalator OS X (MacTeX) . Ponadto duplikaty i starsze wersje nie znajdują się w domyślnym repozytorium, ale zawierają alternatywne repozytoria tap . Porównaj to z Macports, który np. Zawiera port IPython dla wszystkich zawartych wersji Pythona. Jest to rodzaj innej filozofii, która naturalnie zwiększa liczbę pakietów w Macportach.
Debilski


@YaOz, na pewno możesz zmienić homebrew, aby użyć czegoś innego niż /usr/local?
Pacerier

41

Żeby dodać kilka moich własnych myśli, które wydają się prawdziwe, przynajmniej około końca 2014 roku.

Homebrew, jak kilka lat temu, zdecydowanie ma przewagę pod względem udostępniania myśli. Znajdziesz wiele blogów z ludźmi, którzy mówią o tym, jak bardzo są zadowoleni z Homebrew - zwykle z powodu całego „MacPorts ściąga na całym świecie” kontra „Homebrew korzysta z tego, co już masz”.

Jednak IMO, MacPorts jest teraz inną bestią niż kilka lat temu. Kiedy po raz pierwszy przełączyłem się na OS X i używałem MacPorts, filozofia MP była frustrująca, ponieważ prawie wszystko zostało zbudowane ze źródła. Nowa instalacja była szczególnie bolesna / powolna. Jednak w ciągu ostatniego roku, bazując wyłącznie na własnych wrażeniach, wydaje się, że 90% pakietów MP to pliki binarne, więc instalacja jest teraz naprawdę szybka. Z tego, co zbieram, Homebrew również zmierza w tym kierunku z „Butelkami”, ale mam wrażenie, że większość rzeczy, które instalujesz w tym momencie za pośrednictwem HB, zostanie skompilowana ze źródła.

Tak więc, jeśli tylko w celu przedstawienia przeciwnej opinii, MacPorts wydaje się być obecnie „szybszą” opcją. Jednak większość opinii MP wydaje się opierać na doświadczeniach z około 2011-12 roku i tak naprawdę nie bierze tego pod uwagę. Weź to z odrobiną soli, ponieważ nie jestem regularnym użytkownikiem HB (i raczej bolesne jest używanie obu stron obok siebie).

Myślę, że HB ma zalety, które oznaczają, że prawdopodobnie „wygra wojnę” na dłuższą metę

  • HB jest w całości Ruby, podczas gdy MacPorts i jego formuły pakietów są napisane w języku TCL, który ... nie jest popularnym językiem skryptowym. To powiedziawszy, cholernie proste jest stworzenie własnego portfela.
  • HB opiera się na GitHub i dlatego wydaje się być o wiele bardziej przyjazny dla nowych autorów, podczas gdy MacPorts hostuje swoje własne repozytorium SVN gdzieś, jak sądzę - co w zasadzie odzwierciedla różny wiek obu projektów, jak sądzę.
  • Jak wspomniano, ogólny konsensus jest taki, że MacPorts został zastąpiony przez HB i słusznie lub nie, co przyciąga do niego więcej osób.

W przeciwnym razie YaOZl & kLy całkiem dobrze poradził sobie z główną różnicą pod względem sudo, zależności itp. Osobiście uważam, że MacPorts czasami prowadzi do pewnych problemów związanych z innymi programami, które nie oczekują niczego /opt/local, co jest instalowane z uprawnieniami roota itp. Są też takie rzeczy, które generalnie najlepiej nie są instalowane z MacPorts (np. Możesz zainstalować Railsy przez MacPorts, ale szaleństwem byłoby nie instalowanie go za pomocą zwykłego zarządzania klejnotami Ruby). Poza tym jestem wielkim fanem filozofii MacPorts polegającej na budowaniu własnego małego świata i nie poleganiu na paczkowanej bibliotece OS X - kiedy to działa, a przede wszystkim działa, wszystko jest bardzo proste. Właśnie tego naprawdę chcesz od Menedżera pakietów. I jak już wspomniałem, w tej chwili wszystko jest cholernie szybkie.

Mam nadzieję, że niektóre z nich były przydatne.


„Jak wspomniano, ogólny konsensus jest taki, że MacPorts został zastąpiony przez HB i słusznie lub nie, co przyciąga do niego więcej osób”. ... wydaje się to bardzo powierzchownym stwierdzeniem ... popularność w porównaniu z zapewnianiem jakości nie jest taka sama i w żadnym wypadku nie oznacza, że ​​drugie jest „zastępowane” przez pierwsze.
Dmitri Zaitsev

3

Napar był dla mnie całkowicie płynny, więc nie mogę powiedzieć o jego wadach. Niektóre wady MacPorts:

Istnieje kilka bardzo popularnych pytań dotyczących pierwszych dwóch punktów.


Takie było moje doświadczenie z instalowaniem ImageMagick na 10.6; brew była bardzo łatwa, ale nie obejmowała delegata JP2. imagemagick.org/script/binary-releases.php
Nemo,

2
brew i macports wymagają tylko narzędzi wiersza poleceń Xcode, więc to samo tutaj.
Mark

@ Mark Nie jestem pewien, co masz na myśli, ale napar działał dla mnie idealnie bez Xcode.
Nemo

2
Potrzebujesz kompilatora do parzenia i MacPorts, które można zainstalować za pomocą narzędzi wiersza poleceń Xcode. Nie będziesz potrzebować aplikacji Xcode .
nohillside

1
Zapomniałem, jak brzydkie jest synchronizowanie tego, gdy jest za firewallem ... tak!
rogerdpack
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.