Re: gradle reboot -- 2024W49 update

Le 2024-12-09 14:32, Emmanuel Bourg a écrit :
> 
> I don't think we should try too hard to keep the bootstrapping logic in 
> the package, that'll most certainly be tedious to maintain over time.

Well that's indeed something to think about, and I am a bit worried 
about that as well. With Gradle, the work necessary to maintain the 
bootstrapping in working condition will have to be weighted against the 
work necessary to patch and downgrade the build scripts to make them 
work with a previous release, which may or may not be that easy 
depending on feature gaps between Gradle releases.

Gradle authors made it pretty clear that they actively upgrade Gradle 
build scripts to use the latest features available (aka "dogfooding"). 
Even if Debian maintainers managed to ship every Gradle final release, 
new majors releases were so far never built with a final release, but 
rather pre-releases or snapshots of the new major release [1]. This also 
happens for minor releases, though changes in build scripts are less 
drastic and some minor releases are probably (untested so far but worth 
testing) going to build with some previous releases.

AFAIK the current Debian Policy doesn't say much about bootstrapping 
build tools i.e. which exceptions to the usual rules might be admissible 
or not in these cases. Fedora provides some guidelines [2] [3] that seem 
reasonable. My personal opinion is that making such tools bootstrappable 
would be a good practice, but that it's ultimately the job of the 
upstream developers to provide the means to bootstrap their products. It 
has always been (AFAIK) possible to build GNU Make without GNU Make. 
Their authors now make it possible to build GNU Make without any "make" 
at all [4]. It is almost possible to build SBT without SBT [5]. 
Unfortunately the feedback we've got from Gradle leads so far is that 
they don't care much about that issue.

But I would leave it to the maintainer of the day to decide whether they 
want to maintain the bootstrapping in working condition or not. I 
promise not to bark and bite if they don't ^ ^. Though I think that even 
if the tool breaks at some point, keeping the parts around in the 
toolbox just in case they are needed again later would be wise.

That said, I'm actually marginally outdoing the Gradle folks with my 
approach as I assume that any release will be buildable by the same 
release, which may not always be true, and I would not be surprised if 
Gradle authors stated at some point that it is not among their goals, 
but it's much more convenient to assume that and I believe that this is 
going to work most of the time with no (or little) changes.


[1]: https://salsa.debian.org/-/snippets/756
[2]: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#_exceptions
[3]: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
[4]: https://git.savannah.gnu.org/cgit/make.git/tree/bootstrap
[5]: 
https://github.com/sbt/sbt/blob/1.10.x/DEVELOPING.md#running-sbt-from-source---sbton
      — spoiler, as the wishlist season is officially opened: I added 
"package SBT" on my to-do list for 2025.