Dave Page wrote:
> It seems to me that most of your arguments against the installers are
> based on incorrect understanding or information, and most of your
> arguments for Homebrew actually come across as arguments against!

You're right about the former - and as to the latter, they *were* arguments against ("potential objections"). I try to pre-argue against my own proposals to save everyone time; if I can still prevail, I must have a damn good idea :)

At this point I agree with you, but I'm still going to go into detail, because I think there are two markets for Postgres, and the database community has been so focused around enterprise for so long that you're missing opportunities with web startups. I'd love to help bridge the gap, having jumped straight from big-iron PL/I to ooh-Ruby-is-shiny. And web startups develop on Mac laptops. They just do. So if it helps you to imagine me as a 20something "I'm a Mac" hipster, working on some hot Facebook/mobile app with funding from Spark Capital, do that. Lord knows it helps me.

>> - We have few Mac experts hanging out in #postgresql.
> Not sure how this is relevant to the proposal.

The impetus for the idea was that there seems to be a steady stream of novice PG users on Mac who come into #postgresql with installation problems, which is bad enough as an out-of-box experience - but worse is that there are rarely folks around who can help. (Of course, I'm extrapolating; every time *I'm* in IRC and see this, there's someone who can help. But you know what I mean.)

And (although my proposal started with documentation) I'm of the firm opinion that "there's no such thing as a documentation error"; a user problem is a software problem. Humans will click buttons before they'll read, developers are humans, and no amount of RTFM will ever fix that. If we can make installers smarter, that's way better than troubleshooting guides, IRC, mailing lists, etc. So that's where I was coming from.

I didn't realize that you were actively maintaining the EDB installer (see below for the 8.4 doc explanation); obviously, if you can improve that, it's the best solution and we should, if anything, recommend it MORE vigorously. Still, there's a growing community of developers who expect "brew install" to work, and I do want to fix it for them. The EDB installer will always be a one-off experience; most of the other servers you install will be through a package manager, and homebrew's popularity (despite its youth) is impressive. Both of my n=2 data points had run across PG a while back, installed it with the one-click to try it out, forgotten about it, done "brew install postgresql" today, and naturally ran into problems.

>> - By default, it installs to /Library/PostgreSQL, which is also (I think)
>> where the Apple-supplied Lion install is
> No, Apple's version is installed in /usr on mine.

Ah hah. I suppose only the Apple .plist is stored under /Library, then. Let me amend that to "this made everyone in IRC, and probably many other non-Mac-expert troubleshooters, assume that this is an Apple-installed package." It'd be great for this to go somewhere that feels like "Oh, this was installed by you"; /Library feels kinda weird for a server, though I can understand your reasoning. Maybe even /Library/EnterpriseDB/PostgreSQL to make it obvious?

>> - The uninstaller is hidden in /Library/PostgreSQL, which (since Finder
>> hides /Library by default) you're likely to go to via Terminal. But the
>> uninstaller is a Mac app, so even if you find it you have to know to use
>> "open" to run it, because Mac apps are really directories that the Finder
>> abstracts away from you.
> Yes.

How about a one-liner bash script "uninstall-postgresql" that does nothing but "open uninstall-postgresql.app"?

>> - The EDB docs are written against 8.4.
> Only if you install 8.4. If you install 8.3 you get the 8.3 docs, 9.0
> the 9.0 docs and so on.

No, I meant on the web:


That's what made me assume that the installer wasn't maintained (except as to repackaging new PG versions, obviously). It's obviously not hard to replace "8.3" with "9.1" when you read it, but it still leaves an impression akin to "This web site works best with IE7 and above." Allow me to now replace most of this thread with "hey, you might wanna update that page."

>> - There are eight ways to install Postgres on a Mac
> That isn't any more of a reason to discount the EDB installer than any other.

Nope, just an argument that the recommended installer should handle that nicely.

>> - We just had two folks within an hour, BOTH with conflicting installs of
>> Postgres.
> Not sure how that is relevant either. You can have conflicting
> installation using any of the installation methods, including a
> home-built source tree.

Right, but I suspect this is a common problem - not only have I seen it in IRC but 3 or 4 times in my 12-person startup, which is kinda amazing given that we've been recommending homebrew since day 2 last year (but day 1 was macports, and then there was Lion, which is already 30-40% of the Mac installed base).

It's worse in the Mac world because it is, very much unlike the enterprise database world, a whiplashing, trend-driven ecosystem. Once there was Fink, and there was great rejoicing because now we had a package system at all. And then there was MacPorts, and everyone said "that's so much better! Let's all switch!" and there was rejoicing and some conflicts. And now the Rails community is both (a) collectively realizing that MySQL is not, in fact, better than Postgres for any of their use cases, and thus embracing PG as their go-to database, and (b) loving homebrew, no doubt because it's written in Ruby. And the Rails community is a Mac community.

So you have a growing user base who may have tried two or three package managers over the years and either ignored the warnings to not run both, or couldn't find all their packages in one manager, plus people who are using Lion and didn't realize it now comes with PG, so they're trying to install it, plus the I-forgot-I-tried-this crowd... it'd be nice to handle this case.

>> 1. homebrew installs everything under /usr/local and makes that
>> user-writeable.  Sorry.  It does because most Mac users don't know how to
>> edit PATH for GUI apps (it's in a .plist in a hidden directory in your home
>> dir), and /usr/local is already in PATH by default.
> Your reasoning doesn't make sense. Why does putting something in the
> path require a directory to be world writeable.

Sorry - two separate things plus one misdirected argument:

1. Rubyists in general are sick of sudo'ing on their laptops, because It Doesn't Matter (as I'll fail to argue later). Homebrew puts itself into a directory that is user-writable so it does not require sudo for basic installation.

2. Because shell's $PATH is hard to change programmatically due to shell-config individualism (MacPorts was notorious for failing at this), and yet many Mac programmers know nothing of shells at all (so they don't know how to edit it manually), Homebrew puts itself into a directory that is already in $PATH by default, but which is conveniently nonexistent by default.

Thus, Homebrew chowns /usr/local to (desktop user):admin.

> In any case, the fact that Homebrew does that to /usr/local should be
> enough to make any user run away screaming in terror. If it opens up a
> security hole like that, what else does it do to break your system?

So this is pointless to the discussion now, but if you want to engage off-list, I'd frankly love to be reconvinced: Assume that I am on a laptop, not a server. There is one physical user, and that user is me. I am always logged in as that user. I am also conditioned to enter my password every time an installer says it needs me to. I am a developer, and I am writing software that will require me to keep my database credentials in cleartext in a directory readable by me, and in the non-PCI, non-SOX, non-HIPPA world of startups, those are certainly going to be superuser credentials for convenience. What, exactly, is the attack vector opened by installing postgres or other developer tools under my username? And what is the relative risk of being targeted along that vector, and not "You're at Starbucks and you're browsing Facebook without SSL", other than spear phishing attacks?

>> 2. The current formula installs Postgres as the desktop user, not as the
>> _postgres role account.
> That's not very helpful on shared machines - and whilst it may be fine
> for developers etc, it's not the recommended way to setup PostgreSQL
> for any kind of production use.

Oh, of course. Homebrew does not target the three remaining people who run production XServes. It's purely for Mac developer workstations. At startups. Which are MacBooks! :)

>> Meanwhile, the EDB installer by default installs both app and data to a
>> directory that requires root - so I assume it runs as root too - and
>> nobody's complained.
> No it doesn't. It installs the app to a root owned directory for
> security, and the data goes in a postgres owned directory so it can
> only be modified by the account the service runs under.

My bad - false assumption.

> They seem like a number of reasons not to use Homebrew too (at least
> as it is now).

Right, but it's about 20 lines of code to fix all that; embrace the wonder of Ruby.

>> In IRC, both users had actually installed the EDB version months ago and
>> forgotten about it, but over time, Lion users will grow, since new Macs
>> come with Lion.  There are several ways to address this; my preference
>> is to warn about existing installs but take care of any magic
>> to make them go away, a la
>> http://nextmarvel.net/blog/2011/09/brew-install-postgresql-on-os-x-lion/.
> So you propose to make it silently disable existing servers?

Oh, God no. I meant "You have an existing Postgres install. Do you really want to replace the binaries? We'll stick them in this directory for safekeeping." I do not think the homebrew use case and the multiple side-by-side versions use case overlap at all. (Except me, and I'd cope.)

>> 8. There might be other popular things that EDB's StackBuilder does.
> PostGIS, Slony, psqlODBC, pgJDBC, Npgsql, phpPgAdmin...

OK, I'm convinced! (Though for the record, homebrew has formulas for postgis, pg_top, pgbouncer, pgpool-ii, and pgtap, so nyah. Formulas are simple if building is simple; pgtop.rb attached if you're curious.)

require 'formula'

class PostgresqlInstalled < Requirement
  def message; <<-EOS.undent
    PostgresQL is required to install.

    You can install this with:
      brew install postgresql

    Or you can use an official installer from:
  def satisfied?
    which 'pg_config'
  def fatal?

class PgTop < Formula
  homepage 'http://ptop.projects.postgresql.org/'
  url 'http://pgfoundry.org/frs/download.php/1781/pg_top-3.6.2.tar.gz'
  md5 '12ddb50cf83e3027d182a1381d388f1d'

  depends_on PostgresqlInstalled.new

  def install
    system "./configure", "--disable-debug", "--disable-dependency-tracking",
    system "make install"
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to