Path: csiph.com!news.samoylyk.net!gothmog.csi.it!bofh.it!news.nic.it!robomod From: Hans-Christoph Steiner Newsgroups: linux.debian.maint.java Subject: Re: gradle reboot -- 2024W49 update Date: Mon, 09 Dec 2024 19:20:01 +0100 Message-ID: References: X-Mailbox-Line: From debian-java-request@lists.debian.org Mon Dec 9 18:17:42 2024 Old-Return-Path: X-Amavis-Spam-Status: No, score=-6.298 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, BODY_8BITS=1.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, LDO_WHITELIST=-5, MURPHY_SCAM1=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001] autolearn=ham autolearn_force=no X-Policyd-Weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 CL_IP_EQ_HELO_IP=-2 (check from: .at. - helo: .fout-a3-smtp.messagingengine. - helo-domain: .messagingengine.) FROM/MX_MATCHES_HELO(DOMAIN)=-2; rate: -5.5 X-Me-Sender: X-Me-Received: X-Me-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrjeeigdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuf fvfhfhohgjtgfgsehtkeertddtvdejnecuhfhrohhmpefjrghnshdqvehhrhhishhtohhp hhcuufhtvghinhgvrhcuoehhrghnshesrghtrdhorhdrrghtqeenucggtffrrghtthgvrh hnpedutdffleekhfelhfefudfhffdvffeihfdvvdeiheeuheefgeekgeeigefhveekheen ucffohhmrghinhepuggvsghirghnrdhorhhgpdhfvgguohhrrghprhhojhgvtghtrdhorh hgpdhgnhhurdhorhhgpdhgihhthhhusgdrtghomhdpuggvvhgvlhhophhinhhgrdhmugen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehhrghnsh esrghtrdhorhdrrghtpdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuthdp rhgtphhtthhopeguvggsihgrnhdqjhgrvhgrsehlihhsthhsrdguvggsihgrnhdrohhrgh X-Me-Proxy: Feedback-ID: i264a41e9:Fastmail MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US Organization: @||@ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailing-List: archive/latest/23558 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/6466d8e8-7ff0-4289-8e49-376f110f8d4a@at.or.at Approved: robomod@news.nic.it Lines: 64 Sender: robomod@news.nic.it X-Original-Date: Mon, 9 Dec 2024 19:17:15 +0100 X-Original-Message-ID: <6466d8e8-7ff0-4289-8e49-376f110f8d4a@at.or.at> X-Original-References: <5284bacb294ba1ff08f32a5a0b175dd4@free.fr> <8497785db64c2691266dc8269486d7c2@free.fr> <2c092ca6-5614-0eed-ea71-a1ffbb82cc2d@apache.org> <2db594d17e58f30adcba8b06a2fe0415@free.fr> Xref: csiph.com linux.debian.maint.java:12851 sre4ever@free.fr: > 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. I also think that your bootstrapping plan sounds good. And I second that I don't think it is so important to maintain the bootstrapping Makefile. It'll always be in git for anyone who wants to go back to it. 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. .hc