Re: gradle reboot -- 2024W49 update

Le 2024-12-09 19:17, Hans-Christoph Steiner a écrit :
>  I think it would be fine to keep in place, as long as the workflow is 
> documented, e.g. the bootstrapping is not required to be maintained, 
> but it would be nice to have.

It's probably not as complicated to maintain as it may look right now, 
let me give some details about how I see future maintainer work wrt/ 
this.

The makefile is automatically generated  by a new "makeMakefile" gradle 
task that is added by the custom plugin. My goal is to make it work as 
generated with no further postprocessing, especially no manual editing. 
It is only intended to (re)build the version of Gradle from which is was 
generated, as a fallback method for a first stage build if the Gradle 
currently installed on the system is not usable for the build. IOW it's 
there to prevent some FTBFS cases.

When importing a new Gradle release:
- either the build succeeds out of the box with the version of Gradle 
currently installed on the system. In that case the Makefile will be 
automatically updated as part of a manual build of the package (the task 
would be skipped by default if the makefile version matches the package 
version). The maintainer only has to commit it as part of packaging 
updates.
- or the system Gradle fails to build the new release. In that case the 
maintainer has basically two choices: either downgrade the build scripts 
to make them work with the system Gradle, and then they are back to the 
same situation as above, or go through the bootstrap process again, and 
in that case a new Makefile will be generated and used as part of the 
bootstrap process.

Of course all of this is going to be documented, and I'm also planning 
to automate the bootstrap process (download the binary dist and 
dependencies, setup a temporary installation, first stage builds etc).

Testing that the Makefile fallback actually works could be done by the 
maintainer, but I think it would be more convenient to delegate that to 
some custom CI pipeline on Salsa that is allowed to fail so the 
maintainer won't be blocked to proceed with an upgrade if that's the 
only thing that breaks.

And if that's the makeMakefile task that breaks, which I think is less 
likely than future issues with the rest of the custom build logic, they 
can just comment out the bits in debian/rules if they don't want to fix 
it.

Cheers,