<div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 8, 2023 at 10:16 AM Nicklas Larsson <<a href="mailto:n_larsson@yahoo.com">n_larsson@yahoo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="line-break:after-white-space"><div>Hi all!</div><div><br></div><div>Glad you took up this subject again. I have meant to return to this, but things always come between.</div><div><br></div><div>Just to clarify, my main objective is to *rename* the existing proj ports and the latest version would always be ‘proj’.</div><div><br></div><div>The ports that do not support the new 8+ API will still have its proper dependency (proj7, proj6 etc.).</div><div><br></div><div>In PROJ version 5 through 8 the API was transformed, this means with version 8 the “old” API was abandoned.</div><div>SAGA, for example, still only support the old API, thus the proj version 7 is the latest one supported.</div><div><br></div><div>Cheers,</div><div>Nicklas</div><div><br><blockquote type="cite"><div>On 8 Sep 2023, at 16:52, Sergey Fedorov <<a href="mailto:vital.had@gmail.com" target="_blank">vital.had@gmail.com</a>> wrote:</div><br><div><div dir="ltr">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.<div>Switching to explicit proj5 port should be perfectly fine, of course. (And then R ports won’t prevent anything else from updating.)<div><br></div><div>New Proj <i>should</i> work with R packages, but let me wait until I can test that on PPC.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 8, 2023 at 9:38 PM Dave Allured - NOAA Affiliate via macports-dev <<a href="mailto:macports-dev@lists.macports.org" target="_blank">macports-dev@lists.macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 8, 2023 at 2:09 PM Sergey Fedorov <<a href="mailto:vital.had@gmail.com" target="_blank">vital.had@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">IMO that makes sense.<div><br></div><div>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?).</div><div>Then I can move them to a later or the current Proj in a while.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 9, 2023 at 3:54 AM Nicklas Larsson via macports-dev <<a href="mailto:macports-dev@lists.macports.org" target="_blank">macports-dev@lists.macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hello all,<br>
<br>
I'd like to propose to simplify the maintainance of the PROJ ports, which has<br>
become unnecessary cumbersome and in many cases leading to installments of<br>
multiple versions only because different ports are out-of-sync in respect to<br>
default proj variant.<br>
<br>
The PROJ ports available now:<br>
<br>
port version<br>
---------------<br>
proj4 4.9.3<br>
proj 5.2.0<br>
proj6 6.3.2<br>
proj7 7.2.1<br>
proj8 8.2.1<br>
proj9 9.2.1<br><br>
It would be better to use the port name 'proj' for the latest version available<br>
(independent of major version), which now is version 9.2.1. The present port<br>
'proj', which is version 5.2.0, should be renamed to 'proj5'. Like this:<br>
<br>
port version<br>
---------------<br>
proj4 4.9.3<br>
proj5 5.2.0<br>
proj6 6.3.2<br>
proj7 7.2.1<br>
proj8 8.2.1<br>
proj 9.2.1<br><br>
The day when there is a new major version, e.g. 10.0.0, the 'proj' port will be<br>
updated accordingly and 'proj9' will keep the 9.x.y version:<br>
<br>
port version<br>
---------------<br>
proj4 4.9.3<br>
proj5 5.2.0<br>
proj6 6.3.2<br>
proj7 7.2.1<br>
proj8 8.2.1<br>
proj9 9.2.1<br>
proj 10.0.0<br>
<br>
The ports with 'proj' dependency, which are actively updated and maintained,<br>
will in this way be kept in sync with less risk of installing multiple versions.<br>
Ports, which do not support later versions of PROJ, can keep the pinned version.<br><br>
List of ports with proj[x] dependency:<br>
<br>
R/R-lwgeom path:lib/proj5/lib/pkgconfig/proj.pc:proj<br>
R/R-proj4 path:lib/proj5/lib/pkgconfig/proj.pc:proj<br>
R/R-reproj path:lib/proj5/lib/pkgconfig/proj.pc:proj<br>
R/R-rgdal path:lib/proj5/lib/pkgconfig/proj.pc:proj<br>
R/R-sf path:lib/proj5/lib/pkgconfig/proj.pc:proj<br>
R/R-terra path:lib/proj5/lib/pkgconfig/proj.pc:proj<br>
R/R-vapour path:lib/proj5/lib/pkgconfig/proj.pc:proj<br>
databases/mysql55-lib_mysqludf_fproj4 port:proj4<br>
databases/postgis port:proj4<br>
databases/postgis2 port:proj6<br>
databases/postgis3 port:proj[6-9]<br>
databases/spatialite-tools port:proj[6-9]<br>
databases/spatialite port:proj[6-9]<br>
gis/gdal port:proj[6-9]<br>
gis/grass port:proj[6-9]<br>
gis/grass7 port:proj[6-9]<br>
gis/liblas port:proj[6-9]<br>
gis/libosmium port:proj4<br>
gis/mapnik port:proj4<br>
gis/mapserver port:proj[6-9]<br>
gis/mod_tile port:proj4<br>
gis/osm2pgsql port:proj8<br>
gis/qgis3 port:proj[6-9]<br>
gis/qlandkarte port:proj4<br>
gis/qlandkartegt port:proj[4-7]<br>
gis/saga port:proj8<br>
graphics/libgeotiff port:proj[7-9]<br>
octave/octave-octproj port:proj8<br>
perl/p5-alien-proj port:proj[6-9]<br>
perl/p5-alien-proj4 port:proj4<br>
python/py-cartopy port:proj8<br>
python/py-pyproj port:proj8<br>
python/py-spatialite port:proj4<br>
science/cdo port:proj8<br>
science/gerris port:proj<br>
science/magicspp port:proj6<br>
science/metview port:proj6<br>
science/ncarg port:proj<br>
science/relax3d port:proj7<br>
science/sumo port:proj4<br>
science/vapor port:proj4<br>
science/wgrib2 port:proj8<br>
science/xastir port:proj4<br><br>
What do you think, could this be a good way to go forward?<br>
Suggestions, opinions?<br><br>
Best regards,<br>
Nicklas<br></blockquote></div></blockquote></div></div></blockquote></div></div></blockquote></div></div></blockquote></div></div>