Le 11/06/2026 à 11:12, Juan M. Méndez Rey a écrit :
There are also packages depending on Scala 2.11: plm, pilon, latexdraw, htsjdk,
unicycler: they would need to be ported to 2.13 o r think about retiring them
if we would remove 2.11.
I got a quick look:
- PLM is still on Scala 2.11
- Pilon moved to Scala 2.13 5 years ago
- Latexdraw 4.0 dropped Scala
- HTSJDK also dropped Scala
(https://github.com/samtools/htsjdk/commit/9f0e80f5), but there are
still 4 Scala tests, probably based on Scala 2.12
- Unicycler depends on Scala indirectly through Pilon, but the
dependency was removed 4 years ago
Regarding versioned scala-x.y vs upgrading scala: versioned, for the
compatibility reason you raise. Scala is binary compatible within a minor (any
2.13.x library works on any 2.13.x) but not across minors, so every library is
cross-compiled per series: e.g.: upstream encodes it in the name (foo_2.12,
foo_2.13, foo_3). We can mirror default-jdk: real scala-2.12/scala-2.13/scala3
plus a thin scala metapackage. scala-2.12 already exists in that shape; Scala 3
is stable across 3.x and reuses the 2.13 library, so it slots in.
Ok, so we'd need:
- scala (2.11): kept for PLM only. Once PLM is updated, the scala
package becomes a meta package pointing to the latest version. We may
also rename it scala-2.11 right now for clarity.
- scala-2.12: required at least for sbt until version 2.0
- scala-2.13: required for building and running Scala 3, Apache Spark
- scala-3.8: last Scala version using the 2.13 libraries
- scala-3.9: will no longer depend on Scala 2.13?
I don't mind having multiple versions of Scala in Debian, that's still
better than a 10 year old version and there is hope the ecosystem
eventually converges toward a couple of versions (2.13 and 3.x). But
does that mean we'll need as many variants of the libraries (such as
scala-asm or scala-xml)?
Emmanuel Bourg
