On 04/01/2012 04:19 PM, Jay Levitt wrote:

10. There is no homebrew support for multiple versions, and no current
plans to add it (though it's on the wishlist). This means homebrew is
only useful if "I want to install a PostgreSQL thingie" is the common
Mac use case. If people often need to use specific older versions, to
mirror their server configs, it's a problem. It *might* be possible to
hack this into our formula, but I'm not sure it's either doable or

To be a credible alternative to EDB's packages, Homebrew would need to match having installers for all of the supported versions at http://www.postgresql.org/support/versioning/ , which right now means back to 8.3. While I'm often annoyed at "checkbox compliance" exercises, that's unlikely to be a negotiable one. Your optimism that it's "just switch the version number to build another version" will make everyone who currently builds packages roll their eyes too. Wandering this road will end up with a formula for each version, because they will be different sometimes, and there's going to be packaging bug backporting coming out of that. Just be glad you don't have to worry about anything before 8.3 now.

I just started playing in this area recently. I have a shell utility whose purpose in life is to make it easier to install multiple PostgreSQL builds from source: https://github.com/gregs1104/peg

I confirmed recently that it works fine on OS X using brew. Was even toying with renaming the project ('peg' is already squatted on in Homebrew) and packaging it up. There are enough people who hack on PostgreSQL on Macs using Homebrew that I think I'd find a few users. I'm not sure if someone would be willing to get stuck with maintaining that if it got merged into an official package though.

That's wavering off topic though, so back to more officialish installers. You've asked one question and discussion has implied a few others. Let me try to iterate over them with my opinions:

-Will PostgreSQL switch to Homebrew as the recommended Mac install soon?

No. You've already hit a few nerves suggesting why, as well as suggesting some of the issues in your first e-mail. There's a larger problem challenging Homebrew too. This sort of Mac packaging has never escaped having a flavor of the week feel to it, and as a group the people working on PostgreSQL are not fans of switching things regularly like that. Don't take that personally: this is a project that stayed on CVS until late 2010, partly because the alternatives didn't seem stable enough. And when we did switch, it was only after finding problems that had to be fixed in the tools used. You just got a first round of such griping here.

I do believe Homebrew is the lead dog in the build from source race right now, but the history here says the right bet is on none of them--that the simplest feasible binary install is the right choice for the "recommended" package. That's what EDB is trying to do, and some of the important associated details like "make it easy to use pgAdmin" are not really negotiable.

-Should there be better documentation on using Homebrew to satisfy people who don't like the assumptions made by the EDB Mac packages?

Yes. We've had a link from http://wiki.postgresql.org/wiki/Detailed_installation_guides to one of the early guides for a while. I've been wanting to see a whole page hosted directly on the wiki covering this subject; I just created https://wiki.postgresql.org/wiki/Homebrew for that purpose. I'll link it into the main install guide section once it's more interesting.

-Should Homebrew add [automatic initdb|service script integration|compatibility with using a postgres user]?

Yes to all of these. If you're going to argue from a perspective like "make it easy for Ruby developers", it really should be easy in the end, to make for a compelling change from the status quo.

I think you've set your sights beyond their needs. If the Homebrew recipe becomes better, and some rough edges are removed, those are the important parts. I don't think Homebrew shouldn't aim to satisfy everyone; it should do a really good job satisfying its intended audience. It is not necessary to make it the "recommended" installer for that to happen. I'd suggest dumping that whole idea as too ambitious and focus just how to make things better for the intended targets. Homebrew is never going to be an "enterprise" satisfying installer, since most businesses will not tolerate building from source themselves unless pressed extremely hard.

-What needs to change in Homebrew before it would be considered more seriously by the PostgreSQL community?

You framed your discussion points as a technical argument. Good execution there is a necessary component, but not the only one. I mentioned pgAdmin (and "Formulas are simple if building is simple" will surely be of no help there) and multiple version builds already; some other sub-topics are important too.


There's a tricky line between 'secure by default' and 'easy to use' that people are always fighting about. Impossible to make everyone happy at the same time. Right now I think Homebrew is skewed a bit far toward the 'easy' side for comfort. There's surely a better middle ground to be found here though, and there are multiple Mac wielding developers who know PostgreSQL packaging floating around. I've been wondering if it's worthwhile to consider a pair of formula, differing only in this area: a clearly labeled unsecured but easy to use one, and a production server one.

--Critical release updates

Another thing that would need to get nailed down is the staff that will be maintaining each of the supported PostgreSQL versions, along with responding to things like sensitive security updates. I know where to find Dave Page and his team at EDB--I just talked with him last night. Homebrew needs some time to build up more direct PostgreSQL community connections before the project is going to be trusted similarly.

--Support contacts

We'd need to have a number of people committed to helping with formula problems on any version of PostgreSQL, who can schedule commits to the master repo. "Anyone can push an update!" != "someone will push an update to the right place".

A lesson from the git conversion here would be to work bottom-up. The whole community doesn't just move to something new via orders from some top; it happens by converting one developer at a time until there's a critical mass convinced.


Homebrew will have to become more complicated if it's going to try and wander down this path. With complexity and backward compatibility come increased needs for documentation.

Greg Smith   2ndQuadrant US    g...@2ndquadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to