pkg-config

Greg Troxel gdt at lexort.com
Tue Dec 19 16:43:22 PST 2023


Sandro Santilli <strk at kbt.io> writes:

> On Mon, Nov 20, 2023 at 07:52:59PM -0500, Greg Troxel wrote:
>
>> I do not understand the need for new postgis to support old geos.
>
> My general aim is to make people PARTECIPATE in development, so any
> barrier to that should be avoided as much as possible. This means if
> you, as a developer, have an old geos and $reasons not to upgrade
> ( I for one I've always plenty of reasons not to upgrade ) then I
> still want you to be able to develop PostGIS.

I don't really see it this way.  This notion of "have an old geos" isn't
really accurate.  It's "are running LTS such that /usr/lib/libgesos is
old".  One can certainly build geos to a different prefix, and then
build postgis both to that prefix and using it as a source of geos, and
run new postgis, and debug/develop away.   So, I see "people who have an
old geos" as a legitimization of LTS :-)

Of course, requiring the very latest is unreasonable.  My usual test is
something roughly like "should work with any geos that was current at any point
in the two years before the .0 postgis release of this branch".

> Note I wasn't even happy with the drop of "optional GEOS" and
> "optional PROJ" for that same reason (I think some developers could
> contribute perfectly good features w/out having PROJ or GEOS
> installed.

I'm sure there are people who could, but it doesn't feel like a big
barrier.  There's no clear answer about the tradeoff of the ability to
run without and the maintenance burden of the ifs.


My view may be off, as I am coming at this from the point of view of
packaging, where I end up running many packages from their VCS to
resolve portability issues, and having other packages installed is easy.


More information about the postgis-devel mailing list