25 ms·

I currently use MacPorts... just wondering why I should switch?

by bshep 17y ago

tvon 17y ago
FWIW, I was an early Homebrew user and even contributed a few recipes, but I moved back to MacPorts because (and no offense to mxcl, but it's kind of unavoidable) the author seems to do things with little understanding of the underlying system or justification. Taking ownership of /user/local is completely utterly pointless and just plain bad advice. Copy-and-pasting optimization code from the Gentoo wiki is pointless. Binaries and libs are stripped without must justification, which will (did for me anyway) cause problems when compoing against the libs (eg, easy_install-ing anything against homebrew libs caused problems for me). There has also been a lot of FUD spread about at the expense of MacPorts which I think is just low class. The anti-Macports complaints basically amount to "I don't understand this, so I'm going to say it's bad". That said, it's written in ruby, uses github and the homepage is well done, so it will probably be wildly popular.
- rufo 17y ago
  I've had MacPorts completely explode in my face several times when installing a seemingly innocuous package - some shared library gets replaced due to a requirement, and suddenly every utility I've installed doesn't work. Eventually I got to a point where I only used MacPorts to install ImageMagick and compiled everything else by hand; so far homebrew has felt like a more disciplined version of "compile it yourself". I can't say I've had any problems with compiling Ruby gems against homebrew besides some settings that needed to be overridden in the MySQL gem, so that hasn't been a problem for me. I kind of have mixed feelings about the ownership. So far I've been running it in /usr/local owned by my user and haven't had any problems, but I can see the security argument for not doing it. It doesn't feel any different then compiling your own binaries and leaving them in your home directory, something I've had to do on several hosts I've had in the past. (Also: Snow Leopard doesn't install anything to /usr/local by default, so if you're starting from scratch there's nothing to take ownership of...) Overall, I've rather liked it so far. We'll see if I regret it...
  - jnoller 17y ago
    Thank you, the "a more disciplined version of "compile it yourself" line exactly sums up my feelings. If I really wanted a fleshed out, mature package management system, honestly - I'd install Ubuntu or Fedora.
- compay 17y ago
  I have everything installed in ~/Homebrew and have had no problems. I really wanted to keep liking Macports, but I got sick of having to install a new perl just to install git, among many examples. The kicker for me was installing pandoc; Macports wanted to download and compile a new GHC, refusing to recognize the one on my system. I let it run for 3 hours and finally killed the install and looked for a better way to do things.
  - shabble 17y ago
    Perl and GHC are the two packages I've had the most problems with as well. Some other languages seem to have a foo_select package which will allow you to switch the primary version, but 'perl5' seems fixed at 5.8.something, which is pretty horrible. There's a ticket with a lot of activity at http://trac.macports.org/ticket/16830 http://trac.macports.org/ticket/16830 but afaik there's still no easy way to stop it trying to rip out your new perl 5.10 without manually fixing deps everywhere. GHC I just installed from a binary package :-)
- asenchi 17y ago
  I think your understanding of your system is flawed. Taking ownership of /usr/local is a suggestion it isn't a requirement. It seems the anti-homebrew complaints basically amount to "I don't understand this, so I'm going to say it's bad". The biggest reason I've seen to get rid of Macports in favor of Homebrew is software versions, Homebrew is constantly up to date and I can upgrade software with ease. Not so with Macports.
- Locke1689 17y ago
  Just a side note but /usr does not actually stand for /user (although I often pronounce it that way when speaking). It's actually an initialism standing for UNIX System Resources.
  - tvon 17y ago
    Funny, I don't think I've ever written it that way before (/user/local), though I do say it that way. At the time of that writing I was highly caffeinated, which might have something to do with it.
  - doty 17y ago
    You sure that isn't just a backronym? It seems highly unlikely given its peers (/etc, /lib, /bin, none of which are acronyms) and given the system it lives in, which I don't think used the word "resources" anywhere else. When I google I mainly find drive-by assertions that it means "UNIX System Resources" (and sometimes "User Specific Resources"). The closest I can find to something real is: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html
  - miles 17y ago
    http://en.citizendium.org/wiki/Unix_directory_structure http://en.citizendium.org/wiki/Unix_directory_structure /usr -- originally the directory holding user home directories, its use has changed, and it now holds executables, libraries, and shared resources that are not system critical: X11, KDE, PERL, etc. (The name "Unix System Resources" is a post hoc backronym.)
- mxcl 17y ago
  /usr/local makes it far easier to install stuff like Gems with C extensions. It is a standard path checked by the C build system (eg. gcc). There no good reason I have yet heard why using /usr/local is bad advise. I assume that since you provided no rationale for your statement you are in fact unaware of one. But anyway having said this it is merely a recommendation — do whatever you want. The installation guide goes to great lengths to tell you that you should do whatever you want. Back when I initially made Homebrew I was interested in the greatest goal of maximum awesome O99 CFLAG awesomeness. Now I'm only interested in reliable compiles and the default CFLAGS are pretty sensible. At the time I wouldn't have recommended the project to anyone particularly, but it got popular anyway. But anyway, I never copy and pasted without reading a bunch first. I spent several days researching the stuff, the Gentoo wiki was a good source. There is no anti MacPorts stuff in any of the docs anymore. I was never anti MacPorts at all, if anyone will believe me. I just found it to be not a great tool for developers. Homebrew is a grass roots project, at the time it seemed harmless fun to poke fun at the competition. As the project became more popular I took it all out. Now there is just a small gibe that I couldn't resist because it's too good a bit of wit. Finally, no offence? May I suggest next time you say such a thing you don't immediately accuse the person to whom you mean no offence of being both ignorant and arrogant. PS with offence, you're an ignorant twat, and probably ugly too.
100k 17y ago
I haven't switched to Homebrew but the advantage is that MacPorts creates its own universe of libraries, whereas Homebrew uses what Mac OS X already comes with. This makes installs a lot faster.
- tvon 17y ago
  MacPorts creates it's own universe because that's the only reliable way to do it. What will Homebrew do when Python gets updated by Apple, or when you want 2.6.10 and Apple only has 2.6.4? With Macports the situation is easily dealt with, with Homebrew it's not.
  - jordibunster 17y ago
    Homebrew targets specific versions of OS X (currently 10.5/10.6). Within a released version of OS X, they don't tend to break backwards compatibility.
  - jnoller 17y ago
    "brew install python" works (and I've used it). In fact, I have a small pile of additional recipes locally for just doing custom, well-controlled compiles of Python.
  - chrisbolt 17y ago
    And yet the recommended solution for upgrading MacPorts with an OS X upgrade? Uninstall and reinstall all ports. What's the point of it creating its own universe if it needs to destroy it anyways?
FluidDjango 17y ago
If it worked for you: then you shouldn't. I had nothing but grief from trying to to get a basic (but up to date) LAMP running on any of several OS X (10.5 - 10.6). Life is too short.
oomkiller 17y ago
As a previous MacPorts user, I love homebrew. I keep macports around, because it has tons of ports that homebrew doesn't, but I dread using them because it is so much slower than homebrew. OS X ships with a lot of libs, and XCode installs even more. With macports, it redownloads and recompiles ALL of them, but with Homebrew it uses what you have. Also, the formulas are updated more often than macports, which I guess could be a good or bad thing.
troystribling 17y ago
I gave up MacPorts after several install failures, notably gtk after about a 1 hour compile, and switched to development in an Ubuntu VM. Have not had a problem since.
- jvdh 17y ago
  gtk failure is a problem with Snow Leopard, there's no stable gtk version that iscompatible with SL.
  - troystribling 17y ago
    I had build errors with 10.5.

I currently use MacPorts... just wondering why I should switch?

by bshep 17y ago

I currently use MacPorts... just wondering why I should switch?

tvon 17y ago

FWIW, I was an early Homebrew user and even contributed a few recipes, but I moved back to MacPorts because (and no offense to mxcl, but it's kind of unavoidable) the author seems to do things with little understanding of the underlying system or justification. Taking ownership of /user/local is completely utterly pointless and just plain bad advice. Copy-and-pasting optimization code from the Gentoo wiki is pointless. Binaries and libs are stripped without must justification, which will (did for me anyway) cause problems when compoing against the libs (eg, easy_install-ing anything against homebrew libs caused problems for me). There has also been a lot of FUD spread about at the expense of MacPorts which I think is just low class. The anti-Macports complaints basically amount to "I don't understand this, so I'm going to say it's bad". That said, it's written in ruby, uses github and the homepage is well done, so it will probably be wildly popular.

rufo 17y ago
I've had MacPorts completely explode in my face several times when installing a seemingly innocuous package - some shared library gets replaced due to a requirement, and suddenly every utility I've installed doesn't work. Eventually I got to a point where I only used MacPorts to install ImageMagick and compiled everything else by hand; so far homebrew has felt like a more disciplined version of "compile it yourself". I can't say I've had any problems with compiling Ruby gems against homebrew besides some settings that needed to be overridden in the MySQL gem, so that hasn't been a problem for me. I kind of have mixed feelings about the ownership. So far I've been running it in /usr/local owned by my user and haven't had any problems, but I can see the security argument for not doing it. It doesn't feel any different then compiling your own binaries and leaving them in your home directory, something I've had to do on several hosts I've had in the past. (Also: Snow Leopard doesn't install anything to /usr/local by default, so if you're starting from scratch there's nothing to take ownership of...) Overall, I've rather liked it so far. We'll see if I regret it...
- jnoller 17y ago
  Thank you, the "a more disciplined version of "compile it yourself" line exactly sums up my feelings. If I really wanted a fleshed out, mature package management system, honestly - I'd install Ubuntu or Fedora.
compay 17y ago
I have everything installed in ~/Homebrew and have had no problems. I really wanted to keep liking Macports, but I got sick of having to install a new perl just to install git, among many examples. The kicker for me was installing pandoc; Macports wanted to download and compile a new GHC, refusing to recognize the one on my system. I let it run for 3 hours and finally killed the install and looked for a better way to do things.
- shabble 17y ago
  Perl and GHC are the two packages I've had the most problems with as well. Some other languages seem to have a foo_select package which will allow you to switch the primary version, but 'perl5' seems fixed at 5.8.something, which is pretty horrible. There's a ticket with a lot of activity at http://trac.macports.org/ticket/16830 http://trac.macports.org/ticket/16830 but afaik there's still no easy way to stop it trying to rip out your new perl 5.10 without manually fixing deps everywhere. GHC I just installed from a binary package :-)
asenchi 17y ago
I think your understanding of your system is flawed. Taking ownership of /usr/local is a suggestion it isn't a requirement. It seems the anti-homebrew complaints basically amount to "I don't understand this, so I'm going to say it's bad". The biggest reason I've seen to get rid of Macports in favor of Homebrew is software versions, Homebrew is constantly up to date and I can upgrade software with ease. Not so with Macports.
Locke1689 17y ago
Just a side note but /usr does not actually stand for /user (although I often pronounce it that way when speaking). It's actually an initialism standing for UNIX System Resources.
- tvon 17y ago
  Funny, I don't think I've ever written it that way before (/user/local), though I do say it that way. At the time of that writing I was highly caffeinated, which might have something to do with it.
- doty 17y ago
  You sure that isn't just a backronym? It seems highly unlikely given its peers (/etc, /lib, /bin, none of which are acronyms) and given the system it lives in, which I don't think used the word "resources" anywhere else. When I google I mainly find drive-by assertions that it means "UNIX System Resources" (and sometimes "User Specific Resources"). The closest I can find to something real is: http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html
- miles 17y ago
  http://en.citizendium.org/wiki/Unix_directory_structure http://en.citizendium.org/wiki/Unix_directory_structure /usr -- originally the directory holding user home directories, its use has changed, and it now holds executables, libraries, and shared resources that are not system critical: X11, KDE, PERL, etc. (The name "Unix System Resources" is a post hoc backronym.)
mxcl 17y ago
/usr/local makes it far easier to install stuff like Gems with C extensions. It is a standard path checked by the C build system (eg. gcc). There no good reason I have yet heard why using /usr/local is bad advise. I assume that since you provided no rationale for your statement you are in fact unaware of one. But anyway having said this it is merely a recommendation — do whatever you want. The installation guide goes to great lengths to tell you that you should do whatever you want. Back when I initially made Homebrew I was interested in the greatest goal of maximum awesome O99 CFLAG awesomeness. Now I'm only interested in reliable compiles and the default CFLAGS are pretty sensible. At the time I wouldn't have recommended the project to anyone particularly, but it got popular anyway. But anyway, I never copy and pasted without reading a bunch first. I spent several days researching the stuff, the Gentoo wiki was a good source. There is no anti MacPorts stuff in any of the docs anymore. I was never anti MacPorts at all, if anyone will believe me. I just found it to be not a great tool for developers. Homebrew is a grass roots project, at the time it seemed harmless fun to poke fun at the competition. As the project became more popular I took it all out. Now there is just a small gibe that I couldn't resist because it's too good a bit of wit. Finally, no offence? May I suggest next time you say such a thing you don't immediately accuse the person to whom you mean no offence of being both ignorant and arrogant. PS with offence, you're an ignorant twat, and probably ugly too.

100k 17y ago

I haven't switched to Homebrew but the advantage is that MacPorts creates its own universe of libraries, whereas Homebrew uses what Mac OS X already comes with. This makes installs a lot faster.

tvon 17y ago
MacPorts creates it's own universe because that's the only reliable way to do it. What will Homebrew do when Python gets updated by Apple, or when you want 2.6.10 and Apple only has 2.6.4? With Macports the situation is easily dealt with, with Homebrew it's not.
- jordibunster 17y ago
  Homebrew targets specific versions of OS X (currently 10.5/10.6). Within a released version of OS X, they don't tend to break backwards compatibility.
- jnoller 17y ago
  "brew install python" works (and I've used it). In fact, I have a small pile of additional recipes locally for just doing custom, well-controlled compiles of Python.
- chrisbolt 17y ago
  And yet the recommended solution for upgrading MacPorts with an OS X upgrade? Uninstall and reinstall all ports. What's the point of it creating its own universe if it needs to destroy it anyways?

FluidDjango 17y ago

If it worked for you: then you shouldn't. I had nothing but grief from trying to to get a basic (but up to date) LAMP running on any of several OS X (10.5 - 10.6). Life is too short.

oomkiller 17y ago

As a previous MacPorts user, I love homebrew. I keep macports around, because it has tons of ports that homebrew doesn't, but I dread using them because it is so much slower than homebrew. OS X ships with a lot of libs, and XCode installs even more. With macports, it redownloads and recompiles ALL of them, but with Homebrew it uses what you have. Also, the formulas are updated more often than macports, which I guess could be a good or bad thing.

troystribling 17y ago

I gave up MacPorts after several install failures, notably gtk after about a 1 hour compile, and switched to development in an Ubuntu VM. Have not had a problem since.

jvdh 17y ago
gtk failure is a problem with Snow Leopard, there's no stable gtk version that iscompatible with SL.
- troystribling 17y ago
  I had build errors with 10.5.