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

Re: kotlin2 in Debian -- 2025W23 update



Hi Emmanuel,

Le 2025-06-16 15:45, Emmanuel Bourg a écrit :
On 07/06/2025 19:14, Julien Plissonneau Duquène wrote:

A significant difference with the current Kotlin package is that I'm planning to remove (if possible) all embedded copies of libraries. This will require to patch some of them that were forked by JetBrains to fix or add features.

I'm not sure this is a good idea, because it diverges from upstream, increases the maintenance burden, and could potentially break kotlin if such a dependency gets broken and can no longer compile (due to kotlin being broken). For kotlin I'd recommend keeping it simple and sticking to the upstream layout as much as possible. Saving a few kilobytes isn't important here.

I think it would actually be easier terms of maintenance, space savings are definitely not the reason behind that move. I would worry more about the risks of breaking a shared dependency used elsewhere by patching it for kotlin.

The alternatives here are to either embed the dependencies in the kotlin package (which is the way it's currently done), or package the JetBrains forks separately.

Embedding the dependencies means that the compiler package has to be rebuilt at least twice after patching a dependency: a first time to build an updated package with the old package, then a second time to rebuild the compiler with a compiler that uses the updated dependency. And if there is kotlin-specific patching involved of that dependency, the source package would become multi-tarball again. All these make the package maintenance more complicated and brittle, e.g. if someone else updates an embedded dependency package but forgets to (test-)rebuild the compiler twice afterwards, it might fail to build later at an inconvenient time.

Packaging the JetBrains forks separately avoids the issues above, but still adds to maintenance burden as now the forked package has to be maintained in addition to the mainstream package. In most cases the duplication would make no sense IMO. I will consider it though if there is no reasonable way to make the regular dependency package useable with kotlin (by patching either the dependency and/or kotlin).

Diverging from upstream is not ideal, but there is such a gap in policies and goals between the binary releases from the upstream projects and Debian that it is completely unavoidable anyway. In several cases, upstream depends on older releases of libraries than those shipped in Debian, probably because they have to provide commercial support on older releases of IDE and tools. My plan is to use the upstream test suites to detect and mitigate issues that could be introduced by Debian divergences, and keep these to a minimum where it actually matters.

--
Julien Plissonneau Duquène


Reply to: