Hi Simon, On 06/05/2025 16:24, Simon Josefsson wrote:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104784
Nice catch. That's an interesting failure mode, probably another one that was not completely anticipated by sponsors of /bin -> /usr/bin directory aliasing, and it's likely to affect a number of projects using wrapper scripts.
This is indeed a bug in the gradle package. My own build scripts are always calling /usr/bin/gradle explicitly so they would not be impacted, but it's definitely worth fixing as there is currently no easy way to do that with debhelper's gradle buildsystem.
FTR, from the point of view of the upstream project Gradle isn't supposed to be invoked with a command found through the PATH, and isn't even supposed to be installed at a known place on any system. The canonical way to use it is to run ./gradlew from the root of the project you want to build (that is supposed to have a few bootstrap binaries checked in along the project) and then let the thing happily download the whole Internet to get the specific Gradle release(s), JDK(s) and all the dependencies needed to build, run and test the project.
As official Debian packages can obviously not be built this way for multiple good reasons, a package-specific default location is hardcoded into the packaged Gradle so it can use that as a last resort to find its installation root when the relative path guesses fail. We want to keep the relative path mechanism as it's convenient for testing and using multiple versions on a system.
There are packages that invoke Gradle during package builds that will FTBFS until that bug is fixed.
Part of the issue is that the debhelper gradle class currently needs gradle to be in the PATH and lacks a way to pass a different launcher path. I'm also planning to fix that later.
Thank you for reporting this. Cheers, -- Julien Plissonneau Duquène
