I understand there may be blockers, but I would like to at least document the situation for the next person who wonders "Why isn't scala 3 in Debian". - -- System Information: Debian Release: forky/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.17.9+deb14-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages scala depends on: ii default-jre-headless [java7-runtime-headless] 2:1.21-76 pn libjline2-java <none> ii openjdk-17-jre-headless [java7-runtime-headless] 17.0.15+6-1 ii openjdk-21-jre-headless [java7-runtime-headless] 21.0.10~4ea-1 pn scala-library <none> pn scala-parser-combinators <none> pn scala-xml <none> scala recommends no packages. Versions of packages scala suggests: pn scala-doc <none> -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQS5beC2erx2PFqyC7XhcL+0NDTnAAUCaWF+jAAKCRDhcL+0NDTn AGD6AQCkTiHEN77qhroZJbmH8mU8fwmt4BMkoUJDZC/GS0OFVAD9EMdE/HnIloo8 1IZr1fl7VrkuMIuV6hgrGT0v3j4y3Ak= =kiil -----END PGP SIGNATURE-----
Hi, Nice to greet some of you again! I investigated this. This RFP points at a real gap: Scala 3, and the ecosystem on top of it (Apache Spark, Metals, Joern, Almond, ...) belongs in Debian, yet none of it is packageable today. Getting there first needs sbt and a modern Scala 2, and both were lost to the sbt<->scala bootstrap (sbt removed in 2023, scala frozen at 2.11 since 2017, I am on the side that thinks that this have hurt Scala ecosystem but it can be mended). I have broken that bootstrap. Scala 2.12.21 now builds from source with no sbt, from a minimal seed that is dropped after a self-host rebuild (following the rustc/GHC model). Seven packages build clean in sbuild: scala-asm, jline3, sbt-util-interface, sbt-compiler-interface, scala-2.12-bootstrap and scala-2.12 are all in my mendezr/* salsa namepace; This is the chain that opens the road for sbt -> Scala 2.13 -> Scala 3 is now open. I have filed those ITPs: sbt-util-interface #1139638, sbt-compiler-interface #1139639, scala-2.12-bootstrap #1139641 (this one, the binary seed, will need a bootstrap exemption, as rustc/GHC/OpenJDK have) and scala-2.12 #1139642. Providing here the MRs: https://salsa.debian.org/java-team/scala-asm/-/merge_requests/3 (coexistence with Scala 2.11 approach) https://salsa.debian.org/java-team/scala-asm/-/merge_requests/4 (the Scala 2.12 supersede approach, exclusive with the above) https://salsa.debian.org/java-team/jline3/-/merge_requests/3 New-package repos: https://salsa.debian.org/mendezr/sbt-util-interface https://salsa.debian.org/mendezr/sbt-util-interface https://salsa.debian.org/mendezr/sbt-compiler-interface https://salsa.debian.org/mendezr/scala-2.12-bootstrap https://salsa.debian.org/mendezr/scala-2.12 Looking for review, co-maintainers and a sponsor. Pierre, CC'ing you as the last scala uploader in case you are interested. Thanks, Juan Manuel Méndez Rey
Hi Juan, Thank you very much for working on Scala, I gave up years ago and I'm glad someone is picking up the ball. I see there is a choice about preserving the old version (2.11) or not. If you are confident packaging a new version of Scala is achievable, then I'd vote for retiring the old version. There is also a decision to make between upgrading the existing scala package, or switching to versioned scala-x.y packages (the existing scala package could then depend on the latest version, similarly to the default-jre package). The key factor here is backward compatibility, how stable is Scala nowadays? Do libraries still have to be rebuilt for new Scala versions? If so a versioned package might be more appropriate. Did you consider bootstrapping Scala 3 directly instead of starting from 2.12? Wouldn't that be easier? Emmanuel Bourg
El jueves, 11 de junio de 2026 a las 10:12, Emmanuel Bourg <ebourg@apache.org> escribió: Thanks Emmanuel, glad to be able to hear your opinions with this, that means a lot, and what I found probably is related with your experience. 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. That was my initial question too. Why not bootstrap 3 directly: But I found this: It doesn't avoid the work: sbt (which 2.13 and 3 both build with) is itself built with Scala 2.12, Scala 3's stdlib is the 2.13 library, and Dotty self-bootstraps from a prior Scala 3 too. Going straight to 3 would mean front-loading more prebuilt seeds (a 3 compiler + sbt + a 2.13 STARR), meaning a bigger exemption to defend in NEW, not a smaller one. The 2.12 seed is the smallest binary that unlocks the whole chain and drops out after self-host. I also factored in all the apps like Spark that still is getting users everywhere and that is in 2.12/2.13. My proposed plan then is: coexistence scala-asm (MR !3) + versioned toolchain now, retire 2.11 once its rdeps migrate. Although I see it is open to the team's preference on regard of the metapackage naming. Please, Let me know what you think, Juan
Le 11/06/2026 à 11:12, Juan M. Méndez Rey a écrit : - 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 - 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
Answering below El jueves, 11 de junio de 2026 a las 14:53, Emmanuel Bourg <ebourg@apache.org> escribió: PLM looks like the only last 2.11 contender. Ok, so we'd need: I like the idea. Seems like the correct way to do it and I will me amending the draft MRs shortly. As an Scala developer myself, I only care about 2.12, 2.13 and 3. And I believe we should force ourselves to be in 2.13 and 3 only. And with 2.13 the door is open for very cool packages of the scala ecosystem that are there. Things varies here, depending on which kind of package, so the multiplier is not as big. 1. Internal compiler dependencies: scala-asm, jline (they are pure java). They are a fixed number. - scala-asm 9 : it will work for scala 2.12, scala 2.13 - scala-asm 5 : it will work for scala 2.11 (already done in the MR!3 "coexistence branch" against java-team/scala-asm) (MR !4 is the alternative in-place bump to 9.9.0-only, for the day we retire 2.11.) - jline 2: It works for 2.11/2.12 - jline 3: It works for 2.13 2. Scala Libraries: scala-xml, scala-parser-combinators, scala-collection-compat . They need cross-compiling (2.13, 3) (2.11 already has his own ones, we dont need to touch it) For some cases scala 3 will be able to use scala2.13 ones, AFAIK, we may find cases where not. So, as a summary, and I believe that if a independent step could be taken before anything else, would be renaming scala to scala11, I prepared these two MRs: https://salsa.debian.org/java-team/scala/-/merge_requests/1 https://salsa.debian.org/java-team/plm/-/merge_requests/3 Emmanuel, I don't want to give you any burden, and I am committed to complete the process, just I need a volunteer for sponsoring the uploads (my NM process is still ongoing) and after the discussion when the team agrees on the approach. Leaving them here referenced in any case. Best, Juan
Hi David, Thanks for coming into discussion specially if it helps on simplifying the process! I had a look to the VirtusLab approach. So, please,let me see if what I gathered clarifies, then a question, because I think that option is not fully possible for the Debian approach. 1. The 3.9 library: noted, thanks. I'd been assuming "Scala 3 = the 2.13 stdlib", which holds to 3.8 but not 3.9's own _3 library. It only affects the future Scala 3 layer; but for 2.12/2.13 and its ecosystem are unchanged. 2. On "sbt + scala-cli bring the libraries": As far as I can see that works because they fetch deps from Maven Central via Coursier (https://scala-cli.virtuslab.org/docs/guides/introduction/dependencies/). The Debian archive build targets must not attempt network access, so I believe this path is not possible. If we were to package sbt/scala-cli that still needs every library packaged from source under /usr/share/maven-repo; that download model is exactly what would prevent VirtusLab's .debs out of the archive, hence why I suggested the approach proposed in this thread. Question: can you confirm the VirtusLab .debs work that way. Like, they rely on Coursier pulling dependencies at first use, rather than shipping them from the archive? Just want to be sure I'm describing them accurately. Best, Juan
I think that 3.8 also uses the scala_3 library. 3.8 was a kind of RC for 3.9 so they wanted to make the breaking changes first before jumping to what it an LTS release. SBT and Scala-CLI will always use the cached versions of the libraries it finds from Maven (or which ever repository you specify), and if you update the dependencies on your build file or script it will always go and fetch the new version from the repository. The cache lives in the user's directory, and I don't think there is a system wide cache that debian packages could populate. This also applies to the compiler and all its support libraries. So yes, the virtuslabs .debs do not try to package libraries, just the sbt and scalacli. Because that is the way the scala build system works. Packaging the compiler and the libraries is only of use if you want to run them manually, and no-one does that.
Hi David, Answering below El viernes, 12 de junio de 2026 a las 13:18, David Goodenough <david.goodenough@broadwellmanor.co.uk> escribió: Good to know, and good to remember when reach the scala 3 stage, thanks! - Your approach: Having sbt + scala-cli so a developer can use Scala on Debian, with Coursier fetching their dependencies on demand. That's a separate effort that can be pursued independently — and would be valuable in its own right. - My suggestion (and the RFP): package the compiler and libraries from source so they can be build-dependencies for other Debian packages — Scala applications like Spark, Metals, Joern, and the existing Scala rdeps. They need to build from source, offline, in the archive. None of those can enter Debian until the toolchain is there. So as a recap, tools and libraries: they serve different users (yours the developer, "mine" the Debian packages) and the two efforts don't block each other. That second goal is the one I'm after. Let me know if I got this correct, our you found any flaw. Best, Juan
Le 11/06/2026 à 17:01, Juan M. Méndez Rey a écrit : I got a look at PLM, and the changes required to compile with Scala 2.12 are modest. I've submitted a PR upstream: https://github.com/BuggleInc/PLM/pull/527 We have to be cautious with jline 3 and kotlin. For the Scala libraries, will we have one source package producing 2 or 3 binaries packages for each Scala version, or multiple source packages? I don't have much time, but if the path is clear I can help a bit with the uploads. Emmanuel Bourg
<david.goodenough@broadwellmanor.co.uk> escribió: The problem is that most Scala packages are built using sbt or mill, and nothing you can do (to my knowledge) will make sbt or mill ignore maven and use .deb installed libraries. Likewise with any scala-cli scripts. So unless you can solve the centralized cache problem and force all build systems to use it you are not going to be able to do it your way.
El viernes, 12 de junio de 2026 a las 15:18, Emmanuel Bourg <ebourg@apache.org> escribió: Nice one! So, going straight to the point. Cleanest order to start, no exemption needed: 1. scala-asm coexistence (5.2.0 for 2.11 + 9.9.0 for 2.12) No new binary names, so no NEW queue: https://salsa.debian.org/java-team/scala-asm/-/merge_requests/3 2. scala -> scala-2.11 rename (built + install tested locally, with a scala metapackage) https://salsa.debian.org/java-team/scala/-/merge_requests/1 2.1 plm, in the meanwhile, while your PR gets merged. plm switches Build-Depends to "scala-2.11 | scala" so it keeps getting 2.11 during and after the transition (NMU): https://salsa.debian.org/java-team/plm/-/merge_requests/3 3. sbt-util-interface (#1139638): pure-Java leaf, ready for NEW: https://salsa.debian.org/mendezr/sbt-util-interface jline3 is a Scala 2.13 thing, independent of 2.11, so it needn't hold this up. But in the meanwhile, I answered about that here, asking for your input. https://salsa.debian.org/java-team/jline3/-/merge_requests/3#note_769369 The scala-2.12-bootstrap "seed" is the only piece needing the "exemption talk", as we call it, with the ftp masters. Thanks for offering to help with the uploads. Please take your time, or we can wait for others to jump in. Best, Juan
e.g.: [repositories] debian: file:///usr/share/maven-repo What I can see from your point is the cost: each application still needs its whole dependency tree packaged at compatible versions, but still having the compiler and core libraries are a finite job and the foundation for the rest. I might be missing something though, let me know if you anything wrong. Juan
Le 12/06/2026 à 16:15, Juan M. Méndez Rey a écrit : What about the following steps: 1. Upgrade scala-asm to 9.x, do not keep 5.x 2. Inject the scala 2.12 jars in the existing scala package and build Scala 2.12 with a two pass build (1st with the prebuilt jars, the second without) 3. Update PLM 4. Package the sbt stuff That would skip the scala-2.12-bootstrap package Emmanuel Bourg
Hi Emmanuel, Sounds good, let's go with your plan. I already have the no-sbt 2.12 build and can move it into the two-pass embedded-seed proposal. - One thing to keep in mind: step 1 (dropping scala-asm 5.x) retires Scala 2.11, which has the 14 source reverse-deps. They will need rebuilding, porting, or removal. Your PLM PR will cover the main dependency of the old 2.11, and most of the rest already dropped Scala upstream, so it should be manageable. New MRs: scala-asm: https://salsa.debian.org/java-team/scala-asm/-/merge_requests/4 Scala: Bumped to 2.12.21 with your approach: New MR https://salsa.debian.org/java-team/scala/-/merge_requests/2 Clean with sbuild + lintian --pedantic + autopkgtest. Please, have a look when you have some time, Juan Best, Juan-------- Original Message -------- On Friday, 06/12/26 at 17:58 Emmanuel Bourg <ebourg@apache.org> wrote: Le 12/06/2026 à 16:15, Juan M. Méndez Rey a écrit : What about the following steps: 1. Upgrade scala-asm to 9.x, do not keep 5.x 2. Inject the scala 2.12 jars in the existing scala package and build Scala 2.12 with a two pass build (1st with the prebuilt jars, the second without) 3. Update PLM 4. Package the sbt stuff That would skip the scala-2.12-bootstrap package Emmanuel Bourg