6 ms·

I do not wants to flame, but is there a reason people dislike Macports so much. I tried Homebrew when it was 1-2 years old, but stuck with ports bc it was so s

by 616c 12y ago

I do not wants to flame, but is there a reason people dislike Macports so much. I tried Homebrew when it was 1-2 years old, but stuck with ports bc it was so stable, compiles from source, and I never heard a serious problem. I heard the opposite complaint on the net, but almost all Macports hate was from many years before. I am the only one who chose not to rely on Homebrew!?

DigitalJack 12y ago
I haven't used macports in quite a while, but I switched because homebrew was more up to date. It might not be the case now though.
RexRollman 12y ago
I am absolutely no kind of programmer but I prefer to compile from source on my own, when I can. For example, the first thing I did yesterday after clean installing Yosemite Beta 4 was to compile Scrypt.
- dekz 12y ago
  Can I perhaps ask why? Is it a trust issue that you don't like accepting a prebuilt binary from some random on the internet?
  - RexRollman 12y ago
    I just enjoy the control.
    - 72deluxe 12y ago
      That''s quite witty! Do you also make all of your bread from the base ingredients too? :-)
      - RexRollman 12y ago
        For example, I like running the latest version of Vim (OS X is often behind). Compiling from the source, I can control what the binary is named (to avoid a name collision with the built in Vim), I can control the features (--with-features), and I can have it install to a directory of my choosing (~/Applications, where I also have scrypt install).I also install Lame and FLAC this way. As for bread, no, I am horrible at cooking!
        72deluxe 12y ago
        That's quite wise, particularly regarding the feature selection. Such joy from having the source! I suppose I never run into this problem because I don't use the software to its full extent and therefore don't miss any features! I must be lazy.
madvoid 12y ago
Nope, I'm a Macports guy as well, never had any serious problems with it. I wish it was possible to run both though because there are packages exclusive to either that I would like to run.
archagon 12y ago
My understanding is that Homebrew does not clobber any system defaults — works with the OS, not against it. I could be wrong, though.
- tvon 12y ago
  No, MacPorts is actually more sane in this regard because it build it's own set of dependencies instead of relying on anything the system provides. This makes it a more soundly designed tool, IMO. Homebrew also recommends using /usr/local as the root which I think is just plain bad advice, but it is simple enough to change it to something else.
  - 6cxs2hd6 12y ago
    Why is /usr/local bad advice?
    - teacup50 12y ago
      Because /usr/local doesn't belong to homebrew and is not appropriate for homebrew to commandeer. MacPorts was originally written by the BSD team at Apple; if /usr/local was where a packaging system was supposed to stuff itself on OS X, they would have used it -- instead of /opt/local. The co-opting of /use/local breaks all kinds of stuff -- for instance, /usr/local/lib is in the default linker search path and can't be removed, which means that trying to not link against homebrew libraries requires some pretty evil hacks -- such as library symbol interposing to hide /usr/local from stat(), etc.
      - antimagic 12y ago
        I disagree. / is where the stuff needed for single-user mode gets installed. /usr is where the OS's userland stuff gets installed. On Linux systems this includes everything that you get from your package manager, because this is considered to be part of your system. /usr/local is wher you install your own packages. For example, if I'm installing something from source, that's where I'm going to install it. Or if I'm building my own project, I would also install it there. On a Mac, there is no system-blessed pacakage manager - the official packages are pre-installed on your Mac and only change when you get an OS update. They tend to be installed in /Library or ~/Library. All of the add-on package managers therefore play a role much closer to that of hand-installed source. It's logical that they install to /ur/local. In particular, one of my main use case for package managers is when I want to try out a package that has a whole bunch of dependencies. I might want to compile the package that interests me by hand, as I need to tweak the config, but I don't want to have to do the configure-make-make install dance for the 30 packages that it has as dependencies. That's where homebrew / MacPorts comes into the picture, they save me that work. But they should be installed into the same hierachy as the package that does interest me, as they are at the same level of "officialness". One last thing. I know Fedora, Gentoo and MacOSX fairly well, and I have also worked a fair bit on a hand-rolled linux distribution. None of them ever had /usr/local/lib in their LD_LIBRARY_PATH by default, I've always had to configure that in my .bash_profile. This is exactly what you would expect, by default the directory should be empty, so why add it to the default LD_LIBRARY_PATH, that doesn't make any sense.
nknighthb 12y ago
I would think you can't find recent Macports complaints because nobody uses Macports. I didn't even realize it was still being updated at all. I stopped using it many years ago because it was frequently long out of date and broke in ways that I found impossible to fix without wiping everything and starting over. I switched to Fink, which broke occasionally but I was usually able to rescue it without too much hassle. Eventually I stopped using Fink maybe a year (or two?) ago in favor of homebrew, and have not had any serious problems since. brew's structure combined with 'brew doctor' and a vast and frequently-updated array of available packages seem to have done a pretty good job of avoiding the "can't get there from here" problems I had with fink and macports.
- rconti 12y ago
  Huh. I had no idea. I've been using MacPorts for what must be a decade, or close to it. Tried Fink a few times, never had any luck -- but never had a reason to find anything new (brew). I guess the Ports versions of everything I use are "good enough". If it ain't broke, and all that.
johncoltrane 12y ago
People don't really dislike Macports, they just like shiny new things on github.
- davidcelis 12y ago
  Homebrew isn't exactly new
  - johncoltrane 12y ago
    Homebrew was new 5 years ago when a whole new generation of Mac-using front end developers discovered the command-line (and git, and tmux…). MacPorts worked perfectly well but hey! how can an old tcl-based, svn-using package manager compete with a new ruby-based package manager that's on GitHub?
freiheit 12y ago
I prefer Homebrew over Macports, because the Homebrew default is to use the stuff your system already has. Macports always wants to pull in (newer versions) a bunch of stuff that's already in OSX. There's benefits to both approaches. However, I really only need a few extras on my OSX laptop, and I don't really want to end up compiling dozens of extra stuff just to get the latest version. Sometimes I want to force that new version, but only if there's specific functionality I'm after. Others really want to get the latest and greatest of everything constantly...
sbalea 12y ago
I use MacPorts. I tried Homebrew about a year ago, it worked fine, but I could not see the benefit. The current MacPorts is pretty up to date, at least for my needs. Pretty trouble free…
sanderjd 12y ago
I think homebrew is much easier to contribute to. I started using it when I wanted something that neither Macports nor homebrew had at the time, and it was very simple to add it to homebrew. It seems like things are generally more up to date and comprehensive in homebrew, and I think it's because of how easy it is to add things.
tjl 12y ago
I stopped using Macports for two reasons. First, it was taking a long time for some of the ports to get up to date. That doesn't seem to be a problem now, but it was. The second reason is that it insists on using its own versions of tools that OS X already has. I'd prefer not to install new versions if I don't have to. I understand their reasoning, but that's why I don't use Macports.
super_mario 12y ago
I don't use either. I build my stuff manually, and that way I also contribute upstream if there is a problem with some software not building on Mac OS X out of the box. Macports was perhaps necessary a while back, when most people didn't realize Mac OS X was just another BSD based UNIX. Now that the word is out, most software builds without a hitch. And honestly if you can't download a source tar archive and compile it yourself with your own customizations, then don't call yourself a hacker.
grizzkill 12y ago
I like Macports a lot more. I've never had an issue with any of the packages really besides a few esoteric ones that failed to build or hadn't been updated in a while (and they are usually easy to by updating the portfile). I prefer the segregated environment of macports too, you won't overwrite any system stuff. I got the impression that homebrew wasn't a terribly well thought out tool and was a bit lazy. There's a lot of 'github' culture there which I'm wary of (and by github culture I mean half finished stuff and fancy looking projects lacking rigor). Case in point, it annoys me that their slogan is 'the missing package manager for OSX'. Macports had been around long before they were. I only sometimes wish that Macports had better binary package support.

by 616c 12y ago

DigitalJack 12y ago

I haven't used macports in quite a while, but I switched because homebrew was more up to date. It might not be the case now though.

RexRollman 12y ago

I am absolutely no kind of programmer but I prefer to compile from source on my own, when I can. For example, the first thing I did yesterday after clean installing Yosemite Beta 4 was to compile Scrypt.

dekz 12y ago
Can I perhaps ask why? Is it a trust issue that you don't like accepting a prebuilt binary from some random on the internet?
- RexRollman 12y ago
  I just enjoy the control.
  - 72deluxe 12y ago
    That''s quite witty! Do you also make all of your bread from the base ingredients too? :-)
    - RexRollman 12y ago
      For example, I like running the latest version of Vim (OS X is often behind). Compiling from the source, I can control what the binary is named (to avoid a name collision with the built in Vim), I can control the features (--with-features), and I can have it install to a directory of my choosing (~/Applications, where I also have scrypt install).I also install Lame and FLAC this way. As for bread, no, I am horrible at cooking!
      - 72deluxe 12y ago
        That's quite wise, particularly regarding the feature selection. Such joy from having the source! I suppose I never run into this problem because I don't use the software to its full extent and therefore don't miss any features! I must be lazy.

madvoid 12y ago

Nope, I'm a Macports guy as well, never had any serious problems with it. I wish it was possible to run both though because there are packages exclusive to either that I would like to run.

archagon 12y ago

My understanding is that Homebrew does not clobber any system defaults — works with the OS, not against it. I could be wrong, though.

tvon 12y ago
No, MacPorts is actually more sane in this regard because it build it's own set of dependencies instead of relying on anything the system provides. This makes it a more soundly designed tool, IMO. Homebrew also recommends using /usr/local as the root which I think is just plain bad advice, but it is simple enough to change it to something else.
- 6cxs2hd6 12y ago
  Why is /usr/local bad advice?
  - teacup50 12y ago
    Because /usr/local doesn't belong to homebrew and is not appropriate for homebrew to commandeer. MacPorts was originally written by the BSD team at Apple; if /usr/local was where a packaging system was supposed to stuff itself on OS X, they would have used it -- instead of /opt/local. The co-opting of /use/local breaks all kinds of stuff -- for instance, /usr/local/lib is in the default linker search path and can't be removed, which means that trying to not link against homebrew libraries requires some pretty evil hacks -- such as library symbol interposing to hide /usr/local from stat(), etc.
    - antimagic 12y ago
      I disagree. / is where the stuff needed for single-user mode gets installed. /usr is where the OS's userland stuff gets installed. On Linux systems this includes everything that you get from your package manager, because this is considered to be part of your system. /usr/local is wher you install your own packages. For example, if I'm installing something from source, that's where I'm going to install it. Or if I'm building my own project, I would also install it there. On a Mac, there is no system-blessed pacakage manager - the official packages are pre-installed on your Mac and only change when you get an OS update. They tend to be installed in /Library or ~/Library. All of the add-on package managers therefore play a role much closer to that of hand-installed source. It's logical that they install to /ur/local. In particular, one of my main use case for package managers is when I want to try out a package that has a whole bunch of dependencies. I might want to compile the package that interests me by hand, as I need to tweak the config, but I don't want to have to do the configure-make-make install dance for the 30 packages that it has as dependencies. That's where homebrew / MacPorts comes into the picture, they save me that work. But they should be installed into the same hierachy as the package that does interest me, as they are at the same level of "officialness". One last thing. I know Fedora, Gentoo and MacOSX fairly well, and I have also worked a fair bit on a hand-rolled linux distribution. None of them ever had /usr/local/lib in their LD_LIBRARY_PATH by default, I've always had to configure that in my .bash_profile. This is exactly what you would expect, by default the directory should be empty, so why add it to the default LD_LIBRARY_PATH, that doesn't make any sense.

nknighthb 12y ago

I would think you can't find recent Macports complaints because nobody uses Macports. I didn't even realize it was still being updated at all. I stopped using it many years ago because it was frequently long out of date and broke in ways that I found impossible to fix without wiping everything and starting over. I switched to Fink, which broke occasionally but I was usually able to rescue it without too much hassle. Eventually I stopped using Fink maybe a year (or two?) ago in favor of homebrew, and have not had any serious problems since. brew's structure combined with 'brew doctor' and a vast and frequently-updated array of available packages seem to have done a pretty good job of avoiding the "can't get there from here" problems I had with fink and macports.

rconti 12y ago
Huh. I had no idea. I've been using MacPorts for what must be a decade, or close to it. Tried Fink a few times, never had any luck -- but never had a reason to find anything new (brew). I guess the Ports versions of everything I use are "good enough". If it ain't broke, and all that.

johncoltrane 12y ago

People don't really dislike Macports, they just like shiny new things on github.

davidcelis 12y ago
Homebrew isn't exactly new
- johncoltrane 12y ago
  Homebrew was new 5 years ago when a whole new generation of Mac-using front end developers discovered the command-line (and git, and tmux…). MacPorts worked perfectly well but hey! how can an old tcl-based, svn-using package manager compete with a new ruby-based package manager that's on GitHub?

freiheit 12y ago

I prefer Homebrew over Macports, because the Homebrew default is to use the stuff your system already has. Macports always wants to pull in (newer versions) a bunch of stuff that's already in OSX. There's benefits to both approaches. However, I really only need a few extras on my OSX laptop, and I don't really want to end up compiling dozens of extra stuff just to get the latest version. Sometimes I want to force that new version, but only if there's specific functionality I'm after. Others really want to get the latest and greatest of everything constantly...

sbalea 12y ago

I use MacPorts. I tried Homebrew about a year ago, it worked fine, but I could not see the benefit. The current MacPorts is pretty up to date, at least for my needs. Pretty trouble free…

sanderjd 12y ago

I think homebrew is much easier to contribute to. I started using it when I wanted something that neither Macports nor homebrew had at the time, and it was very simple to add it to homebrew. It seems like things are generally more up to date and comprehensive in homebrew, and I think it's because of how easy it is to add things.

tjl 12y ago

I stopped using Macports for two reasons. First, it was taking a long time for some of the ports to get up to date. That doesn't seem to be a problem now, but it was. The second reason is that it insists on using its own versions of tools that OS X already has. I'd prefer not to install new versions if I don't have to. I understand their reasoning, but that's why I don't use Macports.

super_mario 12y ago

I don't use either. I build my stuff manually, and that way I also contribute upstream if there is a problem with some software not building on Mac OS X out of the box. Macports was perhaps necessary a while back, when most people didn't realize Mac OS X was just another BSD based UNIX. Now that the word is out, most software builds without a hitch. And honestly if you can't download a source tar archive and compile it yourself with your own customizations, then don't call yourself a hacker.

grizzkill 12y ago

I like Macports a lot more. I've never had an issue with any of the packages really besides a few esoteric ones that failed to build or hadn't been updated in a while (and they are usually easy to by updating the portfile). I prefer the segregated environment of macports too, you won't overwrite any system stuff. I got the impression that homebrew wasn't a terribly well thought out tool and was a bit lazy. There's a lot of 'github' culture there which I'm wary of (and by github culture I mean half finished stuff and fancy looking projects lacking rigor). Case in point, it annoys me that their slogan is 'the missing package manager for OSX'. Macports had been around long before they were. I only sometimes wish that Macports had better binary package support.