Vad är fördelar och nackdelar med MacPorts, Fink och Homebrew?

Definitivt Homebrew. Jag började med Fink, bytte sedan till MacPorts (lyckligare), sedan Homebrew (mycket, mycket lyckligare). Det här är mina skäl till att använda var och en (en pro-lista om du vill):

Fink

• Apt-baserad – känn dig som hemma om du kommer från en Debian-baserad miljö
• Binära paket – paket finns som binära så inga långa sammanställningstider. Praktiskt taget trots att jag har hittat att de förkompilerade binärfilerna alltid var föråldrade och jag var tvungen att sammanställa saker för mitt system ändå

MacPorts

• Till skillnad från hembryggeri beror inte på MacOS-biblioteket som kan förändras i framtiden.
• Installera allt i / opt / local
• Trevligt varianter system som låter dig anpassa build
• Enkla och intuitiva portfiler, låter dig också lägga till dina egna
• stöder många versioner av OSX och macos som går tillbaka till Tiger inklusive PowerPC-versioner se annat svar

Homebrew

• Maximal utnyttjande av vad som kommer med OS X. Till skillnad från Fink eller MacPorts, det kräver inte att du bygger / installerar rubin och bibliotek från grunden bara för att installera ett litet Ruby-baserat verktyg.
• Installeras i /usr/local
• Installera utan root-åtkomst
• Varje installerat paket är rent sandlådat i sin egen källare så att du inte ave avvikande filer över hela ditt system, bara symlänkar från bin, man, etc.
• Har guider och automatisering för att skapa dina egna formelfiler (dvs. paketbeskrivare)
• Skrivet i rubin och alla formler är kortfattade rubinskript
• Snabbare installationer på grund av förkompilerade binärfiler

pkgin

• Snabbare installationer på grund av förkompilerade binärfiler
• Allt installerat i / opt / pkg /
• med stöd av pkgsrc community och Joyent
• Känd för att fungera på NetBSD, DragonFly BSD, Solaris, Debian, Mac OS X, Minix

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

http://pkgin.net/

Kommentarer

• Kommentarer är inte för längre diskussion; den här konversationen har flyttats till chatt . Om låset måste frigöras, ta upp problemet på Fråga olika meta eller med en flagga.

MacPorts

Det är mer oberoende av Mac OS X, det betyder att MacPorts bara kommer att ignorera många av systembiblioteken och programvaror som redan har tillgängligt i Mac OS X och drar sin egen istället , vilket kan vara långsammare när verktyget du installerar kräver en uppsättning stora bibliotek och programvaror.

Men denna typ av val är säkrare eftersom paketen du installerade påverkas mindre av Apples systemuppdatering / uppgradering procedur.

Homebrew

Det är mer beroende av befintliga Mac OS X-installerade paket, så detta kommer att påskynda installationen av paket och minimera redundanta bibliotek.

Men risken för att installerade paket kan vara trasiga n på grund av Apples systemuppdatering / uppgradering.

Så det här är de två olika slags avvägningar.

Dessutom tar Homebrew över / usr / local som standard, med vilken vissa människor gillar inte detta eftersom det på något sätt konflikt med unix-traditionen och kan orsaka problem om du redan har installerat något där (MySQL, etc.))

Förutom dessa skillnader, med tanke på de paket som dessa två kan erbjuda, kan du kontrollera med dessa två kommandon om du redan har MacPorts / Homebrew installerat, som visar dig de paket de för närvarande tillhandahåller:

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

Och du kommer att upptäcka att MacPorts har många fler paket än Homebrew.

(19399 mot 3583 den 13 maj 2016)

Kommentarer

• Som en anmärkning om det olika antalet paket: Homebrew inkluderar bestämt inte paket för programmeringsspråk som har sitt eget förpackningssystem (rubygems / pip / cpan …) eller för programvara för vilken det finns ett lämpligt OS X-installationsprogram (MacTeX). Dubbletter och äldre versioner finns inte i standardrepet, men ingår i alternativa tryck repor. Jämför detta med macports, som t.ex. innehåller en IPython-port för alla inkluderade Python-versioner. Det är typ av en annan filosofi som naturligtvis ökar antalet paket i macports.
• Utmärkt länk! terrychay.com/article/macports-vs-homebrew.shtml Tack!
• @YaOz, du kan säkert byta hembröd för att använda något annat än /usr/local?
• @Pacerier Jag tror att någon annanstans än /usr/local/ är ”stöds inte” eller ”avskräckt” .

Bara för att lägga till några av mina egna tankar som verkar vara sanna omkring 2014 åtminstone .

Homebrew, som för ett par år sedan, har definitivt överhanden när det gäller mindshare. Du kommer att hitta många bloggar med folk som pratar om hur mycket lyckligare de är med Homebrew – vanligtvis på grund av hela ”MacPorts drar i hela världen” vs ”Homebrew använder sig av det du redan har”.

IMO, MacPorts är dock ett annat odjur nu än för några år sedan. När jag först bytte till OS X & använde MacPorts var MP-filosofin verkligen frustrerande eftersom nästan allt byggdes från källan. En ny installation var särskilt smärtsam / långsam. Men under det senaste året eller så, uteslutande baserat på mina egna intryck, verkar det som om 90% av MP-paketen är binära & så installationen går faktiskt väldigt snabbt nu. Från det jag samlar går Homebrew också i den här riktningen med ”Flaskor” men jag får intrycket att de flesta saker du installerar via HB vid denna tidpunkt kommer att sammanställas från källan.

Så, om bara för att ge en utjämnande åsikt, verkar MacPorts faktiskt vara den ”snabbare” o ption idag. Men de flesta folks åsikter från MP verkar baseras på erfarenheter från cirka 2011-12 eller så & tar verkligen inte hänsyn till detta. Ta detta med ett saltkorn men eftersom jag inte är en vanlig HB-användare (och det är ganska smärtsamt att använda båda sida vid sida).

Jag tror att HB har fördelar som betyder att det förmodligen kommer att ”vinna kriget ”i det långa loppet dock

• HB är alla Ruby medan MacPorts och dess paketformler är skrivna i TCL vilket är … inte precis ett populärt skriptspråk. ganska jävla enkelt att skapa din egen portfil.
• HB är baserat kring GitHub & verkar alltså mycket mer välkomnande för nya bidragsgivare medan MacPorts är värd för sitt eget SVN-arkiv någonstans Jag tror – som i princip återspeglar de olika åldrarna för båda projekten antar jag.
• Som nämnts är det allmänna samförståndet att MacPorts har ersatts av HB &, rätt eller felaktigt, det drar fler människor mot det.

Annars täckte YaOZl & kLy huvudskillnaden när det gäller sudo, beroenden etc. ganska bra. Jag finner att MacPorts ibland leder till huvudvärk när det gäller andra program som inte förväntar sig att något ska vara i /opt/local, saker som installeras med rootbehörigheter etc & det finns några saker som i allmänhet bäst inte är installerade med MacPorts (t.ex. du kan installera Rails via MacPorts men du skulle vara galen att inte installera den via Rubys normala Gem Management). Annat än det även om jag ”är ett stort fan av MacPorts-filosofin att bygga sin egen lilla värld & och inte förlita mig på något färdigförpackat OS X-bibliotek – när det fungerar, och det gör det mest, allt är död enkelt. Vilket är vad du vill ha av en Package Manager egentligen. Och som jag nämnde är det vid denna tidpunkt ganska jävla snabbt att ställa in de flesta saker.

Hoppas att något av det var användbart.

Kommentarer

• ” Som nämnts är det allmänna samförståndet att MacPorts har ersatts av HB &, rätt eller fel, som drar fler människor mot det. ” … detta känns som ett mycket ytligt uttalande …att vara populär jämfört med att tillhandahålla kvalitet är inte detsamma och antyder på intet sätt att den andra är ” ersatt ” av den första.
• MacPorts använder nu Github. Se guide.macports.org/#project.github : ” MacPorts-projektet använder det distribuerade Git-versionskontrollsystemet för att hantera koden för hela projektet. Våra huvudförvar finns på GitHub. Vi underhåller offentliga arkiv för nästan all vår projektkod och dokumentation, inklusive ett GitHub-arkiv för själva MacPorts-systemet, för MacPorts-portarna och till och med för guiden du läser just nu. ”

Något som andra svar (hittills) inte verkar ha nämnt är att MacPorts har utmärkt stöd för äldre versioner av macOS. Homebrew stöder endast operativsystem som för närvarande stöds av Apple, vilket vanligtvis betyder de tre senaste utgåvorna. Från och med augusti 2020 är till exempel endast Catalina, Mojave och High Sierra kompatibla med Homebrew.

Däremot kan MacPorts installeras på Tiger (!), Och projektet har speciella korrigeringar för att behålla programvara arbetar där det är möjligt. De har också ett ” Legacy Support ” -bibliotek som stöder symboler från nya versioner av macOS till äldre; länka mot det här biblioteket medan du kompilerar kan alla typer av ny programvara plötsligt fungera på äldre system!

Så om du kör en gammal version av macOS eller om du tror att du kan behöva stanna kvar nuvarande operativsystem efter Apples utgångsdatum, det är definitivt en anledning att gå med MacPorts.

Brew var helt smidig för mig att använda, så jag kan inte berätta om dess nackdelar. Några nackdelar med MacPorts:

• du måste installera Xcode från Apples utvecklarwebbplats , därför måste du ha ett Apple-utvecklarkonto (som nu kräver kreditkort) och ladda ner nästan 3,5 GB grejer.
• om port 873 (rsync) blockeras av din brandvägg måste du konfigurera HTTPS-protokollet manuellt ;
• HTTP (S) -servern från vilken paket laddas ner är (ofta) extremt långsam (under 20 KiB / s igår; testad från ett par mycket pålitlig Gigabit anslutningar i olika länder) och kan misslyckas med felet Funktionen är för långsam. Mindre än 1024 byte / sek överfördes de senaste 60 sekunderna , vilket tvingar dig att göra om allt från grunden.

Det finns flera mycket populära frågor om de två första punkterna.

Kommentarer

• Det här var min upplevelse att installera ImageMagick den 10.6; bryggning var väldigt enkelt, men ’ t inkludera JP2-delegaten. imagemagick.org/script/binary-releases.php
• bryggning och macport kräver bara Xcode-kommandoradsverktyg så detsamma här.
• @Mark I ’ jag är inte säker på vad du menar, men bryggning fungerade perfekt för mig utan Xcode.
• Du ’ Behöver en kompletterare för bryggning och MacPorts, som kan installeras via Xcode Command Line Tools. Du behöver inte Xcode -programmet .
• Jag glömde hur ful det är att synkronisera den där saken bakom en brandvägg … yikes!