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.