Re: kotlin2 in Debian -- 2025W23 update
- To: debian-java@lists.debian.org
- Subject: Re: kotlin2 in Debian -- 2025W23 update
- From: Julien Plissonneau Duquène <sre4ever@free.fr>
- Date: Fri, 20 Jun 2025 21:22:05 +0200
- Message-id: <[🔎] 5f7282727a94df9d515283577fd2adeb@free.fr>
- In-reply-to: <[🔎] 9e91fff3-bd04-7109-897e-47f112fecd76@apache.org>
- References: <c447006d-7f97-72ec-1980-2425466a196b@free.fr> <2e2ac5f7efc8ae401863382517249ce9@free.fr> <fd7bed1065756d6755c922929c201585@free.fr> <7e2a9e1b7fda03ad83d664582fb89c8d@free.fr> <ce6d7fbffa95bc534b1fc569e4471cab@free.fr> <5650baeeec5223dfb5affa4aa42f1b56@free.fr> <fab2fe12-991d-4fd3-a17f-28483bae3cf9@debian.org> <7053663db379b063042e99eb31bdadcd@free.fr> <80615ea609e5fab28e354a494d83e59d@free.fr> <572b182be1c0f0e013ce95cbf563f223@free.fr> <ac7cff49d09a4ee5e48254d7aabcbc00@free.fr> <7a6e787cb9984825628a1a365ac6e8a3@free.fr> <c0add46a68772eb1de3e916d23ca6f86@free.fr> <07f185f4d07c5acd3e458b01e354be41@free.fr> <3ebae8b9869459ef719d6366190fa5f0@free.fr> <e7d2987d54f803a4ae8bb889e0a13ac1@free.fr> <c88ba99ac7ce198a5368270f80ea65de@free.fr> <e84f052b22a3d8ee3703f17480a09f28@free.fr> <3570bd5d462de5034469dccd60a9130b@free.fr> <ccd77a2e7c35c5685c2ab3c3edf7b093@free.fr> <a8d2bf91eea2a1a37a09a7abf0119ef2@free.fr> <[🔎] d35b5df36bd8faa3afef0534017a9af9@free.fr> <[🔎] 9e91fff3-bd04-7109-897e-47f112fecd76@apache.org>
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: