GDAL: deprecate 2.X

[adamjstewart]

This PR deprecates all GDAL 2.X versions. GDAL 3.X was released over 3 years ago, and most packages have been ported to support GDAL 3.X by now.

Motivation

GDAL's build system keeps changing. GDAL 2.X only has configure options to help find dependencies, so our variants are named after those dependencies. GDAL 3.X added configure options to enable/disable specific raster and vector drivers. In my opinion, this is much more intuitive, and I would like to change all of our variants to match the driver names, not the dependency names. GDAL 3.5 (released today) adds a CMake build system, and 3.6 will remove the current Autotools build system, adding more complexity to our build recipe. This PR is an attempt to reduce the number of versions of GDAL we (i.e. I) have to support and keep the recipe maintainable.

Future

I'm hoping to get this PR into Spack 0.18 (coming next week), then immediately remove GDAL 2.X and rename all of our variants on develop. This is a pretty disruptive change. I wish there were a better way to support this. Maybe @alalazo has some ideas? @tgamblin this pertains to our discussion about version deprecation and removal.

Pinging some folks who have contributed to our GDAL recipe in the past: @Sinan81 @snehring @haralmha @rouault @amaji @payerle @michaelkuhn @iarspider @neilflood

Will anyone (or any packages) be negatively impacted by removing these versions? What about removing GDAL 3.0:3.4? Here's what I found from our recipes:

• gplates: requires GDAL 1 (gplates: add v2.3.0 #30676)
• grass+gdal: requires GDAL 3.2 and older
• ncl+gdal: requires GDAL 2 and older
• py-rasterio: requires GDAL 3.3 and older

We'll likely have to keep 3.0:3.4 around for now, as I'm heavily dependent on py-rasterio. If anyone wants to continue to support GDAL 2, I might ask you to become an official "maintainer" of our build recipe, because I'm no longer able to test GDAL 2.

[adamjstewart]

@tgamblin assures me that @alalazo's new multi-build system support will make this much easier, so this deprecation may not be strictly necessary, but it's something I wanted to at least point out as a complicated use case where we might want 3 separate classes:

• gdal@3.5: - cmake build system, driver variants
• gdal@3.0:3.4' - autotools build system, driver variants
• gdal@:2' - autotools build system, dependency variants

We could also use driver variants for GDAL 2.X and hope for the best since there's no way to explicitly enable/disable them...

[snehring]

A quick survey of our environment shows we've got a few versions of gdal 2.x installed but I suspect that's just left over from legacy installs at this point.

As far as dependents go, our users use r-rgdal a fair amount, which seems fine with 3.x per the recipe and documentation.

I'm fine with deprecating them and dealing with any (likely none in our env) fallout.

[Sinan81]

🤔

[Sinan81]

I am generally in favor of providing backwards compatibility to the extent that it's practical or with the understanding that users won't get support from maintainers for non-trivial issues. Hence, it would be great to provide support for multiple builds systems. Or could one use a provider set-up so that let's say gdal-legacy package would provide older versions with autotools while gdal package would do so for newer (with cmake).

[Sinan81]

I recently encountered a similar problem whiling building gtk, and I basically renamed older package as gtk-legacy so that I could build older versions with autotool build as opposed to meson.

[Sinan81]

Of course the change from dependency variants to driver variants complicates the situation.

[Sinan81]

Also, could we use a version dependent dependency to handle this situation. For example:

def Mypackage(...):
    depends('gdal-legacy +dependency_opt', when('@...'))
    depends('gdal +driver_opt', when('@...')

[adamjstewart]

Yes, multi-build system support works fine (https://spack.readthedocs.io/en/latest/build_systems/multiplepackage.html), and @alalazo is working on making it even better (#30411). But you can't have separate classes for these at the moment, so having separate variants for different versions is cumbersome and requires a lot of nested with when(). So this PR deprecates older versions so I can focus on the build system differences only.

[iarspider]

@adamjstewart I'm fine with dropping 2.x - CMS doesn't even use gdal. Pinging @haralmha (SFT) and @vvolkl (Key4HEP)

[haralmha]

I am also fine with dropping 2.x. We use newer versions in the LCG stack

[alalazo]

@adamjstewart Feel free to go ahead merging when you think it is ok to do so based on people responses

[adamjstewart]

Will merge just to ensure that this makes it into 0.18, but if anyone has any problems with this after I merge, let me know and I can always revert. Hopefully #30411 will make this kind of thing easier in the future. Also see #30676.

[Sinan81]

I guess I am fine with dropping 2.x too.