hardcodes versioned GISBASE path on Alpine

Out of curiosity: why is $(grass --config path) no longer usable?

GDAL-GRASS plugin now works on Alpine too:

Testing the GDAL-GRASS plugins:
  GRASS -raster- (ro): GRASS Rasters (7+)
  OGR_GRASS -vector- (ro): GRASS Vectors (5.7+)

hardcodes versioned GISBASE path on Alpine

Out of curiosity: why is $(grass --config path) no longer usable?

I'm not absolutely sure, but I doubt it ever worked – only there were no tests before.

I think at this point grass --config path gave the un-versioned path:

... after:

There is still a test failure on Alpine, which is unrelated and out-of-scope for this PR, where running:

https://github.com/OSGeo/grass/blob/main/docker/testdata/test_grass_session.py

...fails.

#27 2.786 Traceback (most recent call last):
#27 2.786   File "/scripts/test_grass_session.py", line 9, in <module>
#27 2.786     gs.create_project(project, epsg="25832")
#27 2.786   File "/usr/local/grass/etc/python/grass/script/core.py", line 1817, in create_project
#27 2.786     ps = pipe_command(
#27 2.787          ^^^^^^^^^^^^^
#27 2.787   File "/usr/local/grass/etc/python/grass/script/core.py", line 516, in pipe_command
#27 2.787     return start_command(*args, **kwargs)
#27 2.787            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#27 2.787   File "/usr/local/grass/etc/python/grass/script/core.py", line 437, in start_command
#27 2.788     return Popen(args, **popts)
#27 2.788            ^^^^^^^^^^^^^^^^^^^^
#27 2.788   File "/usr/local/grass/etc/python/grass/script/core.py", line 84, in __init__
#27 2.788     subprocess.Popen.__init__(self, args, **kwargs)
#27 2.788   File "/usr/lib/python3.12/subprocess.py", line 1028, in __init__
#27 2.788     self._execute_child(args, executable, preexec_fn, close_fds,
#27 2.788   File "/usr/lib/python3.12/subprocess.py", line 1963, in _execute_child
#27 2.789     raise child_exception_type(errno_num, err_msg, err_filename)
#27 2.789 FileNotFoundError: [Errno 2] No such file or directory: 'g.proj'

(Adding proj-dev was not the solution for that, more likely related to PATH).

These series of attempts to fix this should be manually (in merged form) back ported to 8.4 after 8.4.1 is released.

I tried out locally the images yesterday, and was surprised by some errors. Just running with

docker run -it osgeo/grass:main-debian

And gives an error that something isn't it path. I researched a bit and it's related to not having an entry point defined.
I tried older 8.4.0 releases, and the other flavors.
I compared with actinia images, and that last one started right away.

I initially thought it because I had just enabled the containerd image store, but after reverting that (and confirming it worked as before), grass images had the same behavior

... after:

grass/docker/alpine/Dockerfile

Line 198 in 33f29c1

ENV GISBASE /usr/local/grass

That variable GISBASE probably should not be set. The grass command should know that by itself. If the variable is set is and is wrong, the command gets confused. Maybe the script should ignore it.

... after:

grass/docker/alpine/Dockerfile

Line 198 in 33f29c1

ENV GISBASE /usr/local/grass

That variable GISBASE probably should not be set. The grass command should know that by itself. If the variable is set is and is wrong, the command gets confused. Maybe the script should ignore it.

With a symlink in place (from un-versioned GISBASE to versioned), which with this change fixes, it should work without setting GISBASE. I guess the need for setting it from the beginning, was that the setting of symlink didn't work out as expected.