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.

Reply via email to