Re: Clean up PROJ mess

[Nicklas Larsson via macports-dev]

I have now put up a PR [1] to address this PROJ issue. The changes I propose to 
make are in summary:

- rename current `proj` to `proj5` (and update the few of its dependencies)
- collect all proj[N] ports to one Portfile `proj`
- create a new stub port `proj` which will serve as alias for the latest 
version (presently proj9) and to which the others are subports of

This will hopefully lead to less repetitive code and easier maintenance. Ports 
that support the latest version of PROJ can be cleaned up of the cascade of 
proj[N] variants currently  common, in only adding `proj` as a dependant.

Nicklas


[1] https://github.com/macports/macports-ports/pull/23462



> On 9 Sep 2023, at 09:43, Sergey Fedorov  wrote:
> 
> 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  > 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 > > 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 >>> > 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 >>> > 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  > 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 
>> > > 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:
>>> 
>>> portversion
>>> ---
>>> proj4   4.9.3
>>> 

Re: Clean up PROJ mess

[Sergey Fedorov]

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  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 
> 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  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  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 
>>> 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@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:
>
> portversion
> ---
> proj4   4.9.3
> proj5.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:
>
> portversion
> ---
> proj4   4.9.3
> proj5   5.2.0
> proj6   6.3.2
> proj7   7.2.1
> proj8   8.2.1
> proj9.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:
>
> portversion
> ---
> proj4   4.9.3
> proj5   5.2.0
> proj6   6.3.2
> proj7   7.2.1
> proj8   8.2.1
> proj9   9.2.1
> proj10.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 

Re: Clean up PROJ mess

[Dave Allured - NOAA Affiliate via macports-dev]

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  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  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  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 
>> 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@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:

 portversion
 ---
 proj4   4.9.3
 proj5.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:

 portversion
 ---
 proj4   4.9.3
 proj5   5.2.0
 proj6   6.3.2
 proj7   7.2.1
 proj8   8.2.1
 proj9.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:

 portversion
 ---
 proj4   4.9.3
 proj5   5.2.0
 proj6   6.3.2
 proj7   7.2.1
 proj8   8.2.1
 proj9   9.2.1
 proj10.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  

Re: Clean up PROJ mess

[Nicklas Larsson via macports-dev]

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  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 
> mailto:macports-dev@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  > 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 
> mailto:macports-dev@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:
> 
> portversion
> ---
> proj4   4.9.3
> proj5.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:
> 
> portversion
> ---
> proj4   4.9.3
> proj5   5.2.0
> proj6   6.3.2
> proj7   7.2.1
> proj8   8.2.1
> proj9.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:
> 
> portversion
> ---
> proj4   4.9.3
> proj5   5.2.0
> proj6   6.3.2
> proj7   7.2.1
> proj8   8.2.1
> proj9   9.2.1
> proj10.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/spatialiteport:proj[6-9]
> gis/gdalport:proj[6-9]
> gis/grass   port:proj[6-9]
> gis/grass7  port:proj[6-9]
> gis/liblas  port:proj[6-9]
> 

Re: Clean up PROJ mess

[Sergey Fedorov]

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  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  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@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:
>>>
>>> portversion
>>> ---
>>> proj4   4.9.3
>>> proj5.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:
>>>
>>> portversion
>>> ---
>>> proj4   4.9.3
>>> proj5   5.2.0
>>> proj6   6.3.2
>>> proj7   7.2.1
>>> proj8   8.2.1
>>> proj9.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:
>>>
>>> portversion
>>> ---
>>> proj4   4.9.3
>>> proj5   5.2.0
>>> proj6   6.3.2
>>> proj7   7.2.1
>>> proj8   8.2.1
>>> proj9   9.2.1
>>> proj10.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/spatialiteport:proj[6-9]
>>> gis/gdalport: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_tileport:proj4
>>> gis/osm2pgsql   port:proj8
>>> gis/qgis3   port:proj[6-9]
>>> gis/qlandkarte  port:proj4
>>> gis/qlandkartegtport:proj[4-7]
>>> gis/sagaport:proj8
>>> graphics/libgeotiff port:proj[7-9]
>>> octave/octave-octproj

Re: Clean up PROJ mess

[Marius Schamschula]

octave/octave-octproj works with proj >= 6.3.0

I just haven’t updated the Portfile to version 9.x, as there haven’t been any 
upstream changes in a while.

> On Jun 8, 2023, at 2:54 PM, Nicklas Larsson via macports-dev 
>  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:
> 
> portversion
> ---
> proj4   4.9.3
> proj5.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:
> 
> portversion
> ---
> proj4   4.9.3
> proj5   5.2.0
> proj6   6.3.2
> proj7   7.2.1
> proj8   8.2.1
> proj9.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:
> 
> portversion
> ---
> proj4   4.9.3
> proj5   5.2.0
> proj6   6.3.2
> proj7   7.2.1
> proj8   8.2.1
> proj9   9.2.1
> proj10.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/spatialiteport:proj[6-9]
> gis/gdalport: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_tileport:proj4
> gis/osm2pgsql   port:proj8
> gis/qgis3   port:proj[6-9]
> gis/qlandkarte  port:proj4
> gis/qlandkartegtport:proj[4-7]
> gis/sagaport: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-pyprojport:proj8
> python/py-spatialiteport:proj4
> science/cdo port:proj8
> science/gerris  port:proj
> science/magicsppport:proj6
> science/metview port:proj6
> science/ncarg   port:proj
> science/relax3d port:proj7
> science/sumoport: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
> 

Marius
--
Marius Schamschula

Re: Clean up PROJ mess

[Dave Allured - NOAA Affiliate via macports-dev]

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  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@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:
>>
>> portversion
>> ---
>> proj4   4.9.3
>> proj5.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:
>>
>> portversion
>> ---
>> proj4   4.9.3
>> proj5   5.2.0
>> proj6   6.3.2
>> proj7   7.2.1
>> proj8   8.2.1
>> proj9.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:
>>
>> portversion
>> ---
>> proj4   4.9.3
>> proj5   5.2.0
>> proj6   6.3.2
>> proj7   7.2.1
>> proj8   8.2.1
>> proj9   9.2.1
>> proj10.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/spatialiteport:proj[6-9]
>> gis/gdalport: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_tileport:proj4
>> gis/osm2pgsql   port:proj8
>> gis/qgis3   port:proj[6-9]
>> gis/qlandkarte  port:proj4
>> gis/qlandkartegtport:proj[4-7]
>> gis/sagaport: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-pyprojport:proj8
>> python/py-spatialiteport:proj4
>> science/cdo port:proj8
>> science/gerris  port:proj
>> science/magicsppport:proj6
>> science/metview port:proj6
>> science/ncarg   port:proj
>> science/relax3d 

Re: Clean up PROJ mess

[Nils Breunese]

You could already create a proj9 port now and have proj depend on that. When 
version comes out you can add proj10 and change proj to depend on that instead 
of proj9. This way users can choose to install ‘proj latest’ or ‘proj 9’ 
explicitly, with the former getting updated as newer versions are released, and 
the latter just giving a user version 9.

Nils.

> Op 8 jun. 2023 om 21:54 heeft Nicklas Larsson via macports-dev 
>  het volgende geschreven:
> 
> 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:
> 
> portversion
> ---
> proj4   4.9.3
> proj5.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:
> 
> portversion
> ---
> proj4   4.9.3
> proj5   5.2.0
> proj6   6.3.2
> proj7   7.2.1
> proj8   8.2.1
> proj9.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:
> 
> portversion
> ---
> proj4   4.9.3
> proj5   5.2.0
> proj6   6.3.2
> proj7   7.2.1
> proj8   8.2.1
> proj9   9.2.1
> proj10.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/spatialiteport:proj[6-9]
> gis/gdalport: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_tileport:proj4
> gis/osm2pgsql   port:proj8
> gis/qgis3   port:proj[6-9]
> gis/qlandkarte  port:proj4
> gis/qlandkartegtport:proj[4-7]
> gis/sagaport: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-pyprojport:proj8
> python/py-spatialiteport:proj4
> science/cdo port:proj8
> science/gerris  port:proj
> science/magicsppport:proj6
> science/metview port:proj6
> science/ncarg   port:proj
> science/relax3d port:proj7
> science/sumoport: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
> 

Re: Clean up PROJ mess

[Sergey Fedorov]

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@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:
>
> portversion
> ---
> proj4   4.9.3
> proj5.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:
>
> portversion
> ---
> proj4   4.9.3
> proj5   5.2.0
> proj6   6.3.2
> proj7   7.2.1
> proj8   8.2.1
> proj9.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:
>
> portversion
> ---
> proj4   4.9.3
> proj5   5.2.0
> proj6   6.3.2
> proj7   7.2.1
> proj8   8.2.1
> proj9   9.2.1
> proj10.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/spatialiteport:proj[6-9]
> gis/gdalport: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_tileport:proj4
> gis/osm2pgsql   port:proj8
> gis/qgis3   port:proj[6-9]
> gis/qlandkarte  port:proj4
> gis/qlandkartegtport:proj[4-7]
> gis/sagaport: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-pyprojport:proj8
> python/py-spatialiteport:proj4
> science/cdo port:proj8
> science/gerris  port:proj
> science/magicsppport:proj6
> science/metview port:proj6
> science/ncarg   port:proj
> science/relax3d port:proj7
> science/sumoport: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
>
>