Clean up PROJ mess
Sergey Fedorov
vital.had at gmail.com
Sat Sep 9 07:43:34 UTC 2023
This just amounts to switching the existing proj port from proj5 to the
latest.
On Sat, Sep 9, 2023 at 12:26 AM Dave Allured - NOAA Affiliate via
macports-dev <macports-dev at lists.macports.org> wrote:
> Niklas, you proposed that "proj9" be renamed to "proj", later in the
> migration. I suggest a minor change. Keep "proj9" unchanged, and make
> "proj" an alias for proj9, or whatever the macports mechanism is for that.
> This means that current ports that need "proj9" explicitly in some way,
> remain unaffected.
>
> After that, always install future major versions as explicitly pinned;
> "proj10", etc. "proj" gets updated too, but remains an alias or pointer
> for "the latest version". Port devs will then have their choice of pinned
> or unpinned version, whatever they think is best for their scenario.
> Hopefully this will mean less work at each major version step for proj.
>
>
> On Fri, Sep 8, 2023 at 10:16 AM Nicklas Larsson <n_larsson at yahoo.com>
> wrote:
>
>> Hi all!
>>
>> Glad you took up this subject again. I have meant to return to this, but
>> things always come between.
>>
>> Just to clarify, my main objective is to *rename* the existing proj ports
>> and the latest version would always be ‘proj’.
>>
>> The ports that do not support the new 8+ API will still have its proper
>> dependency (proj7, proj6 etc.).
>>
>> In PROJ version 5 through 8 the API was transformed, this means with
>> version 8 the “old” API was abandoned.
>> SAGA, for example, still only support the old API, thus the proj version
>> 7 is the latest one supported.
>>
>> Cheers,
>> Nicklas
>>
>> On 8 Sep 2023, at 16:52, Sergey Fedorov <vital.had at gmail.com> wrote:
>>
>> I have obviously forgotten to try the new Proj with R ports back then,
>> and atm away from native PPC hardware; so from my side I would prefer not
>> moving to a newer Proj right-away.
>> Switching to explicit proj5 port should be perfectly fine, of course.
>> (And then R ports won’t prevent anything else from updating.)
>>
>> New Proj *should* work with R packages, but let me wait until I can test
>> that on PPC.
>>
>> On Fri, Sep 8, 2023 at 9:38 PM Dave Allured - NOAA Affiliate via
>> macports-dev <macports-dev at lists.macports.org> wrote:
>>
>>> As a contributor to ncarg (proj5), I like this change. Currently there
>>> are only 10 ports that depend on the traditional "proj" which is really
>>> proj5 under the hood. Collectively there are only 3 maintainers plus a few
>>> nomaintainers, and Sergey has already approved for several of the R ports.
>>>
>>> So I see the migration for this group of "proj5" ports as quite simple.
>>> As a first step, could we add an explicit proj5 port, such that proj and
>>> proj5 co-exist temporarily and are exactly the same? That could be done
>>> safely now, with no impact on anything else. Then after migration of those
>>> 10 ports, "proj" could be easily switched to the latest upstream version,
>>> as proposed.
>>>
>>>
>>> On Thu, Jun 8, 2023 at 2:09 PM Sergey Fedorov <vital.had at gmail.com>
>>> wrote:
>>>
>>>> IMO that makes sense.
>>>>
>>>> My R ports are supposed to support more recent versions of Proj than 5,
>>>> but since that is untested locally (and also requires minor adjustments to
>>>> configure args besides swapping version number), it is perhaps safer to
>>>> keep them at Proj5 for now (I guess that is also simpler for you?).
>>>> Then I can move them to a later or the current Proj in a while.
>>>>
>>>> On Fri, Jun 9, 2023 at 3:54 AM Nicklas Larsson via macports-dev <
>>>> macports-dev at lists.macports.org> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> I'd like to propose to simplify the maintainance of the PROJ ports,
>>>>> which has
>>>>> become unnecessary cumbersome and in many cases leading to
>>>>> installments of
>>>>> multiple versions only because different ports are out-of-sync in
>>>>> respect to
>>>>> default proj variant.
>>>>>
>>>>> The PROJ ports available now:
>>>>>
>>>>> port version
>>>>> ---------------
>>>>> proj4 4.9.3
>>>>> proj 5.2.0
>>>>> proj6 6.3.2
>>>>> proj7 7.2.1
>>>>> proj8 8.2.1
>>>>> proj9 9.2.1
>>>>>
>>>>> It would be better to use the port name 'proj' for the latest version
>>>>> available
>>>>> (independent of major version), which now is version 9.2.1. The
>>>>> present port
>>>>> 'proj', which is version 5.2.0, should be renamed to 'proj5'. Like
>>>>> this:
>>>>>
>>>>> port version
>>>>> ---------------
>>>>> proj4 4.9.3
>>>>> proj5 5.2.0
>>>>> proj6 6.3.2
>>>>> proj7 7.2.1
>>>>> proj8 8.2.1
>>>>> proj 9.2.1
>>>>>
>>>>> The day when there is a new major version, e.g. 10.0.0, the 'proj'
>>>>> port will be
>>>>> updated accordingly and 'proj9' will keep the 9.x.y version:
>>>>>
>>>>> port version
>>>>> ---------------
>>>>> proj4 4.9.3
>>>>> proj5 5.2.0
>>>>> proj6 6.3.2
>>>>> proj7 7.2.1
>>>>> proj8 8.2.1
>>>>> proj9 9.2.1
>>>>> proj 10.0.0
>>>>>
>>>>> The ports with 'proj' dependency, which are actively updated and
>>>>> maintained,
>>>>> will in this way be kept in sync with less risk of installing multiple
>>>>> versions.
>>>>> Ports, which do not support later versions of PROJ, can keep the
>>>>> pinned version.
>>>>>
>>>>> List of ports with proj[x] dependency:
>>>>>
>>>>> R/R-lwgeom path:lib/proj5/lib/pkgconfig/proj.pc:proj
>>>>> R/R-proj4 path:lib/proj5/lib/pkgconfig/proj.pc:proj
>>>>> R/R-reproj path:lib/proj5/lib/pkgconfig/proj.pc:proj
>>>>> R/R-rgdal path:lib/proj5/lib/pkgconfig/proj.pc:proj
>>>>> R/R-sf path:lib/proj5/lib/pkgconfig/proj.pc:proj
>>>>> R/R-terra path:lib/proj5/lib/pkgconfig/proj.pc:proj
>>>>> R/R-vapour path:lib/proj5/lib/pkgconfig/proj.pc:proj
>>>>> databases/mysql55-lib_mysqludf_fproj4 port:proj4
>>>>> databases/postgis port:proj4
>>>>> databases/postgis2 port:proj6
>>>>> databases/postgis3 port:proj[6-9]
>>>>> databases/spatialite-tools port:proj[6-9]
>>>>> databases/spatialite port:proj[6-9]
>>>>> gis/gdal port:proj[6-9]
>>>>> gis/grass port:proj[6-9]
>>>>> gis/grass7 port:proj[6-9]
>>>>> gis/liblas port:proj[6-9]
>>>>> gis/libosmium port:proj4
>>>>> gis/mapnik port:proj4
>>>>> gis/mapserver port:proj[6-9]
>>>>> gis/mod_tile port:proj4
>>>>> gis/osm2pgsql port:proj8
>>>>> gis/qgis3 port:proj[6-9]
>>>>> gis/qlandkarte port:proj4
>>>>> gis/qlandkartegt port:proj[4-7]
>>>>> gis/saga port:proj8
>>>>> graphics/libgeotiff port:proj[7-9]
>>>>> octave/octave-octproj port:proj8
>>>>> perl/p5-alien-proj port:proj[6-9]
>>>>> perl/p5-alien-proj4 port:proj4
>>>>> python/py-cartopy port:proj8
>>>>> python/py-pyproj port:proj8
>>>>> python/py-spatialite port:proj4
>>>>> science/cdo port:proj8
>>>>> science/gerris port:proj
>>>>> science/magicspp port:proj6
>>>>> science/metview port:proj6
>>>>> science/ncarg port:proj
>>>>> science/relax3d port:proj7
>>>>> science/sumo port:proj4
>>>>> science/vapor port:proj4
>>>>> science/wgrib2 port:proj8
>>>>> science/xastir port:proj4
>>>>>
>>>>> What do you think, could this be a good way to go forward?
>>>>> Suggestions, opinions?
>>>>>
>>>>> Best regards,
>>>>> Nicklas
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20230909/df7e0760/attachment-0001.htm>
More information about the macports-dev
mailing list