Bug#1125161: Re-bootstrapping sbt and modern Scala; the Scala 3 path is now open

[Emmanuel Bourg]

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