[OSM-dev] osm2pgsql and homebrew

Kai Krueger kakrueger at gmail.com
Thu Jan 24 17:46:11 GMT 2013

Matt Patterson wrote
> Homebrew were packaging osm2pgsql, which was super handy.

Yes, it would be nice to get the osm rendering tool chain into as many
packaging repositories as possible to make it easier for people to install
and use it on various platforms.

Matt Patterson wrote
> They removed it just before Christmas, which was not at all handy. To be
> honest, their reasons were not stupid, as far as packager concerns go:ake 
> * No obvious stable release, leading to:
> * not properly tested package script.
> (see https://github.com/mxcl/homebrew/issues/14383 and
> https://github.com/mxcl/homebrew/commit/2602faf907f26346f39719e4c092a53401676f96)
> I know Kai Kruger packages osm2pgsql for Ubuntu and therefore imposes
> 'stable' releases, at least as far as APT is concerned.

Well, they are not really stable releases and the situation isn't directly
ideal there either. I kind of just periodically take a SVN snapshot and
package it to the ubuntu ppa repository. It isn't directly a "stable release
process". Although I mostly only update the packages for the most recent
developemnt version of Ubuntu. For older / stable versions of Ubuntu, I
mostly only update the packages if there are known issues or a specific
reason that an update is necessary (e.g. to transition to 64 bit builds as
the 32bit unsigned node id space runs out). So those are semi stable. Mostly
also because there are no "stable releases" and so I don't want to risk
breaking existing installations.

Given the developer situation of osm2pgsql / mod_tile, I suspect we won't
see a proper release process with forked off stable versions any time soon.
However, perhaps we can move over to a process a la JOSM? Which seems to
just "randomly" tag SVN snapshots as stable if there have been no reported
issues with that snapshot for a while.

I.e. someone would announce to the dev mailinglist that a certain SVN
revision should be declared "stable" and then if there are no complaints
within e.g. a week it gets tagged as such in SVN?

Do any of the commercial users of the osm rendering stack have some ideas of
how to improve the quality control and "release cycles"?  E.g. to try and
improve the automated testing framework?

Matt Patterson wrote
> I've looked over some of the error reports people were sending in for
> osm2pgsql as part of homebrew and I'm pretty sure that the fix for those
> is simple - namely, that osm2pgsql either doesn't build with Clang, or its
> configure script doesn't think it does, and so the packaging script
> ('formula', if you're unfamiliar with homebrew) needs to declare a
> dependency on GCC-proper.

I haven't tried building osm2pgsql on MacOSX, as I am not really familiar
with the whole development toolchain there, but at least in linux it does
seem to build fine with clang.

I ran the configure script with "./configure CC=clang CXX=clang++" and both
configure and make completed without issues.

If you can help me with more error reports or with guides of how to set
things up and test on mac OSX, I'd be happy to try and fix any build issues. 

Matt Patterson wrote
> I will happily take on ensuring that osm2pgsql gets back into Homebrew if
> there's a sensible way of declaring 'stable' releases - i.e. piggy backing
> on Kai's work, a bi-weekly tarball uploaded to a known location with a
> sensible incrementing naming format, or even just a regularly updated
> 'release' tag in SVN or Git.

What do other osm2pgsql developers think of this? Can we find a more
sensible and reliable solution to this issue than what we have now (i.e. no
policy at all)?


View this message in context: http://gis.19327.n5.nabble.com/osm2pgsql-and-homebrew-tp5746160p5746265.html
Sent from the Developer Discussion mailing list archive at Nabble.com.

More information about the dev mailing list