Re: Clean up PROJ mess
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
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 > >
Clean up PROJ mess
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
