¿Cuáles son las ventajas y desventajas de MacPorts, Fink y Homebrew?

154

Solo estoy migrando de Ubuntu Linux a Mac, y todo es nuevo y estoy volviendo a aprender muchas cosas.

En Linux tuve el excelente apt-get para administrar paquetes de software. Busqué en Google una alternativa en Mac y descubrí MacPorts, Fink y Homebrew.

Usaré esta computadora principalmente para desarrollar aplicaciones de Ruby on Rails.

Entonces, ¿cuáles son las diferencias entre ellos? ¿Cuáles son las ventajas y desventajas? ¿Cuál se mantiene mejor y tiene más paquetes?

JoaoHornburg
fuente
55
Edité tu título para que coincida con tu pregunta real. En la mayoría de los sitios de Stack Exchange, las preguntas sobre "lo mejor" están mal vistas.
Loïc Wolff
1
¿Por qué necesitas alguno de estos, las gemas de rubí no serán suficientes?
user151019
para más información sobre por qué los duplicados no siempre son malos: apple.stackexchange.com/questions/11461/… también hay algunas alternativas más allí
cregox
Nunca lo usé yo mismo, pero tal vez una comparación con pkgin también sería útil.
Dennis

Respuestas:

118

Definitivamente Homebrew. Comencé con Fink, luego cambié a MacPorts (más feliz), luego a Homebrew (mucho, mucho más feliz). Estas son mis razones para usar cada una (una lista profesional si lo desea):

Soplón

  • Basado en apt: siéntase como en casa si viene de un entorno basado en Debian
  • Paquetes binarios: los paquetes están disponibles como archivos binarios, por lo que no hay tiempos de compilación largos. Prácticamente, aunque descubrí que los binarios precompilados siempre estaban desactualizados y de todos modos tuve que compilar cosas para mi sistema
  • Buena selección de paquetes

MacPorts

  • Mayor selección de paquetes / puertos
  • Generalmente muy actualizado
  • Bonito sistema de variantes que te permite personalizar la construcción
  • Archivos de puerto fáciles e intuitivos

Cerveza casera

  • Muy actualizado
  • Máximo aprovechamiento de lo que viene con OS X. A diferencia de Fink o MacPorts, no requiere que construyas / instales ruby ​​y bibliotecas desde cero solo para instalar alguna pequeña herramienta basada en Ruby.
  • Se instala en /usr/localmodo que no necesita modificarlo en PATHningún lugar
  • Todo lo que pertenece al usuario, por lo que ningún paquete necesita acceso raíz potencialmente riesgoso para instalar
  • Cada paquete instalado se guarda en su propia bodega para que no tenga archivos extraviados en todo su sistema, solo enlaces simbólicos de bin, man, etc.
  • Ridículamente fácil de crear sus propios archivos de fórmulas (es decir, descriptores de paquetes)
  • Como eres de un fondo ruby, otra ventaja es que todo está escrito en ruby ​​y todas las fórmulas son simples guiones ruby

pkgin

  • Muy actualizado
  • Instalaciones más rápidas debido a binarios precompilados
  • Todo instalado en / opt / pkg /
  • respaldado por la comunidad pkgsrc y Joyent
  • Se sabe que funciona en NetBSD, DragonFly BSD, Solaris, Debian, Mac OS X, Minix

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

http://pkgin.net/

kLy
fuente
33
Tenga en cuenta que para la preparación casera puede argumentar que "Las instalaciones en / usr / local" y "aprovechar lo que viene con OS X" son problemas: son las dos razones principales por las que uso otro sistema de empaquetado
usuario151019
55
Dado que / usr / local / bin no se encuentra en la ruta predeterminada de Mac OS X, seguramente debe modificar su RUTA, solo tiene que hacerlo una vez, ya que brew coloca en ese lugar enlaces a todos los nuevos bins que instala (excepto el "solo barril", pero eso es ruido aquí).
Terry N
55
@ jedd.ahyoung Prefiero macports que pone en / opt / local (fink pone en / sw)
user151019
55
Desafortunadamente, homebrew parece estar rechazando cada vez más ciertos casos de uso y API en la medida en que los mantenedores expresan un desprecio flagrante por los usuarios. Macports parece una mejor alternativa, ya que esta tendencia parece estar dominando el homebrew de una manera inquietante. Homebrew, en un momento, se trató de ayudar al usuario, pero lentamente se ha alejado de eso.
GDP2
55
Tengo que estar de acuerdo con @ GDP2. Soy un nuevo usuario de Mac de Linux. Los desarrolladores de cerveza tienen muy mala actitud. ¿Puedes creer que solo hay 13 problemas en brew's github cuando publico este comentario? No quieren escuchar a los usuarios. No quieren ningún problema. Simplemente ignoran los problemas que abrió y los cerró de inmediato. Nunca veo esa actitud en ninguno de los proyectos de Github. Como nuevo usuario, he usado brew durante algunos meses y hoy estoy pensando en cambiar a otro y encontré esta pregunta. La experiencia de usar cerveza es la peor que he tenido en mi vida hasta ahora
sgon00
57

MacPorts

Es más independiente de Mac OS X, esto significa que MacPorts simplemente ignorará muchas de las bibliotecas y softwares del sistema que ya están disponibles en Mac OS X y, en su lugar , extraerá el suyo , lo que podría ser más lento cuando la utilidad que instale requiera algún conjunto de bibliotecas y softwares.

Pero este tipo de elección es más segura porque los paquetes que instaló están menos influenciados por el procedimiento de actualización / actualización del sistema de Apple.


Cerveza casera

Depende más de los paquetes instalados de Mac OS X existentes, por lo que esto acelerará la instalación de paquetes y minimizará las bibliotecas redundantes.

Pero el riesgo es que los paquetes instalados puedan romperse debido a la actualización / actualización del sistema de Apple.

Entonces, estos son los dos tipos diferentes de compensación.

Además, Homebrew toma el control / usr / local de forma predeterminada, con lo que a algunas personas no les gusta esto porque de alguna manera entra en conflicto con la tradición de Unix y puede causar problemas si ya ha instalado algo allí (MySQL, etc.)


Además de estas diferencias, teniendo en cuenta los paquetes que estos dos pueden ofrecer, puede verificar con estos dos comandos si ya tiene MacPorts / Homebrew instalado, que le muestran los paquetes que proporcionan actualmente:

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

Y descubrirá que MacPorts tiene muchos más paquetes que Homebrew.

(19399 vs 3583 el 13 de mayo de 2016)

YaOzI
fuente
17
Como comentario sobre el número diferente de paquetes: Homebrew decididamente no incluye paquetes para lenguajes de programación que tengan su propio sistema de empaquetado (rubygems / pip / cpan ...) o para software para el cual esté disponible un instalador OS X posiblemente más apropiado (MacTeX) . Además, los duplicados y las versiones anteriores no están en el repositorio predeterminado, sino que incluye en alternativas de derivación repos. Compare esto con macports, que, por ejemplo, contiene un puerto IPython para todas las versiones de Python incluidas. Es una especie de filosofía diferente que naturalmente aumenta el número de paquetes en macports.
Debilski el
2
Excelente enlace! terrychay.com/article/macports-vs-homebrew.shtml ¡ Gracias!
Jeff Burdges
@YaOz, ¿seguramente podrías cambiar homebrew para usar otra cosa que no sea /usr/local?
Pacerier
41

Solo para agregar algunos de mis propios pensamientos que parecen verdaderos alrededor de finales de 2014 al menos.

Homebrew, desde hace un par de años, definitivamente tiene la ventaja en términos de compartir la mente. Encontrarás muchos blogs con personas que hablan de lo felices que están con Homebrew, generalmente debido a todo el "MacPorts tira en todo el mundo" frente a "Homebrew hace uso de lo que ya tienes".

Sin embargo, en mi opinión, MacPorts es una bestia diferente ahora que hace un par de años. Cuando me cambié por primera vez a OS X y estaba usando MacPorts, la filosofía MP era realmente frustrante porque casi todo estaba construido desde la fuente. Una nueva instalación fue particularmente dolorosa / lenta. Sin embargo, durante el año pasado más o menos, basado exclusivamente en mis propias impresiones, parece que el 90% de los paquetes MP son binarios, por lo que la instalación es realmente muy rápida ahora. Por lo que sé, Homebrew también se está moviendo en esta dirección con "Bottles", pero tengo la impresión de que la mayoría de las cosas que instalas a través de HB en este momento se compilarán desde la fuente.

Entonces, aunque solo sea para ofrecer una opinión compensatoria, MacPorts parece ser la opción "más rápida" en estos días. Sin embargo, la mayoría de las opiniones de los parlamentarios parecen estar basadas en experiencias de alrededor de 2011-12 más o menos y realmente no tienen esto en cuenta. Sin embargo, tome esto con un grano de sal, ya que no soy un usuario habitual de HB (y es bastante doloroso usar ambos lado a lado).

Sin embargo, creo que HB tiene ventajas que significan que probablemente "gane la guerra" a largo plazo

  • HB es todo Ruby, mientras que MacPorts, y sus fórmulas de paquete, están escritas en TCL que ... no es exactamente un lenguaje de script popular. Dicho esto, es bastante simple crear tu propio portfile.
  • HB se basa en GitHub y, por lo tanto, parece mucho más acogedor para los nuevos contribuyentes, mientras que MacPorts alberga su propio repositorio SVN en algún lugar, creo, que básicamente refleja las diferentes edades de ambos proyectos, supongo.
  • Como se mencionó, el consenso general es que MacPorts ha sido reemplazado por HB y, correcta o incorrectamente, eso atrae a más personas hacia él.

De lo contrario, YaOZl & kLy cubrieron la diferencia principal en términos de sudo, dependencias, etc. bastante bien. Personalmente, encuentro que MacPorts a veces provoca dolores de cabeza en términos de otros programas que no esperan que haya nada /opt/local, que se instalen con permisos de root, etc. y hay algunas cosas que generalmente no se instalan con MacPorts (por ejemplo, puede instalar Rails a través de MacPorts, pero sería una locura no instalarlo a través de la administración de Gem normal de Ruby). Aparte de eso, soy un gran admirador de la filosofía de MacPorts de construir su propio pequeño mundo y no depender de una biblioteca OS X preempaquetada: cuando funciona, y en su mayoría lo hace, todo es muy simple. Que es lo que realmente quieres de un administrador de paquetes. Y como mencioné, en este momento es bastante rápido configurar la mayoría de las cosas.

Espero que algo de eso haya sido útil.

Hal
fuente
"Como se mencionó, el consenso general es que MacPorts ha sido reemplazado por HB y, correcta o incorrectamente, eso atrae a más personas hacia él". ... esto se siente como una afirmación muy superficial ... ser popular vs proporcionar calidad no es lo mismo y de ninguna manera implica que el segundo sea "reemplazado" por el primero.
Dmitri Zaitsev
3

La preparación fue completamente suave para mí, así que no puedo decir sobre sus contras. Algunas desventajas de MacPorts:

Hay varias preguntas muy populares sobre los dos primeros puntos.

Nemo
fuente
Esta fue mi experiencia instalando ImageMagick en 10.6; la preparación fue muy fácil, pero no incluyó al delegado JP2. imagemagick.org/script/binary-releases.php
Nemo
2
brew y macports solo requieren herramientas de línea de comandos Xcode, así que lo mismo aquí.
user151019
@ Mark No estoy seguro de lo que quieres decir, pero brew funcionó perfectamente para mí sin Xcode.
Nemo
2
Necesitará un compilador para brew y MacPorts, que se puede instalar a través de Xcode Command Line Tools. No necesitará la aplicación Xcode .
nohillside
1
Olvidé lo feo que es sincronizar esa cosa cuando está detrás de un firewall ... ¡Ay!
rogerdpack