Hacker News Reader

Comment by NelsonMinar | Hacker News Reader

To be fair to Homebrew (the example I'm picking on here), it does install to a nice sandboxed area. That area is named "/usr/local", but you can give it its own path and everything works pretty well. (I find I have to completely remove and reinstall Homebrew about every two months, generally because libgettext changed yet again.)

View on HN

Homebrew is ok, and it has arguably improved the situation on Mac OS X a great deal, but I think we can do better still.

Using homebrew, one tweaks recipes in ruby code until they work.

Why do we not have a common (and widely adopted!) way for software projects to tell other software how to install/uninstall them, and what other projects they depend on for what particular operations (e.g. configure, build, install, test etc), with reusable data rather than code.

Why is (some of) this information captured in bits of ruby, useful for a particular OS X package management system, but not when you want to deploy a similar stack to a IaaS provider where you'll use a different incompatible system like Puppet or Chef to set up the same stuff.

I think we have made this whole situation more complicated and fractured than it needs to be.

Code is reusable data, and regardless of language is much more useful than an arbitrary data format. There was an attempt to port homebrew to linux, but it didn't go far.

dotCloud has just open-sourced Docker[1], an attempt at solving the deployment issue.

[1] http://docker.io

> There was an attempt to port homebrew to linux, but it didn't go far.

Linux already has more package managers than you can shake a stick at. To gain traction on linux, homebrew would have to offer useful features that other package managers don't have. Even then, people are more likely to copy the features into an existing linux package manager.

I don't think people tend to shop around when it comes to package managers; you use whatever your distro provides. If it sucks, you find a better distro or submit patches, depending how involved you are.

I don't know why anyone would want Homebrew on Linux anyway. The whole point of it is that OS X is a mostly-serviceable UNIX without a decent package manager. So if you have a handful of UNIX packages you just want a lightweight way to install them using the system headers where applicable.

But if you need to install tons of stuff the cracks start to show, because you have no conflict resolution or sophisticated versioning. Linux leans heavily on its package managers, so I just don't see what Homebrew has to offer.

Homebrew formulas are much more frequently up-to-date than other package managers due to the crowd-sourced pull-request updates - there isn't a package mantainer that has to do all the work. Formulas are straight-forward and don't have a million conditionals for different system configurations (this would be hard to maintain on linux). These two things already make it much more pleasant to use than apt-get/yum/pacman.

Homebrew seems more akin to Arch's PKGBUILD or Gentoo's ebuilds than other package managers.

Yes, I am familiar with homebrew and use it every day including submitting pull requests back. However you missed the point of my comment. The point is, it's more pleasant until you run into a conflict which existing Linux version managers tend to handle much better (out of experience and necessity). At that threshold of complexity you need something more sophisticated than homebrew to avoid pulling your hair out. OS X benefits from a certain homogeneity that puts homebrew in a sweet spot.

I don't know about "widely adopted", but we do have a common language for expressing how to build/install/test software across Linux, Unix, Windows and OS X:

http://0install.net/interface-spec.html

The tools to read this are in most Linux distribution repositories already (usually under the name "zeroinstall-injector"), and do dependency resolution, conflict resolution (via a SAT solver), GPG signature checking, etc. And each package unpacks to its own directory, so they don't interfere with system packages.

That's not a sandbox. If you have ten programs installed in /usr/local, and you want to uninstall one of them, rm -Rf /usr/local is not the tool for the job. (At least on Linux. I'm assuming UNIX-like Macs are the same.)

Homebrew actually uses /usr/local/Cellar, so rm -Rf /usr/local/Cellar/pypy is what you'd want, except that it won't remove symlinks to /usr/bin, launch scripts and such; you still need some kind of uninstall script (brew uninstall).

Like I said, Homebrew installs in its own directory pretty well. I chose /usr/homebrew, explicitly so I can rm -rf. I think for most Homebrew users their Macs have nothing else in /usr/local and so that's why it's not an unreasonable default.

Changing the prefix still doesn't mean that each app is sandboxed. That is what the parent comment was talking about.

You can't do rm -rf /usr/homebrew/$SOMEAPP/ and know that it is all gone.

Reply on news.ycombinator.com