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 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:
http://www.postgresql.org/mailpref/pgsql-hackers
