[PROJ] Calling for 7.0.1 release
Sebastiaan Couwenberg
sebastic at xs4all.nl
Wed Mar 25 03:42:52 PDT 2020
On 3/25/20 11:18 AM, Devrim Gündüz wrote:
> On Wed, 2020-03-25 at 05:50 +0100, Sebastiaan Couwenberg wrote:
>> The you should consider automake a dependency that you need to provide
>> as well.
>
> You have zero idea about RHEL world, right?
You obviously don't know me, I'm actually quite familiar with the RHEL
world.
> I hope this does not reflect the vision of the Proj community.
It reflects my vision as a fellow PROJ packager.
My advise for yum.postgresql.org is to be much more conservative when it
comes to including dependencies that are not required for PostgreSQL or
its extensions. PostGIS does not require PROJ >= 6.
apt.postgresql.org used to include backports of gdal & geos, mostly for
postgis. Fortunately it doesn't do that any more. When you're providing
backports of core geospatial libraries you should also provide backports
of their dependent packages like spatialite, qgis, etc. Otherwise users
will have a bad time when postgresql is using a newer version than the
other packages they use.
Since geospatial support via postgis is only an extension for
postgresql, providing backports of geospatial libraries used by postgis
should be considered out of scope yum.postgresql.org.
Updating PROJ to >= 5 is also not appropriate for EPEL 7 because it's
too disruptive. yum.postgresql.org would do well with a similar
conservative policy.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
More information about the PROJ
mailing list