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)? Kai -- 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. _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
