Quais são os prós e os contras do MacPorts, Fink e Homebrew?


154

Estou apenas migrando do Ubuntu Linux para Mac, e tudo é novo e estou aprendendo muitas coisas.

No Linux, eu tinha o excelente apt-get para gerenciar pacotes de software. Pesquisei no Google uma alternativa no Mac e descobri o MacPorts, Fink e Homebrew.

Eu usarei este computador principalmente para desenvolver aplicativos Ruby on Rails.

Então, quais são as diferenças entre eles? Quais são as vantagens e desvantagens? Qual é a melhor manutenção e tem mais pacotes?


5
Editei o seu título para que ele corresponda à sua verdadeira pergunta. Na maioria dos sites do Stack Exchange, as perguntas sobre "o melhor" são desaprovadas.
Loïc Wolff

1
Por que você precisa de alguma dessas jóias de rubi, não é suficiente?
precisa saber é o seguinte

Para saber mais sobre por que duplicatas não são sempre ruins: apple.stackexchange.com/questions/11461/... também existem mais algumas alternativas lá
cregox

Eu nunca o usei, mas talvez uma comparação com o pkgin também seja útil.
Dennis

Respostas:


118

Definitivamente Homebrew. Comecei com o Fink, depois mudei para o MacPorts (mais feliz) e depois para o Homebrew (muito, muito mais feliz). Estas são minhas razões para usar cada uma (uma lista profissional, se você desejar):

Fink

  • Baseado no Apt - sinta-se em casa se você vier de um ambiente baseado no Debian
  • Pacotes binários - os pacotes estão disponíveis como binários, portanto, não há longos tempos de compilação. Praticamente, embora eu tenha achado que os binários pré-compilados estavam sempre desatualizados e eu tive que compilar coisas para o meu sistema de qualquer maneira
  • Seleção decente de pacotes

MacPorts

  • Maior seleção de pacotes / portas
  • Geralmente muito atualizado
  • Bom sistema de variantes que permite personalizar a compilação
  • Arquivos de porta fáceis e intuitivos

Homebrew

  • Muito atualizado
  • Aproveitamento máximo do que vem com o OS X. Ao contrário do Fink ou MacPorts, ele não exige que você construa / instale ruby ​​e bibliotecas do zero apenas para instalar alguma pequena ferramenta baseada em Ruby.
  • Instala para /usr/localque não seja necessário modificar em PATHnenhum lugar
  • Tudo pertence ao usuário, portanto, nenhum pacote precisa de acesso root potencialmente arriscado para instalar
  • Cada pacote instalado é limpo em sandbox em sua própria adega para que você não tenha arquivos perdidos em todo o sistema, apenas links simbólicos de bin, man, etc.
  • É ridiculamente fácil criar seus próprios arquivos de fórmula (por exemplo, descritores de pacotes)
  • Como você é de fundo ruby, outra vantagem é que tudo está escrito em ruby ​​e todas as fórmulas são simples scripts ruby

pkgin

  • Muito atualizado
  • Instalações mais rápidas devido aos binários pré-compilados
  • Tudo instalado em / opt / pkg /
  • apoiado pela comunidade pkgsrc e Joyent
  • Conhecido por funcionar no NetBSD, no DragonFly BSD, no Solaris, no Debian, no Mac OS X, no Minix

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

http://pkgin.net/


33
Note que para casa cerveja você pode argumentar que "Instala em usr / local /" e "alavancagem do que vem com o OS X" são problemas - eles são as duas principais razões pelas quais eu usar outro sistema de embalagem
user151019

5
Dado que / usr / local / bin não está no caminho padrão do Mac OS X, você certamente precisa modificar seu PATH - você só precisa fazê-lo uma vez, pois o brew coloca nesse local links para todos os novos caixas que instala (exceto os "barris apenas", mas isso é barulho aqui).
Terry N

5
@ jedd.ahyoung Eu prefiro macports, que coloca / opt / local (fink coloca / sw)
user151019

5
Infelizmente, o homebrew parece cada vez mais rejeitar certos casos de uso e APIs, de modo que os mantenedores expressam um flagrante desrespeito pelos usuários. O Macports está parecendo uma alternativa melhor, já que essa tendência parece estar impregnando o homebrew de uma maneira inquietante. O Homebrew, ao mesmo tempo, tinha tudo a ver com ajudar o usuário, mas se afastou lentamente disso.
GDP2 17/04/19

5
Eu tenho que concordar com @ GDP2. Eu sou um novo usuário de Mac do Linux. Os desenvolvedores de cerveja têm uma atitude muito ruim. Você acredita que há apenas 13 questões no github do brew quando estou postando este comentário? Eles não querem ouvir usuários. Eles não querem nenhum problema. Eles simplesmente ignoram os problemas que você abriu e os fecharam imediatamente. Eu nunca vejo essa atitude em nenhum dos projetos do github. Como novo usuário, utilizo o brew há alguns meses e hoje estou pensando em mudar para outro e encontrei esta pergunta. A experiência usando bebida é a pior que eu tive na minha vida até agora
sgon00

57

MacPorts

É mais independente do Mac OS X, o que significa que o MacPorts irá simplesmente ignorar muitas das bibliotecas e softwares de sistema já disponíveis no Mac OS X e usar a sua própria , o que pode ser mais lento quando o utilitário que você instala exigir algum conjunto de configurações grandes. bibliotecas e softwares.

Mas esse tipo de escolha é mais seguro porque os pacotes que você instalou são menos influenciados pelo procedimento de atualização / atualização do sistema da Apple.


Homebrew

É mais dependente dos pacotes instalados do Mac OS X existentes, portanto, isso acelerará a instalação dos pacotes e minimizará as bibliotecas redundantes.

Mas o risco é que os pacotes instalados possam ser quebrados devido à atualização / atualização do sistema da Apple.

Portanto, esses são os dois tipos diferentes de troca.

Além disso, o Homebrew assume o comando / usr / local por padrão, com o qual algumas pessoas não gostam disso, porque de alguma forma entram em conflito com a tradição unix e podem causar problemas se você já instalou alguma coisa lá (MySQL, etc.)


Além dessas diferenças, considerando os pacotes que esses dois podem oferecer, você pode verificar com esses dois comandos se você já possui o MacPorts / Homebrew instalado, que mostra os pacotes que eles forneceram atualmente:

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

E você descobrirá que o MacPorts tem muito mais pacotes que o Homebrew.

(19399 vs 3583 em 13 de maio de 2016)


17
Como uma observação sobre o número diferente de pacotes: Homebrew decididamente não inclui pacotes para linguagens de programação que possuem seu próprio sistema de empacotamento (rubygems / pip / cpan…) ou para software para o qual um instalador OS X sem dúvida mais apropriado está disponível (MacTeX) . Além disso, duplicatas e versões mais antigas não estão no repositório padrão, mas incluem em repositórios de toque alternativos . Compare isso com os macports, que, por exemplo, contêm uma porta IPython para todas as versões incluídas do Python. É um tipo de filosofia diferente que naturalmente aumenta o número de pacotes nos macports.
Debilski


@YaOz, certamente você pode mudar o homebrew para usar outra coisa que não seja /usr/local?
Pacerier

41

Apenas para adicionar alguns dos meus pensamentos que parecem verdadeiros por volta do final de 2014, pelo menos.

A Homebrew, há alguns anos, definitivamente tem a vantagem em termos de compartilhamento de ideias. Você encontrará muitos blogs com pessoas falando sobre o quanto eles são mais felizes com o Homebrew - geralmente por causa de toda a "MacPorts puxa no mundo inteiro" vs "o Homebrew usa o que você já tem".

No entanto, na IMO, o MacPorts é um animal diferente agora do que era há alguns anos atrás. Quando eu mudei para o OS X e estava usando o MacPorts, a filosofia MP foi realmente frustrante, porque quase tudo foi construído a partir da fonte. Uma nova instalação foi particularmente dolorosa / lenta. No entanto, ao longo do ano passado, com base apenas em minhas próprias impressões, parece que 90% dos pacotes MP são binários e, portanto, a instalação é realmente muito rápida agora. Pelo que entendi, o Homebrew também está se movendo nessa direção com "Bottles", mas tenho a impressão de que a maioria das coisas que você instala via HB neste momento será compilada a partir da fonte.

Portanto, apenas para oferecer uma opinião compensatória, o MacPorts parece ser a opção "mais rápida" atualmente. No entanto, a opinião da maioria das pessoas sobre o MP parece basear-se em experiências de cerca de 2011-12 ou mais, e realmente não leva isso em consideração. Leve isso com um pouco de sal, já que eu não sou um usuário comum de HB (e é bastante doloroso usar os dois lado a lado).

Eu acho que a HB tem vantagens que significam que provavelmente "vencerá a guerra" a longo prazo.

  • O HB é todo Ruby, enquanto o MacPorts e suas fórmulas de pacotes são escritos em TCL, o que é .... não é exatamente uma linguagem de script popular. Dito isto, é muito simples criar seu próprio portfile.
  • O HB é baseado no GitHub e, portanto, parece muito mais acolhedor para os novos colaboradores, enquanto o MacPorts hospeda seu próprio repositório SVN em algum lugar que eu acho - o que reflete basicamente as diferentes idades dos dois projetos.
  • Como mencionado, o consenso geral é que o MacPorts foi substituído pela HB &, com ou sem razão, que atrai mais pessoas para isso.

Caso contrário, o YaOZl e o kLy cobriram muito bem a principal diferença em termos de sudo, dependências etc. Pessoalmente, acho que o MacPorts às vezes leva a dores de cabeça em termos de outros programas que não esperam nada /opt/local, coisas sendo instaladas com permissões de root etc. & há algumas coisas que geralmente não são instaladas com o MacPorts (por exemplo, você pode instalar o Rails via MacPorts, mas você ficaria louco por não instalá-lo pelo gerenciamento normal de Gem do Ruby). Fora isso, apesar de eu ser um grande fã da filosofia MacPorts de construir seu próprio mundinho e não depender de uma biblioteca OS X pré-empacotada - quando funciona, e geralmente funciona, tudo é simples. Qual é o que você realmente deseja de um gerenciador de pacotes. E como eu mencionei, neste momento é bastante rápido configurar a maioria das coisas.

Espero que um pouco disso tenha sido útil.


"Como mencionado, o consenso geral é que o MacPorts foi substituído pela HB &, com ou sem razão, que atrai mais pessoas para isso". ... isso parece uma afirmação muito superficial ... ser popular versus fornecer qualidade não é o mesmo e de modo algum implica que o segundo seja "substituído" pelo primeiro.
Dmitri Zaitsev

3

A fermentação foi completamente suave para eu usar, por isso não sou capaz de dizer sobre seus contras. Algumas desvantagens do MacPorts:

Existem várias perguntas muito populares sobre os dois primeiros pontos.


Esta foi a minha experiência na instalação do ImageMagick no 10.6; preparar era muito fácil, mas não incluía o delegado JP2. imagemagick.org/script/binary-releases.php
Nemo

2
o brew e o macports exigem apenas as ferramentas de linha de comando do Xcode, portanto, o mesmo aqui.
user151019

@ Mark Não tenho certeza do que você quer dizer, mas o brew funcionou perfeitamente para mim sem o Xcode.
Nemo

2
Você precisará de um complier para o brew e o MacPorts, que podem ser instalados através das Ferramentas de Linha de Comando do Xcode. Você não precisará do aplicativo Xcode .
Nohillside

1
Eu esqueci o quão feio é sincronizar essa coisa quando atrás de um firewall ... caramba!
Rogerdpack
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.