On Mon, May 18, 2026 at 10:27 PM Branko Čibej <[email protected]> wrote:
> 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. > Wow! Good catch! Seems to me that release.py should look for the external tools with the > same names in the same order as autogen.sh. > That sounds like a good starting point. And since these will need to stay synchronized, until there's a better solution, probably they should both have a comment in the appropriate place to remind anyone fiddling with either one to make the same change in both. 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. > These *are* docker and a little dated, but could be an interesting starting point: https://github.com/markphip/svnrm https://github.com/cmpilato/subversion-dist Cheers, Nathan
