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,
--
Julien Plissonneau Duquène
