Re: Switching to Homebrew as recommended Mac install? - Mailing list pgsql-hackers

On 04/01/2012 04:19 PM, Jay Levitt wrote:
>> POSSIBLE OBJECTIONS/PREREQUISITES
>
> 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
> acceptable.

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.

--Security

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.

--Documentation

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    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com