On Friday, 12 June 2026 12:59:27 British Summer Time Juan M. Méndez Rey wrote: > Hi David, > > Answering below > > El viernes, 12 de junio de 2026 a las 13:18, David Goodenough <[email protected]> escribió: > > 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. > Good to know, and good to remember when reach the scala 3 stage, thanks! > > > 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. > I believe we are agreeing at the end, but just to clarify, because I believe > both ways servers different and compatible purposes: > > - 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
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.
