Quels sont les avantages et les inconvénients de MacPorts, Fink et Homebrew?


154

Je suis en train de migrer d'Ubuntu Linux vers Mac, et tout est nouveau et je réapprends beaucoup de choses.

Sous Linux, j'avais l'excellent apt-get pour gérer les packages logiciels. J'ai cherché sur Google une alternative sur Google et découvert MacPorts, Fink et Homebrew.

J'utiliserai principalement cet ordinateur pour développer des applications Ruby on Rails.

Alors, quelles sont les différences entre eux? Quels sont les avantages et les inconvénients? Lequel est le mieux maintenu et a plus de paquets?


5
J'ai édité votre titre pour le faire correspondre à votre vraie question. Sur la plupart des sites Stack Exchange, les questions demandant «le meilleur» sont mal vues.
Loïc Wolff

1
Pourquoi avez-vous besoin de ces pierres précieuses qui ne suffiront-elles pas?
user151019

Pour en savoir plus sur pourquoi les doublons ne sont pas toujours mauvais: apple.stackexchange.com/questions/11461/... aussi il y a quelques alternatives plus là
cregox

Jamais utilisé moi-même, mais peut-être une comparaison à pkgin serait également utile.
Dennis

Réponses:


118

Certainement Homebrew. J'ai commencé avec Fink, puis je suis passé à MacPorts (plus heureux), puis à Homebrew (beaucoup, beaucoup plus heureux). Voici mes raisons pour utiliser chacune (une liste pro si vous voulez):

Mouchard

  • Basé sur Apt - sentez-vous comme à la maison si vous venez d'un environnement basé sur Debian
  • Paquets binaires - les paquets sont disponibles en tant que fichiers binaires, donc pas de temps de compilation long. En pratique, j’ai constaté que les fichiers binaires pré-compilés étaient toujours obsolètes et que je devais quand même compiler des éléments pour mon système.
  • Bonne sélection de forfaits

MacPorts

  • Le plus grand choix de paquets / ports
  • Généralement très à jour
  • Système de variantes agréable qui vous permet de personnaliser la construction
  • Fichiers de port faciles et intuitifs

Homebrew

  • Très à jour
  • Utilisation optimale de ce qui vient avec OS X. Contrairement à Fink ou MacPorts, il n’est pas nécessaire de créer / installer ruby ​​et des bibliothèques à partir de rien pour installer un petit outil basé sur Ruby.
  • Installe dans /usr/localdonc n'a pas besoin de vous modifier PATHn'importe où
  • Tout ce qui appartient à l'utilisateur, aucun paquet n'a donc besoin d'un accès root potentiellement risqué pour l'installation
  • Chaque paquet installé est proprement mis en sandbox dans sa propre cave afin que vous n'ayez pas de fichiers parasites sur votre système, juste des liens symboliques de bin, man, etc.
  • Ridiculement facile de créer vos propres fichiers de formules (c.-à-d. Des descripteurs de paquet)
  • Puisque vous êtes issu d’un fond ruby, tout ce qui est écrit en ruby ​​est un autre avantage: toutes les formules sont de simples scripts ruby.

pkgin

  • Très à jour
  • Installation plus rapide en raison des fichiers binaires précompilés
  • Tout ce qui est installé dans / opt / pkg /
  • soutenu par la communauté pkgsrc et Joyent
  • Connu pour fonctionner sur NetBSD, BSD DragonFly, Solaris, Debian, Mac OS X, Minix

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

http://pkgin.net/


33
Notez que pour les producteurs locaux, vous pouvez affirmer que "s’installe dans / usr / local" et que "tirer parti de ce qui est fourni avec OS X" sont des problèmes - ce sont les deux principales raisons pour lesquelles j’utilise un autre système d’emballage
utilisateur151019 le

5
Etant donné que / usr / local / bin ne figure pas dans le chemin par défaut de Mac OS X, vous devez certainement modifier votre PATH. bacs qu'il installe (sauf le "fût seulement", mais c'est du bruit ici).
Terry N

5
@ jedd.ahyoung Je préfère les macports qui met dans / opt / local (fink met dans / sw)
user151019 le

5
Malheureusement, l'homebrew semble de plus en plus rejeter certains cas d'utilisation et API, de sorte que les responsables expriment un mépris flagrant pour les utilisateurs. Macports semble être une meilleure alternative puisque cette tendance semble envahir l'homebrew de manière troublante. À une certaine époque, Homebrew visait essentiellement à aider l'utilisateur, mais il s'est lentement éloigné de celui-ci.
GDP2

5
Je suis d'accord avec @ GDP2. Je suis un nouvel utilisateur Mac de Linux. Les développeurs en brassage ont une très mauvaise attitude. Pouvez-vous croire qu'il n'y a que 13 problèmes dans le github de Brew lorsque je poste ce commentaire? Ils ne veulent pas écouter les utilisateurs. Ils ne veulent pas de problèmes. Ils ignorent simplement les problèmes que vous avez ouverts et les ferment immédiatement. Je ne vois jamais une telle attitude dans aucun des projets de github. En tant que nouvel utilisateur, j'utilise brasser depuis plusieurs mois et aujourd'hui, je pense passer à un autre et j'ai trouvé cette question. L'expérience d'utilisation de la bière est la pire que j'ai
jamais vécue

57

MacPorts

C’est plus indépendant de Mac OS X, cela signifie que MacPorts ignorera simplement de nombreuses bibliothèques système et logiciels déjà disponibles dans Mac OS X et en tirera le sien , ce qui risque d’être plus lent lorsque l’utilitaire que vous installez requiert un ensemble de fichiers volumineux. bibliothèques et logiciels.

Mais ce type de choix est plus sûr car les packages que vous avez installés sont moins influencés par la procédure de mise à jour / mise à niveau du système d’Apple.


Homebrew

Il dépend davantage des packages installés existants de Mac OS X, ce qui accélérera l'installation et minimisera les bibliothèques redondantes.

Mais le risque est que les paquets installés risquent d'être endommagés à cause de la mise à jour / mise à niveau du système Apple.

Donc, ce sont les deux types de compromis différents.

En outre, Homebrew prend par défaut / usr / local , ce que certaines personnes n’aiment pas, car il entre en conflit avec la tradition unix et peut poser problème si vous y avez déjà installé quelque chose (MySQL, etc.)


Outre ces différences, compte tenu des packages que ces deux logiciels peuvent offrir, vous pouvez vérifier à l'aide de ces deux commandes si MacPorts / Homebrew est déjà installé et affiche les packages actuellement fournis:

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

Et vous découvrirez que MacPorts propose beaucoup plus de packages que Homebrew.

(19399 vs 3583 le 13 mai 2016)


17
Remarque concernant le nombre différent de paquets: Homebrew n'inclut pas les paquets pour les langages de programmation qui ont leur propre système de paquetage (rubygems / pip / cpan…) ou pour les logiciels pour lesquels un installateur OS X plus approprié est disponible (MacTeX). . En outre, les doublons et les anciennes versions ne figurent pas dans le référentiel par défaut, mais incluent dans des référentiels tactiles alternatifs . Comparez cela à macports, qui contient par exemple un port IPython pour toutes les versions Python incluses. C'est une sorte de philosophie différente qui augmente naturellement le nombre de paquets dans macports.
Debilski


@YaOz, vous pourriez sûrement changer d'homebrew pour utiliser autre chose que /usr/local?
Pacerier

41

Juste pour ajouter certaines de mes propres pensées qui semblent vraies vers la fin de 2014 au moins.

Homebrew, il y a quelques années, a définitivement l'avantage sur l'esprit partagé. Vous trouverez beaucoup de blogs avec des gens qui racontent à quel point ils sont plus heureux avec Homebrew - généralement à cause de l'ensemble "MacPorts tire dans le monde entier" vs "Homebrew utilise ce que vous avez déjà".

Cependant, IMO, MacPorts est une bête différente aujourd'hui de ce qu'elle était il y a quelques années. Lorsque je suis passé pour la première fois à OS X et que j'utilisais MacPorts, la philosophie de MP était en effet frustrante, car presque tout a été construit à partir des sources. Une nouvelle installation était particulièrement douloureuse / lente. Cependant, au cours de la dernière année environ, d'après mes propres impressions, il semble que 90% des packages MP soient des fichiers binaires, de sorte que l'installation est réellement très rapide maintenant. D'après ce que je comprends, Homebrew se dirige également dans cette direction avec "Bottles", mais j'ai l'impression que la plupart des choses que vous installez via HB à ce moment-là seront compilées à partir des sources.

Donc, ne serait-ce que pour offrir un avis contradictoire, MacPorts semble être l'option "plus rapide" de nos jours. Cependant, les opinions de MP sur la plupart des gens semblent être basées sur des expériences de 2011-12 environ et ne tiennent pas vraiment compte de cela. Prenez ceci avec un grain de sel, bien que je ne sois pas un utilisateur régulier de HB (et que ce soit plutôt douloureux d’utiliser les deux côte à côte).

Je pense que HB a des avantages qui signifient qu'il sera probablement "gagner la guerre" à long terme si

  • HB est entièrement composé de Ruby, alors que MacPorts et ses formules de package sont écrits en TCL, ce qui… n'est pas exactement un langage de script populaire. Cela dit, c’est très simple de créer votre propre fichier de port.
  • HB est basé sur GitHub et semble donc beaucoup plus accueillant pour les nouveaux contributeurs, alors que MacPorts héberge son propre référentiel SVN quelque part, ce qui correspond essentiellement aux différents âges des deux projets, je suppose.
  • Comme mentionné, le consensus général est que HB a supplanté MacPorts, à tort ou à raison, ce qui attire plus de gens vers elle.

Sinon YaOZl & kLy a très bien couvert la différence principale en termes de sudo, de dépendances, etc. Personnellement, j’ai trouvé que MacPorts donnait parfois lieu à des maux de tête: d’autres programmes ne s’attendaient pas à quoi que ce soit /opt/local, des choses étant installées avec les droits root, etc. & il y a des choses qu’il vaut mieux ne pas installer avec MacPorts MacPorts mais vous seriez fou de ne pas l’installer via la gestion normale de Ruby Gem). En dehors de cela, même si je suis un grand fan de la philosophie de MacPorts qui consiste à créer son propre monde et à ne pas compter sur une bibliothèque pré-emballée pour OS X - quand cela fonctionne et que ça fonctionne, tout est extrêmement simple. C'est ce que vous voulez vraiment d'un gestionnaire de paquets. Et comme je l’ai mentionné plus tôt, il est assez rapide pour organiser la plupart des choses.

J'espère que cela a été utile.


"Comme mentionné, le consensus général est que HB a supplanté MacPorts et, à tort ou à raison, cela attire plus de gens vers elle." ... cela ressemble à une déclaration très superficielle ... être populaire par rapport à la qualité n'est pas la même chose et n'implique nullement que la seconde soit "remplacée" par la première.
Dmitri Zaitsev le

3

Brew était complètement lisse pour moi, donc je suis incapable de parler de ses inconvénients. Quelques inconvénients de MacPorts:

Il y a plusieurs questions très populaires sur les deux premiers points.


Ce fut mon expérience d'installation d'ImageMagick sur 10.6; le brassage était très facile, mais n'incluait pas le délégué de JP2. imagemagick.org/script/binary-releases.php
Nemo

2
brassage et macports nécessitent juste des outils de ligne de commande Xcode donc la même chose ici.
user151019

@ Mark Je ne suis pas sûr de ce que vous voulez dire, mais brasser a parfaitement fonctionné pour moi sans Xcode.
Nemo

2
Vous aurez besoin d'un complément pour Brew et MacPorts, qui peut être installé via les outils de ligne de commande Xcode. Vous n'aurez pas besoin de l' application Xcode .
nohillside

1
J'ai oublié à quel point il est moche de synchroniser cette chose derrière un pare-feu ... beurk!
rogerdpack
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.