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

Juan M. Méndez Rey <[email protected]> Thu, 11 Jun 2026 22:18:11 +0000
Newsgroups gmane.linux.debian.devel.java
Message-ID <gVRkGMMdbrDrd9trDUJ1ilkpVIFpYvGB-nxPIJy-2mQNXaXPOwbsM4Y1Yy10ZFjsQMoK5DqfzRTexSJBO4st_W8woaYjIhBk0nvEDp7Dbr4=@proton.me>
Hi David,

Thanks for coming into discussion specially if it helps on=20
simplifying the process! I had a look to the VirtusLab approach.=20
 =20
So, please,let me see if what I gathered clarifies, then a question,=20
because I think that option is not fully possible for=20
the Debian approach.
 =20
1. The 3.9 library: noted, thanks. I'd been assuming "Scala 3 =3D the 2.13 =
stdlib",=20
which holds to 3.8 but not 3.9's own _3 library.=20
It only affects the future Scala 3 layer; but for 2.12/2.13 and its ecosyst=
em are unchanged.

2. On "sbt + scala-cli bring the libraries":=20

As far as I can see that works because they fetch deps from Maven Central v=
ia Coursier
(https://scala-cli.virtuslab.org/docs/guides/introduction/dependencies/).=
=20

The Debian archive build targets must not attempt network access, so I beli=
eve this path
is not possible.=20
 =20
If we were to package sbt/scala-cli that still needs every library packaged
from source under /usr/share/maven-repo; that download model=20
is exactly what would prevent VirtusLab's .debs out of the archive,=20
hence why I suggested the approach proposed in this thread.

Question: can you confirm the VirtusLab .debs work that way. Like, they rel=
y on Coursier=20
pulling dependencies at first use, rather than shipping them from the archi=
ve?

Just want to be sure I'm describing them accurately.
 =20
Best,
Juan