> Remember when everyone switched to Homebrew because Fink/macports were "antiquated", a.k.a. not written in Ruby?

Yes, I must admit I chose the word "antiquated" quite intentionally, as Homebrew seems to get so much attention (for now) because it's written in Ruby and the website (http://brew.sh/) is shiny, rather than technical merits.

> It was nice back then. Packages didn't install themselves in /usr/local.

You might enjoy Nix, then -- for that reason, and the following:

1. Everything is stored in /nix/store -- nothing ever touches /{local,}/{bin,lib,share}

2. Profiles are symlink forests that merge multiple packages into one FSH[1]-like tree -- each link pointing into /nix/store. When you install a package, a new symlink forest is created replacing the one at ~/.nix-profile (your user profile, being the default). If you request that nix rollback to a previous "generation" of your profile, all Nix has to do is replace the ~/.nix-profile link to instead point at the previous generation's symlink forest (you can think of this as bumping HEAD in git -- it's nearly instantaneous). If upgrading a package goes wrong, just rollback.

3. Because Nix knows the entire dependency graph, its trivial to distribute a build plan across multiple machines (you can set this up to happen by default)

4. We have a continuous integration server (Hydra[2]) that builds and signs all of our packages. Of course, there's nothing stopping you from building from source (or you could run your own Hydra instance, if you so wish).

[1]: http://www.pathname.com/fhs/ [2]: http://nixos.org/hydra/

That's the purpose of /usr/local.

/nix/store? Really? You can't just make up new root level directories. That's so wrong.

The purpose of /usr/local is for you to put stuff there, but it actually causes a lot of problems if a package manager does it.

- your work-issued laptop might have work stuff installed in there, and the package manager will overwrite it

- build-from-source package managers like fink/ports/brew are incapable of controlling themselves and always install things you didn't ask them to

Since /usr/local is in the default search path for your compiler, that last one means your personal configure script runs are not reproducible, and you'll start linking to packaged versions of libiconv or whatever without meaning to, and your code won't work on other machines or it'll crash unexpectedly.

Fink invented /sw for this, MacPorts uses /opt which I think they got from Solaris?

> That's the purpose of /usr/local.

I think you must have ignored a substantial portion of my comment. Let's take a look at what (part of) my Nix store looks like (you'll see it fundamentally looks nothing like /usr/local):

  /nix/store/2mmvks92lx37xghj0795ldzrg50lh2pg-bash-4.3-p42
  ├── bin
  │   ├── bash
  │   ├── bashbug
  │   └── sh -> bash
  └── share
      ├── info
      │   ├── bash.info
      …   …
      └── man
          └── man1
              ├── bash.1.gz
              └── bashbug.1.gz
  
  /nix/store/8g6gb6r49fxsrp547rdi3zr06vd69khq-git-2.7.4
  ├── bin
  │   ├── git
  │   ├── git-cvsserver
  │   ├── git-http-backend -> /nix/store/8g6gb6r49fxsrp547rdi3zr06vd69khq-git-2.7.4/libexec/git-core/git-http-backend
  │   ├── git-receive-pack -> git
  │   ├── git-shell
  │   ├── git-upload-archive -> git
  …   └── git-upload-pack
  

Note that each package under /nix/store is its own prefix; that is, it contains its own bin, lib, share, etc.

/usr/local is a dumping ground "for use by the system administrator when installing software locally"[1]. If you need multiple versions of automake installed: tough luck, the paths collide. If you need multiple versions of Erlang: tough luck, the paths collide.

Would you like to be able to rollback your system by changing one symlink[2]? Too bad: when you last installed packages into /usr/local, your package manager clobbered the previous version.

Technically, we could make /usr/local a symlink forest pointing into /nix/store, but we don't: we want to make sure that only the packages we explicitly declared are picked up by build tools, rather than defaulting to searching through the currently "installed" packages.

> /nix/store? Really? You can't just make up new root level directories. That's so wrong.

Can you substantiate your claim? Note that "it doesn't feel right" doesn't count as a rational criticism.

[1]: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHI...

[2]: This probably sounds like a bold claim. I tried to explain how this works above, but if you don't believe me, feel free to ask and I'll explain further. Alternatively, feel free to read the first paragraph here: http://nixos.org/nix/manual/#sec-profiles

Funny that you should mention the FHS. From that same document:

Applications must never create or require special files or subdirectories in the root directory. Other locations in the FHS hierarchy provide more than enough flexibility for any package.

They really should be using /opt:

/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree

I left MacPorts because the political infighting between package maintainers often left ports hopelessly out of date.

That's basically the main reason why I left MacPorts. The other was the fact that they'd build their own version of already installed programs. The worst offender for a long time was tetex until they finally added support for looking at an existing tetex installation.

I also ran into a number of broken ports. I had used Fink, but I ran into issues with its packaging too. So, when I heard about Homebrew, I decided to try it. It's been pretty decent for me so I've stuck with it. The only major issue I've had has been related to Octave, but that's been a problem for MacPorts too as the OS X version isn't as up to date as the Linux version at times.

I remember switching from Fink and Macports because most of the time both of them would break or break something important.