pkg-config

[Regina Obe]

Almost EOL?  It is EOL  - see the nice label I put next to it - 3.8.4 EOL

https://libgeos.org/usage/download/
See the final release date not italicized 😊

I'd much rather keep the conditional check in PostGIS 3.5 than do yet another release of 3.8.
What I've observed is most people behind aren't even on the latest micro release.  You know how many 3.9.0s I still see. 

Besides we should support geos-config for at least another PostGIS release cycle before we pull the carpet on people's builds.
Give them a warning, it's coming.  I, as a user, appreciate when a project gives me that courtesy of a grace-period release before they officially break my build script
and I have to scramble to fix it.

Then come PostGIS 3.6, we will have done our duty of providing a grace period to builders and also will not have a GEOS 3.8 to worry about dancing around.

> -----Original Message-----
> From: Paul Ramsey <pramsey at cleverelephant.ca>
> Sent: Tuesday, November 21, 2023 12:37 PM
> To: Regina Obe <lr at pcorp.us>
> Cc: Greg Troxel <gdt at lexort.com>; postgis-devel at lists.osgeo.org
> Subject: Re: pkg-config
> 
> Getting a little off-track for postgis-devel, but since I have you
> here: how crazy would it be to add pkg-config install options to GEOS 3.8?
> Pointless because it's almost EOL?
> 
> P
> 
> On Mon, Nov 20, 2023 at 8:09 PM Regina Obe <lr at pcorp.us> wrote:
> >
> > > That's not a theory; it's a normative statement.  I find that people
> > (their orgs) are
> > > willing to pay places like redhat for LTS and then expect volunteers
> > > to
> > pick up the
> > > pieces and mitigate the consequences of that decision.  I am not ok
> > > with
> > that
> > > situation.
> > >
> >
> > I have no sympathy for those either, but I do have sympathy for the
> > people underneath those people.
> > Those people under those bureaucrats.  But anyway we could argue this
> > point probably not worth wasting breathe on. It's a bad situation all
> > around.
> >
> >
> > > > Sure they'd like a new GEOS especially if it has improvements they
> > > > are looking to take advantage of, but OS upgrades are scary and
> > > > database upgrades are scary too (why we support like 4-5 versions
> > > > of PostgreSQL on each PostGIS version)
> > >
> > > Sure, but if someone can install a new postgis, they can install a
> > > new
> > geos first.
> > > Arguably if someone is running LTS because they want all that LTS
> > goodness,
> > > they will have a policy against putting packages not from the LTS in
> > > the
> > LTS-
> > > managed path (probably /usr if GNU/Linux) and then the new postgis
> > > would
> > be
> > > compiled with --prefix=/usr/new or some such, and it's easy enough
> > > to put
> > geos
> > > in that prefix first.
> > >
> > Compiling geos is not hard.  Compiling postgis is given all the
> > dependencies we have.
> > So people try to avoid the pain by getting PostGIS from third party
> > cause the LTS version is often too old.
> >
> > The fact geos is considered a system library / similar to GDAL is what
> > makes it tough.
> > Those libs are held as a sacred thing not to be touched cause messing
> > with them might break 100s of important things you don't know about.
> > PostGIS on the other hand is not quite so sacred, because no
> > application depends directly on the postgis libs.
> > So people are allowed to get PostGIS from somewhere else and many of
> > those somewhere elses, are building the PostGIS dependencies off of
> > the LTS packages, relegating GEOS and GDAL to be picked up there.
> >