I was playing around just now, trying to create a tarball using
release.py. Found an amazing bug that can in the right circumstances
create the tarball using the wrong libtool.
* release.py installs, and then requires presence of, a program called
'libtool'. ✅
* It checks the libtool version before calling autogen.sh. ✅
* It will not consider any programs called 'glibtool'. ❓
* autogen.sh looks for 'glibtool' on the path before 'libtool'. ❌
If I have a different 'glibtool' on the path than the carefully
installed 'libtool', autogen.sh will use the wrong one. It prints the
version number, but that's likely to be missed.
Seems to me that release.py should look for the external tools with the
same names in the same order as autogen.sh.
Or, to go a step further: the RM process, especially the part about
creating the tarball, is sensitive to the RM's environment. How about
instead we create a container image [1] that will have exactly the right
dependencies and no others installed, and make at least the tarball
generation step more stable and repeatable and independent of the OS the
RM happens to be using.
I can have a go at that. It might not be ready for 1.15 but IMO it's a
step we should take.
-- Brane
[1] Not "docker image" :) I moved from Docker first to Podman and now to
Colima with a docker client CLI and I haven't looked back.