Wat zijn de voor- en nadelen van MacPorts, Fink en Homebrew?

Absoluut Homebrew. Ik begon met Fink, schakelde toen over naar MacPorts (gelukkiger) en vervolgens Homebrew (veel, veel gelukkiger). Dit zijn mijn redenen om ze allemaal te gebruiken (een professionele lijst als je wilt):

Fink

• Apt-gebaseerd – voel je meteen thuis als je van een op Debian gebaseerde omgeving
• Binaire pakketten – pakketten zijn beschikbaar als binaire bestanden, dus geen lange compilatietijden. Praktisch gezien heb ik echter “geconstateerd dat de voorgecompileerde binaire bestanden altijd verouderd waren en ik toch dingen voor mijn systeem moest compileren

MacPorts

• In tegenstelling tot homebrew niet afhankelijk van MacOS-bibliotheek die in de toekomst kan veranderen.
• Installeer alles in / opt / local
• Mooi varianten van systeem waarmee u de build kunt aanpassen
• Eenvoudige en intuïtieve port-bestanden, waarmee u ook uw eigen kunt toevoegen
• ondersteunt vele versies van OSX en macos die teruggaan naar Tiger, inclusief PowerPC-versies, zie ander antwoord

Homebrew

• Maximale benutting van wat er bij OS X wordt geleverd. In tegenstelling tot Fink of MacPorts, het vereist niet dat je ruby en bibliotheken helemaal opnieuw bouwt / installeert om een klein, op Ruby gebaseerd hulpmiddel te installeren.
• Wordt geïnstalleerd in /usr/local
• Installeren zonder root-toegang
• Elk geïnstalleerd pakket wordt netjes in een sandbox geplaatst in zijn eigen kelder, zodat u niet bewaar verdwaalde bestanden over uw hele systeem, alleen symbolische links van bin, man, etc.
• Heeft handleidingen en automatisering om uw eigen formulebestanden te maken (d.w.z. pakketbeschrijvingen)
• Geschreven in ruby en alle formules zijn beknopte ruby-scripts
• Snellere installaties vanwege vooraf gecompileerde binaries

pkgin

• Snellere installaties vanwege voorgecompileerde binaire bestanden
• Alles geïnstalleerd in / opt / pkg /
• ondersteund door pkgsrc-gemeenschap en Joyent
• Bekend om te werken op NetBSD, DragonFly BSD, Solaris, Debian, Mac OS X, Minix

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

http://pkgin.net/

Opmerkingen

• Reacties zijn niet bedoeld voor uitgebreide discussie; dit gesprek is verplaatst naar chat . Als de vergrendeling moet worden opgeheven, meld dat probleem dan op Vraag een andere meta of met een vlag.

MacPorts

Het is onafhankelijker van Mac OS X, dit betekent dat MacPorts veel van de systeembibliotheken en software die al beschikbaar in Mac OS X en trekken in plaats daarvan zijn eigen versie , wat langzamer kan zijn wanneer het hulpprogramma dat u installeert een aantal grote bibliotheken en software vereist.

Maar dit soort keuze is veiliger omdat de pakketten die je hebt geïnstalleerd minder worden beïnvloed door Apples systeemupdate / upgrade procedure.

Homebrew

Het is meer afhankelijk van bestaande Mac OS X geïnstalleerde pakketten, dus dit zal de installatie van pakketten versnellen en overbodige bibliotheken minimaliseren.

Maar het risico is dat geïnstalleerde pakketten mogelijk kapot zijn n vanwege Apples systeemupdate / upgrade.

Dit zijn dus de twee verschillende soorten afwegingen.

Ook neemt Homebrew / usr / local standaard, waarmee sommige mensen dit niet leuk vinden omdat het op de een of andere manier conflicteren met de unix-traditie en kunnen problemen veroorzaken als je daar al iets hebt geïnstalleerd (MySQL, etc.)

Afgezien van deze verschillen, gezien de pakketten die deze twee kunnen bieden, kun je met deze twee commandos controleren of je MacPorts / Homebrew al hebt geïnstalleerd, die je de pakketten laten zien die ze momenteel leveren:

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

En je zult ontdekken dat MacPorts veel meer pakketten heeft dan Homebrew.

(19399 versus 3583 op 13 mei 2016)

Opmerkingen

• Als opmerking over het verschillende aantal pakketten: Homebrew bevat beslist geen pakketten voor programmeertalen die hun eigen verpakkingssysteem hebben (rubygems / pip / cpan…) of voor software waarvoor een aantoonbaar geschikter OS X-installatieprogramma beschikbaar is (MacTeX). Ook bevinden duplicaten en oudere versies zich niet in de standaard opslagplaats, maar bevatten ze alternatieve tap opslagplaatsen. Vergelijk dit met macports, dat bijvoorbeeld een IPython-poort bevat voor alle inbegrepen Python-versies. Het is een soort andere filosofie die natuurlijk het aantal pakketten in macports verhoogt.
• Uitstekende link! terrychay.com/article/macports-vs-homebrew.shtml Bedankt!
• @YaOz, je zou vast wel iets kunnen veranderen anders dan /usr/local?
• @Pacerier Ik geloof dat ergens anders dan /usr/local/ “niet ondersteund” of “ontmoedigd” is .

Om een paar van mijn eigen gedachten toe te voegen die op zijn minst rond eind 2014 waar lijken .

Homebrew, sinds een paar jaar geleden, heeft zeker de overhand op het gebied van mindshare. Je zult veel blogs vinden met mensen die praten over hoeveel gelukkiger ze zijn met Homebrew – meestal vanwege het hele “MacPorts trekt in de hele wereld” versus “Homebrew maakt gebruik van wat je al hebt”.

IMO, MacPorts is nu echter een ander beest dan een paar jaar geleden. Toen ik voor het eerst overschakelde naar OS X & MacPorts gebruikte, was de MP-filosofie inderdaad frustrerend omdat bijna alles vanaf de bron is opgebouwd. Een nieuwe installatie was bijzonder pijnlijk / traag. In het afgelopen jaar, puur op basis van mijn eigen indrukken, lijkt het erop dat 90% van de MP-pakketten binaries zijn & dus de installatie is nu eigenlijk heel snel. Voor zover ik heb begrepen, gaat Homebrew ook in deze richting met “Bottles”, maar ik krijg de indruk dat de meeste dingen die je op dit moment via HB installeert, vanaf de bron worden gecompileerd.

Dus, al was het maar om een tegenwicht te bieden, MacPorts lijkt eigenlijk de “snellere” o ption deze dagen. De mening van de meeste mensen over MP lijkt echter gebaseerd te zijn op ervaringen van circa 2011-12 of zo & houdt hier niet echt rekening mee. Neem dit echter met een korreltje zout, aangezien ik “geen gewone HB-gebruiker ben (en het is nogal pijnlijk om beide naast elkaar te gebruiken).

Ik denk dat HB voordelen heeft die betekenen dat het waarschijnlijk zal winnen de oorlog “op de lange termijn echter

• HB is helemaal Ruby, terwijl MacPorts en zijn pakketformules zijn geschreven in TCL, wat … niet bepaald een populaire scripttaal is. vrij verdomd eenvoudig om je eigen portfile te maken.
• HB is gebaseerd op GitHub & lijkt dus veel meer welkom voor nieuwe bijdragers, terwijl MacPorts ergens zijn eigen SVN-repository host Ik denk – wat in wezen de verschillende leeftijden van beide projecten weerspiegelt, veronderstel ik.
• Zoals gezegd is de algemene consensus dat MacPorts is vervangen door HB &, terecht of ten onrechte trekt dat meer mensen naar zich toe.

Anders heeft YaOZl & kLy het belangrijkste verschil in termen van sudo, afhankelijkheden enz. vrij goed afgedekt. Persoonlijk Ik vinden wel dat MacPorts soms tot hoofdpijn leidt in termen van andere programmas die niet verwachten dat er iets in /opt/local staat, dingen worden geïnstalleerd met rootrechten enz. & er zijn enkele dingen die over het algemeen het beste niet met MacPorts kunnen worden geïnstalleerd (bijv je kunt Rails installeren via MacPorts, maar je zou gek zijn om het niet te installeren via Rubys normale Gem-beheer). Anders dan dat, hoewel ik “een grote fan ben van de MacPorts-filosofie om zijn eigen kleine wereld te bouwen & niet te vertrouwen op een voorverpakte OS X-bibliotheek – als het werkt, en meestal doet, alles is doodeenvoudig. Dat is eigenlijk wat je wilt van een pakketbeheerder. En zoals ik al zei, is het op dit moment verdomd snel om de meeste dingen op te zetten.

Ik hoop dat iets daarvan nuttig was.

Reacties

• ” Zoals gezegd is de algemene consensus dat MacPorts is vervangen door HB &, terecht of ten onrechte, dat meer mensen naar zich toe trekt. ” … dit voelt als een zeer oppervlakkige verklaring …populair zijn versus het leveren van kwaliteit zijn niet hetzelfde en impliceren geenszins dat de tweede ” vervangen is ” door de eerste.
• MacPorts gebruikt nu Github. Zie guide.macports.org/#project.github : ” Het MacPorts-project gebruikt het gedistribueerde versiebeheersysteem van Git om de code voor het hele project te beheren. Onze hoofdrepositorys worden gehost op GitHub. We onderhouden openbare repositories voor bijna al onze projectcode en documentatie, inclusief een GitHub-repository voor het MacPorts-systeem zelf, voor de MacPorts-poorten en zelfs voor de gids die je nu leest. ”

Iets dat andere antwoorden (tot nu toe) niet lijken te hebben genoemd, is dat MacPorts heeft uitstekende ondersteuning voor oudere versies van macOS. Homebrew ondersteunt alleen de besturingssystemen die momenteel door Apple worden ondersteund, wat meestal de laatste drie releases betekent. Vanaf augustus 2020 zijn bijvoorbeeld alleen Catalina, Mojave en High Sierra compatibel met Homebrew.

Daarentegen kan MacPorts worden geïnstalleerd op Tiger (!), En het project onderhoudt speciale patches om de software te behouden. werken waar mogelijk. Ze onderhouden ook een ” Legacy Support ” -bibliotheek die symbolen terugzet van nieuwe versies van macOS naar oudere; als u tijdens het compileren een koppeling maakt met deze bibliotheek, kan allerlei nieuwe software plotseling werken op oudere systemen!

Dus als u een oude versie van macOS gebruikt, of als u denkt dat u op een huidige besturingssysteem voorbij de vervaldatum van Apple, dat is zeker een reden om voor MacPorts te gaan.

Brew was volledig soepel voor mij om te gebruiken, dus ik kan niet vertellen over de nadelen ervan. Enkele nadelen van MacPorts:

• u moet Xcode installeren vanaf de Apple Developer-site , daarom moet u een Apple-ontwikkelaarsaccount hebben (waarvoor nu een creditcard vereist is) en download bijna 3,5 GB aan spullen;
• als poort 873 (rsync) wordt geblokkeerd door je firewall, “moet je handmatig het HTTPS-protocol configureren ;
• de HTTP (S) -server waarvan pakketten worden gedownload is (vaak) extreem traag (minder dan 20 KiB / s gisteren; getest met een paar zeer betrouwbare Gigabit verbindingen in verschillende landen) en kan mislukken met fout Bewerking te traag. Minder dan 1024 bytes / sec overgedragen in de afgelopen 60 seconden , waardoor u alles helemaal opnieuw moet doen.

Er zijn verschillende zeer populaire vragen over de eerste twee punten.

Opmerkingen

• Dit was mijn ervaring ImageMagick installeren op 10.6; brouwen was erg eenvoudig, maar ‘ t omvatten de JP2-afgevaardigde. imagemagick.org/script/binary-releases.php
• brew en macports hebben alleen Xcode-opdrachtregelprogrammas nodig, dus hier hetzelfde.
• @Mark I ‘ m weet niet zeker wat je bedoelt, maar brouwsel werkte perfect voor mij zonder Xcode.
• Jij ‘ Ik heb een complier nodig voor brew en MacPorts, die kan worden geïnstalleerd via de Xcode Command Line Tools. Je hebt de Xcode applicatie niet nodig.
• Ik vergat hoe lelijk het is om dat ding te synchroniseren achter een firewall … yikes!