pkg-config

[Greg Troxel]

"Regina Obe" <lr at pcorp.us> writes:

>> I do not understand the need for new postgis to support old geos.
>> People are either drinking the LTS koolaid and should be happy with
>> old everything, or they should be relatively up-to-date.  My personal
>> rule is that when Foo N is released on date D, it should be happy
>> with any version of any dependency, as long as that version is at
>> least the version that was generally recommended for all uses on D -
>> 2years.
>
> That's nice in theory but at least in my reality, some people want a
> really new PostGIS and will stick with LTS from 2 years ago which
> ships with an old GEOS.

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.

> 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.

> I still see a lot of GEOS 3.9s out there of people who really want a PostGIS
> 3.5 badly.

Sure, but I am fundamentally unsympathetic to a mixed LTS/new desire
imposing work on other people.

> GEOS 3.8 is kinda where I feel the fuzzy zone is.  I know two people who'll
> be a bit upset if we drop support for GEOS 3.8
> in PostGIS 3.5.

Would they really have trouble building modern geos and then modern
postgis?


I am more sympathetic about older versions of things like postgresql and
by extension postgis where there is a db upgrade step, instead of just
newer code.  There I'd lean to the version being non-EOL at release
time, when a db has multiple branches.  But it seems the real issue is
systems that are 4 years past release and froze a year before that, more
or less.