[PROJ] PSC Motion: require SQLite 3.11 as minimum version

Thomas Knudsen knudsen.thomas at gmail.com
Thu Nov 7 08:49:26 PST 2019


+1
(convinced by the evidence and reasoning provided by Greg and Bas, although
it would be nice if we in any practical way could "suggest", rather than
"require" >=3.11)

Den tor. 7. nov. 2019 kl. 17.37 skrev Greg Troxel <gdt at lexort.com>:

> Even Rouault <even.rouault at spatialys.com> writes:
>
> >> This isn’t an optional requirement for
> >> Proj6, basically it’s an unusably bad performance regression, so using
> >> Proj6 requires a newer SQLite given current state.
> >
> > Agreed. This probably mostly affects RHEL 7 which, while not being
> antiquated
> > from the point of view of RedHat's release policies, still ships with
> outdated
> > components by todays' standards. So RHEL 7 users have two options: use
> PROJ
> > 5.x or PROJ 6 + backported SQLite.
>
> This is a fundamental issue with LTS releases.  The idea of building
> current versions of software using dependencies from the LTS release
> basically does not work.  Taken to the extreme, supporting that means
> that every package has to work with all versions of dependencies -- and
> compilers -- that were released over 5 years ago.
>
> As for RHEL 7, it sounds like the question is "build modern proj with
> old sqlite3", and it seems reasonable to just say that isn't supported;
> presumably somebody choosing an LTS release also wants old proj, old
> qgis, etc.  And if they want new, they probably should build an entire
> tree of modern versions that are intercompatible.
>
> All that said,
>
>   NetBSD 8 base system:         3.17.0
>   pkgsrc 2019Q3:                3.29.0
>   pkgsrc curent:                3.30.1
>
> I don't have a NetBSD 7 system handy, or 9 (not released), but since
> proj is in pkgsrc and not in base, it's trivial to make it depend on
> pkgsrc sqlite3.
>
> So I see no issue with requiring 3.11.
>
> I geuss the question is
>
>   If someone builds proj with sqlite3 so old that it will be slow, is it
>   better to let it work and be slow or fail the build?
>
> and I can see your point that it's better to fail.
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20191107/5f5a6bcc/attachment.html>


More information about the PROJ mailing list