Jeg migrerer bare fra Ubuntu Linux til Mac, og alt er nyt, og jeg lærer om en masse ting igen.

På Linux havde jeg den fremragende apt-get til at administrere softwarepakker. Jeg googlede efter et alternativ på Mac og fandt ud af om MacPorts, Fink og Homebrew.

Jeg bruger primært denne computer til at udvikle Ruby on Rails-applikationer.

Så hvad er forskellen mellem dem? Hvilke er ulemperne og ulemperne? Hvilken er bedst vedligeholdt og har flere pakker?

Kommentarer

  • Jeg redigerede din titel for at få den til at matche dit rigtige spørgsmål. På de fleste Stack Exchange-websteder stilles spørgsmål, der beder om “, de bedste ” er forkert.
  • Hvorfor har du brug for nogen af disse vandt ‘ t ruby ‘ s perler være tilstrækkelige?
  • for mere om hvorfor duplikater ikke er ‘ t altid dårligt: apple.stackexchange.com/questions/11461/… der er også et par flere alternativer der
  • Brugte det aldrig selv, men måske ville en sammenligning med pkgin også være nyttig.

Svar

Absolut Homebrew. Jeg startede med Fink, skiftede derefter til MacPorts (lykkeligere) og derefter Homebrew (meget, meget gladere). Dette er mine grunde til at bruge hver (en pro-liste, hvis du vil):

Fink

  • Apt-baseret – føler dig hjemme, hvis du kommer fra en Debian-baseret miljø
  • Binære pakker – pakker er tilgængelige som binære filer, så ingen lange kompileringstider. Praktisk set har jeg fundet ud af, at de forud kompilerede binære filer altid var forældede, og jeg var nødt til at kompilere ting til mit system alligevel

MacPorts

  • I modsætning til hjemmebrygget gør afhænger ikke af MacOS-biblioteket, der kan ændre sig i fremtiden.
  • Installer alt i / opt / local
  • Nice varianter system der lader dig tilpasse build
  • Nemme og intuitive portfiler, giver dig også mulighed for at tilføje dine egne
  • understøtter mange versioner af OSX og macos, der går tilbage til Tiger inklusive PowerPC-versioner se andet svar

Homebrew

  • Maksimal udnyttelse af, hvad der følger med OS X. I modsætning til Fink eller MacPorts, det kræver ikke, at du bygger / installerer rubin og biblioteker fra bunden bare for at installere noget lille Ruby-baseret værktøj.
  • Installeres i /usr/local
  • Installer uden rootadgang
  • Hver installeret pakke sandkasseres rent i sin egen kælder, så du ikke ave omstrejfende filer overalt i dit system, bare symlinks fra bin, mand osv.
  • Har guider og automatisering til at oprette dine egne formelfiler (dvs. pakkebeskrivere)
  • Skrevet i rubin og alle formler er kortfattede rubin-scripts
  • Hurtigere installationer på grund af præ-kompilerede binære filer

pkgin

  • Hurtigere installationer på grund af præ-kompilerede binære filer
  • Alt installeret i / opt / pkg /
  • bakket op af pkgsrc community og Joyent
  • Kendt til at arbejde på NetBSD, DragonFly BSD, Solaris, Debian, Mac OS X, Minix

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

http://pkgin.net/

Kommentarer

Svar

MacPorts

Det er mere uafhængigt af Mac OS X, det betyder, at MacPorts bare vil ignorere mange af systembibliotekerne og softwaren, der allerede har tilgængelig i Mac OS X og træk sin egen i stedet , hvilket kan være langsommere, når det hjælpeprogram, du installerer, kræver nogle store biblioteker og software.

Men denne type valg er sikrere, fordi de pakker, du har installeret, er mindre påvirket af Apples systemopdatering / opgradering procedure.

Homebrew

Det er mere afhængigt af eksisterende Mac OS X-installerede pakker, så dette vil fremskynde installationen af pakker og minimere overflødige biblioteker.

Men risikoen er installerede pakker kan være ødelagte n på grund af Apples systemopdatering / opgradering.

Så dette er de to forskellige former for afvejning.

Også Homebrew overtager / usr / local som standard, hvormed nogle mennesker ikke kan lide dette fordi det på en eller anden måde konflikt med unix-traditionen og kan forårsage problemer, hvis du allerede har installeret noget der (MySQL osv.)

Bortset fra disse forskelle, i betragtning af de pakker, disse to kan tilbyde, kan du tjekke med disse to kommandoer, hvis du allerede har MacPorts / Homebrew installeret, som viser dig de pakker, de aktuelt leverede: 

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

Og du vil finde ud af, at MacPorts har mange flere pakker end Homebrew.

(19399 mod 3583 den 13. maj 2016)

Kommentarer

  • Som en bemærkning om det forskellige antal pakker: Homebrew inkluderer bestemt ikke pakker til programmeringssprog, der har deres eget emballagesystem (rubygems / pip / cpan …) eller til software, hvor et uden tvivl mere passende OS X-installationsprogram er tilgængeligt (MacTeX). Også duplikater og ældre versioner er ikke i standardrevisionen, men inkluderer i alternative tryk repoer. Sammenlign dette med macports, som f.eks. Indeholder en IPython-port til alle inkluderede Python-versioner. Det er en slags anden filosofi, der naturligvis øger antallet af pakker i macports.
  • Fremragende link! terrychay.com/article/macports-vs-homebrew.shtml Tak!
  • @YaOz, du kunne helt sikkert ændre hjemmebrygget for at bruge noget andet end /usr/local?
  • @Pacerier Jeg tror, at andre steder end /usr/local/ er “ikke understøttet” eller “modløs” .

Svar

Bare for at tilføje nogle af mine egne tanker, der synes sandt omkring i det mindste i slutningen af 2014 .

Homebrew har som for et par år siden bestemt overhånden med hensyn til mindshare. Du finder mange blogs med folk, der taler om, hvor meget lykkeligere de er med Homebrew – normalt på grund af hele “MacPorts trækker i hele verden” vs “Homebrew gør brug af det, du allerede har” ting.

Imidlertid er IMO, MacPorts et andet dyr nu, end det var for et par år siden. Da jeg først skiftede til OS X & brugte MacPorts, var MP-filosofien virkelig frustrerende fordi næsten alt blev bygget fra kilden. En ny installation var særligt smertefuld / langsom. I løbet af det sidste år eller deromkring, udelukkende baseret på mine egne indtryk, ser det ud til, at 90% af MP-pakkerne er binære filer & så installationen er faktisk virkelig hurtig nu. Fra det, jeg samler, bevæger Homebrew sig også i denne retning med “Flasker”, men jeg får det indtryk, at de fleste ting, du installerer via HB på dette tidspunkt, vil blive samlet fra kilden.

Så hvis det kun er for at give en udligende mening, synes MacPorts faktisk at være den “hurtigere” o ption i disse dage. Men de fleste folks meninger fra MP synes at være baseret på erfaringer fra ca. 2011-12 eller deromkring & tager det ikke virkelig i betragtning. Tag dette med et saltkorn, selvom jeg ikke er en almindelig HB-bruger (og det er ret smertefuldt at bruge begge sider ved siden af hinanden).

Jeg tror, HB har fordele, der betyder, at det sandsynligvis vil vinde krigen “i det lange løb skønt

  • HB er alle Ruby, mens MacPorts og dets pakkeformler er skrevet i TCL, hvilket er …. ikke ligefrem et populært script-sprog. Det sagde, at ret forbandet let at oprette din egen portfil.
  • HB er baseret omkring GitHub & virker således meget mere imødekommende for nye bidragydere, mens MacPorts er vært for sit eget SVN-arkiv et eller andet sted Jeg tror – som dybest set afspejler de forskellige aldre for begge projekter, formoder jeg.
  • Som nævnt er den generelle konsensus, at MacPorts er blevet afløst af HB &, med rette eller forkert, der trækker flere mennesker mod det.

Ellers dækkede YaOZl & kLy den største forskel med hensyn til sudo, afhængigheder osv. ret godt. Jeg finder ud af, at MacPorts nogle gange fører til hovedpine med hensyn til andre programmer, der ikke forventer, at der skal være noget i /opt/local, ting installeres med rodtilladelser osv. & der er nogle ting, der generelt ikke er bedst installeret med MacPorts (f.eks du kan installere skinner via MacPorts, men du ville være vild med ikke at installere den via Rubys normale perlehåndtering). Bortset fra det, selvom jeg er en stor fan af MacPorts-filosofien om at opbygge sin egen lille verden & ikke stole på noget færdigpakket OS X-bibliotek – når det fungerer, og det gør det mest, alt er dødt simpelt. Hvilket er det, du virkelig vil have af en pakkehåndtering. Og som jeg nævnte, på dette tidspunkt er det ret forbandet hurtigt at indstille de fleste ting.

Håber, at noget af det var nyttigt.

Kommentarer

  • ” Som nævnt er den generelle konsensus, at MacPorts er blevet afløst af HB &, med rette eller forkert, der trækker flere mennesker mod det. ” … dette føles som en meget overfladisk erklæring …at være populær i forhold til at levere kvalitet er ikke det samme og antyder på ingen måde, at det andet er ” erstattet ” med det første.
  • MacPorts bruger nu Github. Se guide.macports.org/#project.github : ” MacPorts-projektet bruger Git distribueret versionskontrolsystem at administrere koden for hele projektet. Vores master-arkiver er hostet på GitHub. Vi vedligeholder offentlige arkiver til næsten al vores projektkode og dokumentation, inklusive et GitHub-arkiv til selve MacPorts-systemet, til MacPorts-porte og endda til den guide, du læser lige nu. ”

Svar

Noget, som andre svar (indtil videre) ikke synes at have nævnt, er at MacPorts har fremragende support til ældre versioner af macOS. Homebrew understøtter kun de operativsystemer, der i øjeblikket understøttes af Apple, hvilket normalt betyder de sidste tre udgivelser. Fra august 2020 er f.eks. Kun Catalina, Mojave og High Sierra kompatible med Homebrew.

Derimod kan MacPorts installeres på Tiger (!), Og projektet opretholder specielle programrettelser for at opbevare software arbejder hvor det er muligt. De opretholder også et ” Legacy Support ” bibliotek, der bakker symboler fra nye versioner af macOS til ældre; at linke mod dette bibliotek under kompilering kan få alle mulige nye software til at fungere pludselig på ældre systemer!

Så hvis du kører en gammel version af macOS, eller hvis du tror, du muligvis bliver nødt til at blive på en nuværende OS efter Apples udløbsdato, det er bestemt en grund til at gå med MacPorts.

Svar

Brygning var helt glat for mig at bruge, så jeg kan ikke fortælle om dens ulemper. Nogle ulemper ved MacPorts:

Der er flere meget populære spørgsmål om de to første punkter.

Kommentarer

  • Dette var min oplevelse installation af ImageMagick den 10.6; brygning var meget let, men gjorde det ikke ‘ t inkluderer JP2-delegaten. imagemagick.org/script/binary-releases.php
  • bryg og macports kræver bare Xcode kommandolinjeværktøjer, så det samme her.
  • @Mark I ‘ Jeg er ikke sikker på hvad du mener, men bryg fungerede perfekt for mig uden Xcode.
  • Du ‘ skal bruge en complier til brygning og MacPorts, som kan installeres via Xcode Command Line Tools. Du har ikke brug for Xcode -applikationen .
  • Jeg glemte, hvor grimt det er at synkronisere den ting, når du er bag en firewall … yikes!

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *