[postgis-devel] liblwgeom.so

Paragon Corporation lr at pcorp.us
Fri Sep 9 12:16:37 PDT 2011


> So, back in mid-month, strk asked:
> 
> "Do you agree on having liblwgeom installed systemwide and 
> dynamically linked starting with PostGIS 2.0 ?"
> 
> And there followed, oddly enough, a lot of discussion about 
> the mechanics of doing it and no discussion at all about the 
> wisdom of doing it. I would like to backtrack a little and 
> talk about why it gives me a case of the heebie jeebies.

Hmm and I was one of the people who thought this was a good idea.
Part of the reason I thought the break apart was good (not necessarily the
dynamic linking)

was for example because we have raster which seemed like it was needing to
do gyrations linking
into postgis etc. to get to the proj base and so forth.

> 
> * Our build is already getting complexer and complexer, and 
> this adds more complexity, and another autotool to our world.
> * Breaking our install into components (this library here, 
> these tools that depend on it there) adds to the number of 
> places an install can fail (ha ha! you can't find the 
> library! (note how many times this happens to us already with 
> libgeos!)) even though in theory this stuff always "just works"
> * We are a PgSQL extension, not a third-party library. If 
> this actually "succeeds" in getting people using liblwgeom, 
> it also "fails"
> in that now we have to, in addition to doing our own work as 
> PostGIS developers, ensure we don't break other people's 
> work. If we do change things all the time and people don't 
> use us, then we don't "succeed", so the "let other people use 
> liblwgeom" argument fails.
> 
> I feel like there are non-trivial negatives to this plan and 
> no strongly articulated positives.
> 

I still think we probably need to in the future.  It is internals being
reorganized as Bborie
put it.  I think we might have jumped the gun a little too soon and should
have focused more on testing
what we have and none of us going into it realized
how much of a toll this would take.  In hind sight I can say -0.5, but not
knowing what I know now,
I would have gone with a 1.

-- Regarding Bryce's comment --- 3.0 -- 
Nah we don't have to wait that long.  As long as people can do a soft
upgrade that is all that
really matters.  The reason we wanted things tested for PostGIS 2.0 sooner
than later
was to make sure the disk changes we made would not need to be changed
further before we released, because
if they did, that would require waiting till 3.0.

Thanks,
Regina





More information about the postgis-devel mailing list