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