[gdal-dev] Moving GDAL GRASS driver in a dedicated repository ?

[Sebastiaan Couwenberg]

On 3/22/22 19:41, Even Rouault wrote:
> bumping again this topic, after feedback just received on 3.5.0alpha1.
> 
> For now, I'm heading to completely disable CMake build support for the 
> GRASS drivers in https://github.com/OSGeo/gdal/pull/5490 . Only the 
> existing autoconf scripts that are provided with the plugin (if they 
> work ?) will be usable.

The libgdal-grass Debian package uses the autoconf bits.

> As noted in my comments, CMake build support could potentially be 
> re-enabled, but just allowed the driver to be built as a plugin, and not 
> built-in in GDAL core lib. However that would still do a full GDAL 
> build, not just the driver, so this is perhaps not so useful (a CMake 
> build for the driver would just use an already built GDAL and use 
> find_package(GDAL) )
> 
> It would be good if someone could step up as the maintainer of the 
> driver in-tree, or in an external repository. Otherwise we might just 
> end up giving it the treatment of other drivers that lack attention from 
> a maintainer, ie rm -rf .

According to the wiki Markus and Markus are the maintainers of the GRASS 
driver:

  https://github.com/OSGeo/gdal/wiki/Maintainers-per-sub-system

With GRASS using non-standard library directories it doesn't work that 
well as recently discussed on grass-dev:

  https://lists.osgeo.org/pipermail/grass-dev/2022-February/095596.html

Removing the driver upstream and the libgdal-grass package from Debian 
would make my life easier, so no objection from me.

Kind Regards,

Bas

-- 
  GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1