201–210 of 255 posts
Earlier quoted context omitted.
I've always installed to ~/.homebrew, and never encountered any problems.
Does this mean all your packages are built from source?
I'm excited about Homebrew potentially coming to Linux. When I first started using OS X more regularly, I was surprised by how better an experience OS X + Homebrew is compared to Ubuntu/Debian repositories + PPAs/third-party repositories.
Apt is the second worst linux package manager. RPM is the first worst.
Earlier quoted context omitted.
How so? The interface seems more or less identical to me. I'm not going to deny it's good and brings great stuff to the Mac, I'm just not seeing the advantages.
Other than "in every way possible"? The only thing that is as easy in apt as brew is installing packages. Searching, getting info about a package, updating the list of available packages, are all much easier with homebrew.
Ugh, ugh, ugh. I just tried Homebrew for the third time the other day and it made a complete mess of my /usr/local/bin and also screwed up my install of rvm ... never again will I give it a chance. Sorry, but IMO Homebrew is crufty, opinionated software with poor separation of concerns. Macports is the (objectively?) better choice for my needs.
> it made a complete mess of my /usr/local/bin In that case you might be glad to hear that in v1.0.0: > Homebrew’s default repository installation location changed to /usr/local/Homebrew to keep your /usr/local cleaner Personally, I really like Homebrew and have never had problems (c.f. MacPorts which gave me big problems a few years ago), but I don't use /usr/local for much else, so that's probably why.
However -- I just remember, when Homebrew was getting started, all the supercilious (dare I say arrogant?) advice in the docs ... oh, just install to /usr/local, "seriously", etc. (Looking for a reference in archive.org right now ...) Even their whole "Macports driving you to drink?" thing rubbed me the wrong way -- maybe I'm humour-deficient, but I think to criticize another project when your alternative isn't clearly better is just bad taste.
That being said, I am genuinely curious: is there any one awesome thing is that Homebrew does that Macports can't do? Or better, what kind of problems arise from using Macports? I recognize that packaging in Ruby is probably more convenient than in TCL, but other than that? It seems to me that Homebrew is just getting closer to what Macports did (correctly) in the first place. The only way Macports has ever inconvenienced me is requiring a fresh install from time to time when Apple updates their OS, which (for my use case) is minor.
Earlier quoted context omitted.
I use brew leaves instead of brew list for this sort of thing; as I usually don't care about the constituent transitive dependencies, only the final results.
I wasn't even aware of existence of that!
Throwback to that one time Google wouldn't hire @mxcl. ;) https://twitter.com/mxcl/status/608682016205344768 Well done Mike and contributors! It's a great piece of work.
He couldn't even ${college_level_gotcha}! No wonder he wasn't hired!
/usr/local was bad but /usr/local/Homebrew is worse. The best would have been /opt/brew (short, no uppercase letter)
Earlier quoted context omitted.
The dire status of MacPorts and Fink was the impetus behind Arch OS X back then, but Homebrew's success and ease of use combined with the build-from-source design (it was a real plus not having to host binary packages at the time) preempted that effort. Some design choices still rub me the wrong way to this day though (quibbles to some, but for a couple use cases it can matter), that's why I'm trying hard to bring ba…
MacPorts started as a build-from-source package manager. The introduction of prebuilt binary packages is a recent addition. It was added only because some packages took a really long time to build. Fink is full of old packages, but MacPorts ports are pretty up to date. There are still lots of devs maintaining MacPorts these days. So I don't know what dire status you were talking about.
At the time Homebrew rose in popularity it was super easy to add packages to and update existing packages. MacPorts had a reputation, at least, for being inflexible and difficult for casual maintainers. Some not-completely-esoteric packages would not be updated from upstream sources for years.
In my case there was (still is?) the particularly strange case of GNU Octave, in which the development version (octave-devel) had completely superceded the regular package (octave), and this was not really well documented. To get anything done at all with Octave you had to use octave-devel, while octave was essentially a vestigial limb floating around for no reason.
From the announcement: Use new Ruby Macho library for reading and writing library macOS Mach O file locations. Why does Homebrew need to parse Mach-O files? Is this for fixing up shared library paths inside executables?
Yes, exactly. During bottle installations, we need to be able to relocate dylib references and install names so that they're relative to the Homebrew prefix.
Earlier quoted context omitted.
Yeah I'm curious why he left. From what I could tell it sounded like changes in Swift took an act of congress basically. Which is fine, and how it should be, given how important it is to get it right. I wonder where he went.
My understanding is he just doesn't really know how to work in a big company.