[geos-devel] [postgis-devel] GEOS 3.4.0 is out

[Greg Troxel]

"Paragon Corporation" <lr at pcorp.us> writes:

>> Does the missing platform.h cause you problems?
> If its still broken for you then I guess we'll need to push a 3.4.1 since
> fixing this would require changing the Makefile.am again
> Which is technically part of source.
>
> Regarding the platform.h issue -- that was in response to Frank w.
> complaining that it makes it difficult to compile the tar ball under Nmake.
> You see there is a  platform.h.in  and a platform.h.vc so when the tar is
> built under POSIX it creates a platform.h that is invalid for Nmake (windows
> users).

I was only commenting that the new release did not install platform.h;
the fact that it's not in the tarball sounds right, because files
generated by configure should be omitted anyway.

> I had tested with ./configure and it seemed to compile okay with that
> missing so presumed it was fine.  I took frank's word for it as far as Nmake
> was concerned.

I haven't the foggiest idea if the missing *installed* platform.h is an
actual issue.  But when an include file is part of the de facto public
interface, sometimes people rely on it.  I didn't see in NEWS that it
was no longer installed; perhaps it's documented that it's buggy to
include it (like linking with the C++ library), in which case there's no
issue.

>> I think I should wait until there's a correct release tarball.
>
> Guys sorry. Was it wrong protocol to just fix the 3.4.0 tarball. Is it still
> broken for you Greg?

The replaced tarball seems ok (the only remaining issues are the changed
installed file set, which may or may not be a bug, and test failures,
which don't appear to be related to the tarball creation process).

> I was thinking I should have given it a different name such as
> geos-3.4.0-2.tar.bz2 (which is what I do when I screw up windows packaging
> in stackbuilder)
> But then I was worried people would get even more confused since they are
> accustomed to just pulling a geos-<someversion>.tar.bz2.  
> So I just (hopefully) fixed the broken build.

Yes, it's a protocol violation (according to the world view of packaging
systems) for there ever to exist two distinct tarballs with the same
name.  There have been instances of malicious replacement of tarballs,
and this sort of thing sets off alarm bells.  Hence trying to keep the
non-malicious instances to zero so the alarms are all real and not
ignored.

> Well it would be really nice not to have to bump to 3.4.1 for something that
> is mostly a packaging issue.

I don't understand why you say that; version numbers are just symbolic
names, and there are plenty of them.  It's quite normal to withdraw a
numbered release and have a new one quite soon when there are issues
like this.

> In that case I would vote for 
>
> 1) Lets find more things to complain about all this week
> 2) Release a 3.4.1 on Friday that takes care of the complaints.
>
> You could say my screw-up is a window of opportunity to complain for another
> week :)

If that's warranted separately, then that's of course fine.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20130812/eb050d46/attachment.pgp>