¿Cuáles son los pros y los contras de MacPorts, Fink y Homebrew?

MacPorts

Es más independiente de Mac OS X, esto significa que MacPorts simplemente ignorará muchas de las bibliotecas del sistema y softwares que ya están disponibles en Mac OS X y tirar de la suya propia en su lugar que podría ser más lento cuando la utilidad que se instala requiere algún conjunto de grandes bibliotecas y softwares.

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

Homebrew

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

Pero el riesgo es que los paquetes instalados se rompan debido a la actualización del sistema de Apple.

Por lo tanto, estos son los dos tipos diferentes de compensación.

Además, Homebrew se hace cargo /usr/local por defecto, con lo que a algunos no les gusta esto porque de alguna manera entra en conflicto con la tradición unix y podría causar problemas si ya has instalado algo allí (MySQL, etc.)

Aparte de estas diferencias, teniendo en cuenta los paquetes que estos dos pueden ofrecer, puedes comprobar con estos dos comandos si ya tienes instalado MacPorts/Homebrew, que te muestran los paquetes que proporcionan actualmente:

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

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

(16917 v.s 2298 por ahora.)

Sólo para añadir algunos de mis propios pensamientos que parecen verdaderos alrededor de finales de 2014 por lo menos.

El homebrew, desde hace un par de años, tiene definitivamente la ventaja en términos de mindshare. Encontrarás muchos blogs en los que la gente habla de lo contentos que están con Homebrew, normalmente por el tema de "MacPorts atrae a todo el mundo" frente a "Homebrew hace uso de lo que ya tienes".

Sin embargo, IMO, MacPorts es una bestia diferente ahora de lo que era hace un par de años. Cuando me cambié a OS X por primera vez y usaba MacPorts, la filosofía de MP era realmente frustrante porque casi todo estaba construido desde el código fuente. Una nueva instalación era particularmente dolorosa/lenta. Sin embargo, desde hace un año, y basándome únicamente en mis propias impresiones, parece que el 90% de los paquetes de MP son binarios, por lo que la instalación es ahora realmente rápida. Por lo que deduzco, 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 se instalan a través de HB en este momento se compilan desde el código fuente.

Así que, aunque sólo sea para ofrecer una opinión contraria, MacPorts parece ser realmente la opción "más rápida" en estos días. Sin embargo, la mayoría de las opiniones de la gente sobre MP parecen estar basadas en experiencias de alrededor de 2011-12 o así y realmente no tienen esto en cuenta. Tómese esto con un grano de sal, sin embargo, ya que no soy un usuario regular de HB (y es bastante doloroso usar ambos lado a lado).

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

• HB es todo Ruby, mientras que MacPorts, y sus fórmulas de paquetes, están escritas en TCL, que no es precisamente un lenguaje de scripting popular. Dicho esto, es muy sencillo crear tu propio archivo de puertos.
• 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 ha mencionado, el consenso general es que MacPorts ha sido sustituido por HB y, con razón o sin ella, eso atrae a más gente hacia él.

Por lo demás, YaOZl y kLy cubrieron bastante bien la diferencia principal en términos de sudo, dependencias, etc. Personalmente encuentro que MacPorts a veces conduce a algunos dolores de cabeza en términos de otros programas que no esperan nada para estar en /opt/local Por ejemplo, hay cosas que es mejor no instalar con MacPorts (por ejemplo, puedes instalar Rails a través de MacPorts, pero sería una locura no instalarlo a través de la gestión normal de Ruby). Aparte de eso, soy un gran fan de la filosofía de MacPorts de construir su propio mundo y no depender de una biblioteca preempacada de OS X - cuando funciona, y casi siempre lo hace, todo es muy simple. Que es lo que quieres de un gestor de paquetes realmente. Y como he mencionado, en este momento es bastante rápido para configurar la mayoría de las cosas.

Espero que algo de esto haya sido útil.

Algo que otras respuestas (hasta ahora) no parecen haber mencionado es que MacPorts tiene un excelente soporte para las versiones heredadas de MacOS. Homebrew sólo es compatible con los sistemas operativos actualmente soportados por Apple, lo que normalmente significa las tres últimas versiones. Por ejemplo, a partir de agosto de 2020, sólo Catalina, Mojave y High Sierra son compatibles con Homebrew.

En cambio, MacPorts puede instalarse en Tiger (!), y el proyecto mantiene parches especiales para que el software siga funcionando siempre que sea posible. También mantienen una biblioteca "Legacy Support" que transporta los símbolos de las nuevas versiones de MacOS a las más antiguas; enlazar con esta biblioteca mientras se compila puede hacer que todo tipo de software nuevo funcione de repente en sistemas antiguos.

Por lo tanto, si estás ejecutando una versión antigua de MacOS, o si crees que puedes necesitar permanecer en un sistema operativo actual más allá de la fecha de caducidad de Apple, esa es definitivamente una razón para ir con MacPorts.

El uso de Brew fue completamente suave para mí, por lo que no puedo hablar de sus contras. Algunas desventajas de MacPorts:

• usted tiene que instalar Xcode desde el sitio de desarrolladores de Apple Por lo tanto, debes tener una cuenta de desarrollador de Apple (que ahora requiere una tarjeta de crédito) y descargar casi 3,5 GB de material;
• si el puerto 873 (rsync) está bloqueado por su firewall, tendrá que configurar manualmente el protocolo HTTPS ;
• el servidor HTTP(S) desde el que se descargan los paquetes es (a menudo) extremadamente lento (menos de 20 KiB/s ayer; probado desde un par de conexiones Gigabit muy fiables en diferentes países) y puede fallar con error Funcionamiento demasiado lento. Menos de 1024 bytes/seg transferidos los últimos 60 segundos obligando a rehacer todo desde cero.

Hay varias preguntas muy populares sobre los dos primeros puntos.