Hva er fordeler og ulemper for MacPorts, Fink og Homebrew?

Definitivt Homebrew. Jeg startet med Fink, byttet deretter til MacPorts (lykkeligere), deretter Homebrew (mye, mye lykkeligere). Dette er mine grunner til å bruke hver (en pro-liste hvis du vil):

Fink

• Apt-basert – føl deg som hjemme hvis du kommer fra en Debian-basert miljø
• Binære pakker – pakker er tilgjengelige som binærfiler, så ingen lange kompileringstider. Praktisk om jeg har funnet ut at de forhåndskompilerte binærfiler alltid var utdaterte, og at jeg uansett måtte kompilere ting til systemet mitt

MacPorts

• I motsetning til hjemmebryggere ikke avhengig av MacOS-biblioteket som kan endre seg i fremtiden.
• Installer alt i / opt / local
• Hyggelig varianter system som lar deg tilpasse build
• Enkle og intuitive portfiler, lar deg også legge til dine egne
• støtter mange versjoner av OSX og macos som går tilbake til Tiger inkludert PowerPC-versjoner se annet svar

Homebrew

• Maksimal utnyttelse av det som følger med OS X. I motsetning til Fink eller MacPorts, det krever ikke at du bygger / installerer rubin og biblioteker fra bunnen av bare for å installere noe lite Ruby-basert verktøy.
• Installeres i /usr/local
• Installer uten root-tilgang
• Hver installerte pakke er sandkassert i sin egen kjeller, slik at du ikke ave bortkomne filer over hele systemet ditt, bare symlinker fra bin, man osv.
• Har guider og automatisering for å lage dine egne formelfiler (dvs. pakkebeskrivelser)
• Skrevet i rubin og alle formler er kortfattede ruby-skript
• Raskere installasjoner på grunn av forhåndskompilerte binærfiler

pkgin

• Raskere installasjoner på grunn av forhåndskompilerte binærfiler
• Alt installert i / opt / pkg /
• støttet av pkgsrc community og Joyent
• Kjent for å jobbe med NetBSD, DragonFly BSD, Solaris, Debian, Mac OS X, Minix

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

http://pkgin.net/

Kommentarer

• Kommentarer er ikke for utvidet diskusjon; denne samtalen er flyttet til chat . Hvis låsen må frigjøres, kan du ta opp problemet på Be forskjellige meta eller med et flagg.

MacPorts

Det er mer uavhengig av Mac OS X, dette betyr at MacPorts bare vil ignorere mange av systembibliotekene og programvarene som allerede tilgjengelig i Mac OS X og trekker sin egen i stedet , noe som kan være tregere når verktøyet du installerer krever et sett med store biblioteker og programvare.

Men Denne typen valg er tryggere fordi pakkene du installerte er mindre påvirket av Apples systemoppdatering / oppgradering prosedyre.

Homebrew

Det er mer avhengig av eksisterende Mac OS X-installerte pakker, så dette vil øke installasjonen av pakker og minimere overflødige biblioteker.

Men risikoen er installerte pakker kan være ødelagte n på grunn av Apples systemoppdatering / oppgradering.

Så dette er de to forskjellige typene avveininger.

Dessuten tar Homebrew over / usr / local som standard, som noen ikke liker dette fordi det på en eller annen måte i konflikt med unix-tradisjonen og kan forårsake problemer hvis du allerede har installert noe der (MySQL, etc.)

Bortsett fra disse forskjellene, med tanke på pakkene disse to kan tilby, kan du sjekke med disse to kommandoene hvis du allerede har MacPorts / Homebrew installert, som viser deg pakkene de for øyeblikket ga:

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

Og du vil finne ut at MacPorts har mange flere pakker enn Homebrew.

(19399 mot 3583 13. mai 2016)

Kommentarer

• Som en kommentar til det forskjellige antallet pakker: Homebrew inkluderer bestemt ikke pakker for programmeringsspråk som har sitt eget emballasjesystem (rubygems / pip / cpan…) eller for programvare som det uten tvil er mer passende OS X-installasjonsprogram tilgjengelig (MacTeX). Også duplikater og eldre versjoner er ikke i standard repo, men inkluderer i alternative trykk repoer. Sammenlign dette med macports, som f.eks. Inneholder en IPython-port for alle inkluderte Python-versjoner. Det er litt av en annen filosofi som naturlig øker antall pakker i macports.
• Utmerket lenke! terrychay.com/article/macports-vs-homebrew.shtml Takk!
• @YaOz, Du kan sikkert endre hjemmebrygging for å bruke noe annet enn /usr/local?
• @Pacerier Jeg tror noe annet sted enn /usr/local/ er «ikke støttet» eller «motløs» .

Bare for å legge til noen av mine egne tanker som virker sanne rundt i det minste i 2014 .

Homebrew, som for et par år siden, har definitivt overtaket når det gjelder mindshare. Du vil finne mange blogger med folk som snakker om hvor mye lykkeligere de er med Homebrew – vanligvis på grunn av hele «MacPorts pulls in the world» vs «Homebrew benytter seg av det du allerede har».

Imidlertid er IMO, MacPorts et annet dyr nå enn for noen år siden. Da jeg først byttet til OS X & brukte MacPorts, var MP-filosofien virkelig frustrerende fordi nesten alt ble bygget fra kilden. En ny installasjon var spesielt smertefull / treg. Det siste året eller så, basert på mine egne inntrykk, virker det som om 90% av MP-pakkene er binære filer & så installasjonen er faktisk veldig rask nå. Fra det jeg samler går Homebrew også i denne retningen med «Bottles» men jeg får inntrykk av at det meste du installerer via HB på dette tidspunktet vil bli samlet fra kilden.

Så hvis bare for å gi en motstridende mening, synes MacPorts å være den «raskere» o ption i disse dager. Men de fleste folks meninger fra MP ser ut til å være basert på erfaringer fra ca 2011-12 eller så & tar ikke virkelig hensyn til dette. Ta dette med et saltkorn, ettersom jeg ikke er en vanlig HB-bruker (og det er ganske vondt å bruke begge side ved side).

Jeg tror HB har fordeler som betyr at det sannsynligvis vil «vinne krigen «i det lange løp skjønt

• HB er alle Ruby mens MacPorts, og dens pakkeformler, er skrevet i TCL som er … ikke akkurat et populært skriptspråk. Det sa ganske jævla enkelt å lage din egen portfil.
• HB er basert på GitHub & virker derfor mye mer imøtekommende for nye bidragsytere, mens MacPorts er vert for sitt eget SVN-lager et eller annet sted Jeg tror – som i utgangspunktet gjenspeiler forskjellige aldre for begge prosjektene, antar jeg.
• Som nevnt er den generelle konsensusen at MacPorts er blitt erstattet av HB &, riktig eller feilaktig, det trekker flere mennesker mot det.

Ellers dekket YaOZl & kLy hovedforskjellen når det gjelder sudo, avhengigheter osv. ganske bra. Personlig JEG finner ut at MacPorts noen ganger fører til hodepine når det gjelder andre programmer som ikke forventer at noe skal være i /opt/local, ting blir installert med rottillatelser osv. & det er noen ting som vanligvis ikke er best installert med MacPorts (f.eks du kan installere Rails via MacPorts, men du vil være gal for ikke å installere den via Rubys normale perlehåndtering). Annet enn det, selv om jeg «er en stor fan av MacPorts-filosofien om å bygge sin egen lille verden & ikke stole på noe ferdigpakket OS X-bibliotek – når det fungerer, og det gjør det meste, alt er ganske enkelt. Hvilket er det du virkelig vil ha av en pakkeforvalter. Og som jeg nevnte, på dette tidspunktet er det ganske jævla å sette opp det meste.

Håper noe av det var nyttig. / p>

Kommentarer

• » Som nevnt er generell enighet at MacPorts er blitt erstattet av HB &, med rette eller feil, som trekker flere mennesker mot det. » … dette føles som en veldig overfladisk uttalelse …å være populær mot å tilby kvalitet er ikke det samme, og på ingen måte antyde at det andre er » erstattet » av den første.
• MacPorts bruker nå Github. Se guide.macports.org/#project.github : » MacPorts-prosjektet bruker Git distribuert versjonskontrollsystem for å administrere koden for hele prosjektet. Våre hovedlagre er vert på GitHub. Vi opprettholder offentlige arkiver for nesten all vår prosjektkode og dokumentasjon, inkludert et GitHub-arkiv for selve MacPorts-systemet, for MacPorts-portene og til og med for guiden du leser akkurat nå. »

Noe som andre svar (så langt) ikke ser ut til å ha nevnt, er at MacPorts har utmerket støtte for eldre versjoner av macOS. Homebrew støtter bare operativsystemene som for øyeblikket støttes av Apple, som vanligvis betyr de tre siste utgivelsene. Fra og med august 2020 er for eksempel bare Catalina, Mojave og High Sierra kompatible med Homebrew.

Derimot kan MacPorts installeres på Tiger (!), Og prosjektet har spesielle oppdateringer for å beholde programvare. jobber der det er mulig. De har også et » Legacy Support » -bibliotek som støtter symboler fra nye versjoner av macOS til eldre; kobling mot dette biblioteket mens du kompilerer, kan gjøre at alle slags ny programvare plutselig fungerer på eldre systemer!

Så hvis du kjører en gammel versjon av macOS, eller hvis du tror du kan trenge å være på en nåværende operativsystem etter Apples utløpsdato, det er absolutt en grunn til å gå med MacPorts.

Brygg var helt glatt for meg å bruke, så jeg kan ikke fortelle om ulempene. Noen ulemper ved MacPorts:

• du må installere Xcode fra Apple Developer-nettstedet , derfor må du ha en Apple-utviklerkonto (som nå krever kredittkort) og last ned nesten 3,5 GB med ting;
• hvis port 873 (rsync) er blokkert av brannmuren din, må du manuelt konfigurere HTTPS-protokollen ;
• HTTP (S) -serveren som pakkene lastes ned fra, er (ofte) ekstremt treg (under 20 KiB / s i går; testet fra et par veldig pålitelige Gigabit tilkoblinger i forskjellige land) og kan mislykkes med feil Driften er for treg. Mindre enn 1024 byte / sek overført de siste 60 sekundene , og tvinger deg til å gjøre om alt fra bunnen av.

Det er flere veldig populære spørsmål om de to første punktene.

Kommentarer

• Dette var min erfaring installere ImageMagick 10.6; brygge var veldig enkelt, men ‘ t inkluderer JP2-delegaten. imagemagick.org/script/binary-releases.php
• brygge og macports krever bare Xcode kommandolinjeverktøy så det samme her.
• @Mark I ‘ jeg er ikke sikker på hva du mener, men brygge fungerte perfekt for meg uten Xcode.
• Du ‘ trenger en complier for brygge og MacPorts, som kan installeres via Xcode Command Line Tools. Du trenger ikke Xcode -programmet .
• Jeg glemte hvor stygt det er å synkronisere den tingen når du er bak en brannmur … yikes!