[gdal-dev] Docker - was Re: Motion: remove and deprecate a few drivers

[Andrew C Aitchison]

On Thu, 4 Mar 2021, Robert Coup wrote:

> On Thu, 4 Mar 2021 at 08:59, Andrew C Aitchison <andrew at aitchison.me.uk>
> wrote:
>
>> On Thu, 4 Mar 2021, Javier Jimenez Shaw wrote:
>>
>>> (using a docker image to convert any of those removed formats if you
>>> find a file at the bottom of you cellar in the far future is a great
>>> alternative.
>>
>> I don't have a lot of confidence in being able to run an old docker image
>> in the far future, especially if I don't have an x86 machine to run it on.
>>
>> https://medium.com/nttlabs/buildx-multiarch-2c6c2df00ca2
>> suggests that docker images should be built "multi-arch"
>> so that they run on x86 and the new ARM-based Apple Macs.
>> Who is going to rebuild and host the current GDAL docker like this?

> Your question comes across as entitled

I am sorry if it came across like that.

The rest of this post is probably off topic, so private replies may be best.

> the answer is: whoever cares
> enough to either do the work or pay someone to do it.
>
> The source code is there, the release archives are staying, and it will be
> possible to build an old release in the future which can read & convert a
> file they find. Docker images provide a great *shortcut*, which means if
> you find a file you can trivially convert it *without* building GDAL. I'm
> sure eventually GDAL will produce multi-arch docker images, but that
> shouldn't be a prerequisite for this deprecation/removal.

If someone builds a docker image with gdal including support for the formats
that are about to go away,
and you have hardware that runs that image when you need the conversion,
then docker is great.

If, in five, ten, fifteen or even twenty five years, I don't have
hardware that can run an existing docker image, then I'm less sure that
docker is the answer. Will I have to rely on someone having made that
Apple-ARM docker image of GDAL 3.2.2 back in 2021 ?

Why do I not think docker will be the answer ?
Experience suggests that I am likely to have more success building ancient
gdal on a current machine than building a docker image of that gdal that runs
on the current machine.
I suppose that a pre-existing ancient docker image with compilers should
allow me to build ancient gdal inside the container running on the current
machine ...

> Debian 1.1 386 floppy disk images from 1996 are still available, and if you
> have a m68000, sparc, a s390 or something else long-gone you can easily
> find historic Linux release images with compilers which will happily run.
> x86 will not disappear quickly, today's Linux kernel releases continue to
> support 486s and they were discontinued over 13 years ago. GDALs source
> code is also held in the Arctic Code Vault and other archival libraries
> <https://archiveprogram.github.com/> - it's not going to disappear 
> any time soon.

I had forgotten that the Linux kernel still supported 486.
Red Hat dropped support for 686 hardware with RHEL7 (released 2014)
- although 32bit binaries will still run on RHEL7 and RHEL8
according to https://access.redhat.com/solutions/509373
(personally, I never managed to build 32bit libraries on 64bit RHEL6).

But none of those images are likely to help me run software they contain
on next year's MacBook - though the Debian 1.1 image may run on an
x86_64 RHEL 8 machine.

-- 
Andrew C. Aitchison					Kendal, UK
 			andrew at aitchison.me.uk