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

Zdecydowanie Homebrew. Zacząłem od Finka, potem przerzuciłem się na MacPorts (szczęśliwszy), potem Homebrew (dużo, dużo szczęśliwszy). Oto moje powody, dla których używam każdego z nich (lista pro, jeśli wolisz):

Fink

• Oparty na Apt – poczuj się jak w domu, jeśli pochodzisz z Debiana środowisko
• Pakiety binarne – pakiety są dostępne jako pliki binarne, więc nie ma długich czasów kompilacji. Praktycznie jednak odkryłem, że wstępnie skompilowane pliki binarne były zawsze nieaktualne i i tak musiałem skompilować rzeczy dla mojego systemu

MacPorts

• W przeciwieństwie do homebrew tak nie zależy od biblioteki MacOS, która może ulec zmianie w przyszłości.
• Zainstaluj wszystko w / opt / local
• Ładny system wariantów który pozwala dostosować kompilację
• Łatwe i intuicyjne pliki portów, pozwala także na dodawanie własnych
• obsługuje wiele wersji OSX i macOS powracających do Tiger, w tym wersje PowerPC zobacz inna odpowiedź

Homebrew

• Maksymalne wykorzystanie możliwości systemu OS X. W przeciwieństwie Fink lub MacPorts, nie wymaga budowania / instalowania Rubiego i bibliotek od podstaw, tylko po to, aby zainstalować jakieś małe narzędzie oparte na Ruby.
• Instaluje się w /usr/local
• Instaluj bez uprawnień administratora
• Każdy zainstalowany pakiet jest czysto piaskownicą w swojej własnej piwnicy, więc nie musisz wszystkie bezpańskie pliki w całym systemie, tylko linki symboliczne z bin, man itp.
• Zawiera przewodniki i automatyzację do tworzenia własnych plików z formułami (to znaczy. deskryptory pakietów)
• Napisane w języku Ruby, a wszystkie formuły są zwięzłymi skryptami w języku Ruby
• Szybsze instalacje dzięki wstępnie skompilowanym plikom binarnym

pkgin

• Szybsze instalacje dzięki wstępnie skompilowanym plikom binarnym
• Wszystko zainstalowane w / opt / pkg /
• wspierane przez społeczność pkgsrc i Joyent
• Znany z pracy na NetBSD, DragonFly BSD, Solaris, Debian, Mac OS X, Minix

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

http://pkgin.net/

Komentarze

• Komentarze nie służą do rozszerzonej dyskusji; ta rozmowa została przeniesiona do czatu . Jeśli blokada musi zostać zwolniona, zgłoś ten problem na Ask Different Meta lub za pomocą flagi.

MacPorts

Jest bardziej niezależny od Mac OS X, co oznacza, że MacPorts po prostu zignoruje wiele bibliotek systemowych i oprogramowania, które już dostępne w systemie Mac OS X i zamiast tego pobiera własne , co może być wolniejsze, gdy instalowane narzędzie wymaga zestawu dużych bibliotek i oprogramowania.

Ale ten wybór jest bezpieczniejszy, ponieważ aktualizacje / uaktualnienia systemu Apple mają mniejszy wpływ na zainstalowane pakiety

Homebrew

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

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

Są to dwa różne rodzaje kompromisów.

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

Oprócz tych różnic, biorąc pod uwagę pakiety, które ci dwaj mogą zaoferować, możesz sprawdzić za pomocą tych dwóch poleceń, jeśli masz już zainstalowane MacPorts / Homebrew, które pokazują pakiety, które obecnie dostarczały:

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

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

(19399 vs 3583 z 13 maja 2016)

Komentarze

• Uwaga dotycząca różnej liczby pakietów: Homebrew zdecydowanie nie obejmuje pakietów dla języków programowania, które mają 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 obejmują alternatywne repozytoria tap . Porównaj to z macportami, które np. Zawierają port IPython dla wszystkich dołączonych wersji Pythona. To trochę inna filozofia, która w naturalny sposób zwiększa liczbę pakietów w sporcie.
• Świetny link! terrychay.com/article/macports-vs-homebrew.shtml Dziękuję!
• @YaOz, na pewno mógłbyś zmienić homebrew, aby używał czegoś poza /usr/local?
• @Pacerier Uważam, że gdziekolwiek indziej niż /usr/local/ jest „nieobsługiwane” lub „odradzane” .

Dodam tylko kilka moich własnych przemyśleń, które wydają się prawdziwe przynajmniej około końca 2014 roku .

Homebrew, kilka lat temu, zdecydowanie ma przewagę pod względem dzielenia się myślami. Znajdziesz wiele blogów, w których ludzie mówią o tym, o ile szczęśliwsi są z Homebrew – zwykle z powodu tego całego „MacPorts wyciąga na całym świecie” kontra „Homebrew wykorzystuje to, co już masz”.

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

Tak więc, jeśli tylko chcesz przedstawić równoważną opinię, MacPorts wydaje się być „szybszym” o ption te dni. Jednak opinie większości ludzi na temat posła wydają się opierać na doświadczeniach z około 2011-12 roku & tak naprawdę nie biorą tego pod uwagę. Weź to jednak z przymrużeniem oka, ponieważ nie jestem zwykłym użytkownikiem HB (i używanie obu stron obok siebie jest raczej bolesne).

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

• HB to w całości Ruby, podczas gdy MacPorts i jego formuły pakietów są napisane w TCL, który nie jest … nie do końca popularnym językiem skryptowym. dość cholernie proste tworzenie własnego portfela.
• HB opiera się na GitHub &, dlatego wydaje się o wiele bardziej przyjazny dla nowych współpracowników, podczas gdy MacPorts ma gdzieś własne repozytorium SVN Myślę – co zasadniczo odzwierciedla różny wiek obu projektów, jak przypuszczam.
• Jak wspomniano, ogólny konsensus jest taki, że MacPorts zostało zastąpione przez HB &, słusznie lub niesłusznie, to przyciąga więcej ludzi.

W przeciwnym razie YaOZl & kLy całkiem dobrze opisał główną różnicę w zakresie sudo, zależności itp. Osobiście JA okazuje się, że MacPorts czasami powoduje bóle głowy, ponieważ inne programy nie oczekują, że coś znajdzie się w /opt/local, instalowaniu rzeczy z uprawnieniami administratora itp. & jest kilka rzeczy, których generalnie najlepiej nie instalować z MacPorts (np możesz zainstalować Railsy przez MacPorts, ale byłbyś szalony, gdybyś nie instalował ich przez zwykłe zarządzanie Gemami w Rubim). Poza tym, chociaż jestem wielkim fanem filozofii MacPorts budowania własnego małego świata & nie polegając na jakiejś gotowej bibliotece OS X – kiedy to działa, a przeważnie działa, wszystko jest śmiertelnie prosty. Czego tak naprawdę oczekujesz od menedżera pakietów. I jak już wspomniałem, w tej chwili jest cholernie szybko konfiguracja większości rzeczy.

Mam nadzieję, że część z tego była przydatna.

Komentarze

• ” Jak wspomniano, ogólny konsensus jest taki, że MacPorts zostało zastąpione przez HB &, słusznie lub niesłusznie, przyciąga do siebie więcej ludzi. ” … to wydaje się bardzo powierzchowne stwierdzenie …bycie popularnym a zapewnianie jakości to nie to samo i nie oznacza to, że druga wartość jest ” zastępowana ” przez pierwszą.
• MacPorts używa teraz Github. Zobacz guide.macports.org/#project.github : ” Projekt MacPorts używa rozproszonego systemu kontroli wersji Git do zarządzania kodem dla całego projektu. Nasze repozytoria główne są hostowane w serwisie GitHub. Utrzymujemy publiczne repozytoria dla prawie całego naszego kodu i dokumentacji projektu, w tym repozytorium GitHub dla samego systemu MacPorts, dla portów MacPorts, a nawet dla przewodnika, który właśnie czytasz. ”

Coś, o czym inne odpowiedzi (do tej pory) nie wspominały, to fakt, że MacPorts ma doskonałe wsparcie dla starszych wersji macOS. Homebrew obsługuje tylko te systemy operacyjne, które są obecnie obsługiwane przez Apple, co zwykle oznacza trzy ostatnie wersje. Na przykład od sierpnia 2020 r. Tylko Catalina, Mojave i High Sierra są kompatybilne z Homebrew.

Z kolei MacPorts można zainstalować na Tiger (!), A projekt utrzymuje specjalne poprawki, aby zachować oprogramowanie pracując tam, gdzie to możliwe. Utrzymują także bibliotekę ” Obsługa starszych wersji „, która przenosi symbole z nowych wersji systemu macOS do starszych; połączenie z tą biblioteką podczas kompilacji może sprawić, że wszystkie rodzaje nowego oprogramowania nagle zaczną działać na starszych systemach!

Więc jeśli używasz starej wersji macOS lub jeśli myślisz, że być może będziesz musiał pozostać na obecny system operacyjny, którego data ważności przekroczyła datę ważności Apple, to zdecydowanie powód, aby wybrać MacPorts.

Napar był całkowicie jest dla mnie gładka, więc nie jestem w stanie powiedzieć o jej wadach. Niektóre wady MacPorts:

• musisz zainstalować Xcode z witryny Apple Developer , dlatego musisz mieć konto programisty Apple (który teraz wymaga karty kredytowej) i pobierz prawie 3,5 GB danych;
• jeśli port 873 (rsync) jest zablokowany przez zaporę, musisz ręcznie skonfiguruj protokół HTTPS ;
• serwer HTTP (S), z którego pobierane są pakiety, jest (często) bardzo wolny (wczoraj poniżej 20 KiB / s; testowany na kilku bardzo niezawodnych gigabitach połączeń w różnych krajach) i może zakończyć się niepowodzeniem z powodu błędu Zbyt wolna operacja. Przesłano mniej niż 1024 bajty / s w ciągu ostatnich 60 sekund , co zmusza do ponownego wykonania wszystkiego od zera.

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

Komentarze

• To było moje doświadczenie instalowanie programu ImageMagick w wersji 10.6; napar był bardzo łatwy, ale nie ' t dołącz delegata JP2. imagemagick.org/script/binary-releases.php
• brew i macports wymagają tylko narzędzi wiersza poleceń Xcode, więc to samo tutaj.
• @Mark I ' Nie jestem pewien, co masz na myśli, ale napar działał dla mnie idealnie bez Xcode.
• Ty ' Będziemy potrzebować kompilatora dla brew i MacPorts, który można zainstalować za pomocą narzędzi wiersza poleceń Xcode. Nie będziesz potrzebować aplikacji Xcode .
• Zapomniałem, jak brzydka jest synchronizacja tego elementu za zaporą ogniową … yikes!