[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging Gradle



Hello,

Am Samstag, den 13.03.2021, 02:29 +0530 schrieb Raman Sarda:
> Dear all,
> I have a few queries.
> Is there a way we can go about updating gradle using some another way? I have
> worked on major part of the update last summer but seems we can't go any
> further without gradle enterprise plugin.
> I am trying to update gradle to 6.4.1 and it doesn't build kotlin-dsl plugin
> as of now. Gradle enterprise plugin (formerly buildscan) is needed for it
> which is proprietary.

I haven't followed all the discussions about the progress of introducing Kotlin
to Debian. This appears to be the major obstacle to maintain future Gradle
releases anyway. Where do we stand here?

It is obvious by now that Gradle is the most difficult to maintain build system
for the Debian Java ecosystem. I had a look at the Fedora packaging and it
seems they have already given up a few years ago? Really? How does Red Hat
build gradle packages now?

https://src.fedoraproject.org/rpms/gradle

If new releases of Gradle require proprietary plugins to function then we have
a serious problem, because the DFSG is very clear about that. At best gradle
could be shipped in non-free if the license of the proprietary plugin allows
redistribution. All reverse-dependencies of gradle could no longer be shipped
in Debian main and had to be moved to the contrib distribution. 

> I am working on it here. current progress about enterprise plugin is under
> enterprise-test branch.
> 
> There have been already tons and tons of patches to remove other parts which
> are missing in debian in a bid to atleast make core gradle work. These
> patches along with all the changes in upstream have made it almost impossible
> to upgrade Gradle in Debian. A better approach is needed in my opinion. A
> gradle installer which pulls latest gradle and installs it would be easiest
> way to go about. But then it won't come under standard Debian repositories. 

Ok, you have already noticed the implications yourself. Moving gradle to non-
free might seem as the easiest solution but many Java packages would no longer
be available in Debian main. 

In my opinion, before we talk about upgrading gradle in Debian, we should
finally package Kotlin. This appears to be the major blocker at the moment.
After that we could take smaller steps by upgrading only to gradle 5.x or any
minor version in between that makes it easier to maintain this build system. As
long as all packages can be built from source, this would be fine. Packaging
gradle probably will never be perfect. 

While working on that we should identify the major blockers of maintaining
future gradle versions and voice our concerns about the non-free components in
gradle with the upstream developers. If there is a point when it becomes
impossible to package gradle for Debian main because of the licensing and
upstream refuses to change the license, then we have no choice and need to move
the package to non-free. Otherwise we also can try to strip away those
components, if technically possible, and try to maintain a core gradle package
that just works for our main purpose of building packages from source.

We also have the option to use a custom build system, just using Ant or Maven
instead of Gradle for affected packages. Of course this requires additional
developer time and the question is, would it really help us in the long-term?


> I created a upstream issue to discuss the enterprise plugin situation #16439
> They mentioned that it is possible but didn't mention how yet.
> I also created a upstream issue to discuss better ways of packaging Gradle.
> #16512
> We can discuss this here on mailing list or IRC or salsa to find a way to go
> forward with this. 

Good start. Let's discuss this on this mailing list which is easier to follow
than IRC.

Regards,

Markus

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: