Switching to Homebrew as recommended Mac install? - Mailing list pgsql-hackers
From | Jay Levitt |
---|---|
Subject | Switching to Homebrew as recommended Mac install? |
Date | |
Msg-id | 4F78B716.9090801@gmail.com Whole thread Raw |
Responses |
Re: Switching to Homebrew as recommended Mac install?
Re: Switching to Homebrew as recommended Mac install? Re: Switching to Homebrew as recommended Mac install? Re: Switching to Homebrew as recommended Mac install? |
List | pgsql-hackers |
The Mac installation docs currently recommend the EDB one-click installer as the first choice. While this does install pgadmin and some other refinements, it also is fairly confusing to troubleshoot: - By default, it installs to /Library/PostgreSQL, which is also (I think) where the Apple-supplied Lion install is - 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. - The EDB docs are written against 8.4. - There are, as @lluad points out, no fewer than eight ways to install Postgres on a Mac (fink, macports, homebrew, Lion default, build from source, EDB, and two other binary installers) - We have few Mac experts hanging out in #postgresql. - We just had two folks within an hour, BOTH with conflicting installs of Postgres. So with all respect and thanks to EDB for maintaining those installers, I'd like to propose that homebrew become the recommended install method on Mac, and I will update the Mac formula to overcome any current objections. The nice thing about homebrew is that (a) formulas can contain arbitrary Ruby and command-line options, so we can easily deal with things like detecting existing installs, handling shared memory, etc. if we want to, and (b) pull requests are accepted freely and frequently, so it can always be the current, security-patched version. What do folks think of this idea? When I mention homebrew in #postgresql, there's always an "ick", but I believe that's true of any package manager (and possibly any Mac anything, because we're all Rails-loving ORM-using SQL-not-understanding fanbois, and I say that with love.) The current homebrew installer is already 9.1.3, and does a make-world, so you get all of contrib built. POSSIBLE OBJECTIONS/PREREQUISITES 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. 2. The current formula installs Postgres as the desktop user, not as the _postgres role account. I'm personally of the strong opinion that user-to-user privilege escalation attacks are NOT an issue on desktops; all important files are already owned by the desktop user. The attack vector is *maybe* root escalation attacks, but if you want root, it's so common for installers to ask permission that your malware could just ask. The real attack vector is "I'm in your browser", and that has nothing to do with root, permissions, or users at all. 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. However, if this is a sticking point, I'd have no problem adding a --user option that would default to _postgres (underscore-prefixed usernames are the Apple standard). 3. The current formula (TCF) spits out instructions telling you how to initdb, but they're easy to overlook. I'm happy to add an option if necessary, and might do it anyway. 4. TCF also spits out instructions for adding Postgres to launchctl (Mac's version of /etc/init.d or Windows Services), rather than doing it for you, but again, I'd happily add the option. (I'm checking with Homebrew folks to see if there's some dictum against that; it's a common pattern to put launchctl in the instructions, but IME the usability is poor.) 5. TCF doesn't update your shared memory settings. Again, happy to add that. 6. TCF doesn't look for existing installs. This is especially a problem on Lion, since Apple bundles PG 8.4, either client or server IIUC, and although /usr/local/bin is in your PATH, it comes *after* /usr/bin (grumble), so you'll either have the homebrew server fail to launch (since port 5432 is in use), or you'll have an outdated client version. In IRC, both users had actually installed the EDB version months ago and forgotten about it, but over time, Lion users will grow, since all new Macs come with only Lion. There are several ways to address this; my preference is to have homebrew 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/. 7. There's no homebrew formula for pgadmin. I've never built it, and might be able to add that, but probably not right away. 8. There might be other popular things that EDB's StackBuilder does. 9. EDB is an important contributor to the PG core community, and maybe the link juice/publicity is politically important. Lemme know. That's all I can think of... thoughts? Objections? Which do you think are prerequisites? Jay Levitt
pgsql-hackers by date: