[postgis-devel] liblwgeom symbols exported by postgis module

[Paragon Corporation]

Mark and Bas,

Again sorry for coming  off so antagonistic.  
>> A use case I understand, but one that seems developer specific. A user
rarely needs that kind of reproducibility. Why on earth would he *not* want
a fix in liblwgeom to affect older PostGIS versions?

>Because the fix may not be a simple bug fix, but a performance enhancement.
> I think we had a couple of those in PostGIS 2.2 (luckily the lib name is
not the same between 2.1 and 2.2 but will be more of an issue now that we
separated the .so naming From PostGIS)

I think in retrospect I was a bit over dramatic and I'm not being quite as
inconvenienced as I thought I was.
I think it would be a very rare occasion that we don't have the liblwgeom
api change with each PostGIS minor release.  And sure if someone gos from
2.1.8 to 2.1.9 I'd want the lilbwgeom replaced for all libraries that used
that version.

------------------------------------------
Strk,

Correct if I am wrong in the above assumption.


If that is the case, I'm not too concerned especially if I can just continue
statically compiling liblwgeom in with each PostGIS I release.  On windows
everything lives inside the PostgreSQL/bin folder so my concerns are
probably a bit different
And even the cringe  thing I mentioned is more a cringe on Unix/Linux where
the liblwgeom probably sits in system bin.

------------------------------------------------------
Bas and Mark
> The Debian repositories only supply a single postgis version, so you'd
need to build 2.0 manually.

It's a shame Debian provides only one single postgis version, as that makes
it very difficult for people to do a pg_upgrade.  If they were to go to
PostgreSQL 9.5 from PostgreSQL 9.4, and you only provide a PostGIS 2.2 on
9.5 (and not a 2.2 on PostgreSQL 9.4) or vice versa.  They can't just do the
soft upgrade and pg_upgrade migrate or pg_upgrade  /soft postgis upgrade.


Bas,
> I'm no expert on linking issues, so I don't have good advice for Reginas
issue. But not exporting another libraries symbols should be common sense,
GDAL exporting the lib(geo)tiff symbols when the embedded copy is used
caused all kinds of problems requiring the need to rename those symbols for
example.

Thanks for confirming -- so yes strk -- no export, but I wouldn't bother
touching 2.0.  2.1 maybe. 2.0 is already like 3-4 years old.  It should only
have security patches and egregious errors.  Not sure I consider this the
case since no one else I am aware of has run into the issue but you.


> Well, due to the hostility expressed by Paul in particular, I don't want
to be involved in this discussion. I have enough things depressing me as it
is.

Cheer up.  Paul and I can be eventually convinced (or wave our "I told you
so" smiley hats).  I do consider package maintainers most important for
PostGIS ecosystem -- so I wouldn't want to do anything to jeopardize that
relationship and do want to air out the issues and concerns you guys have.
So please continue working with us and don't walk away angry.


Thanks,
Regina