XPost: linux.debian.bugs.dist

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)