Bug#1125161: Re-bootstrapping sbt and modern Scala; the Scala 3 path is now open
David Goodenough <[email protected]> Fri, 12 Jun 2026 14:51:58 +0100
| Newsgroups | gmane.linux.debian.devel.bugs.general,gmane.linux.debian.devel.java |
|---|---|
| Message-ID | <2041895.PYKUYFuaPT@continuum> |
This is a multi-part message in MIME format. --nextPart23137232.EfDdHjke4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday, 12 June 2026 12:59:27 British Summer Time Juan M. M=C3=A9ndez Re= y wrote: > Hi David, >=20 > Answering below >=20 > El viernes, 12 de junio de 2026 a las 13:18, David Goodenough=20 <[email protected]> escribi=C3=B3: > > 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! >=20 > > 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. > >=20 > > This also applies to the compiler and all its support libraries. > >=20 > > 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. > >=20 > > 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 beli= eve > both ways servers different and compatible purposes: >=20 > - 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 =E2=80=94 and would be = valuable > in its own right. >=20 > - My suggestion (and the RFP): package the compiler and libraries from > source so they can be build-dependencies for other Debian packages =E2=80= =94 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 ent= er > Debian until the toolchain is there. >=20 > 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 ea= ch > other. That second goal is the one I'm after. >=20 > Let me know if I got this correct, our you found any flaw. >=20 > Best, >=20 > Juan The problem is that most Scala packages are built using sbt or mill, and no= thing you can=20 do (to my knowledge) will make sbt or mill ignore maven and use .deb instal= led libraries. Likewise with any scala-cli scripts. So unless you can solve the centralized cache problem and force all build s= ystems to use it=20 you are not going to be able to do it your way. --nextPart23137232.EfDdHjke4D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" <html> <head> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8"> </head> <body><p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0= ;">On Friday, 12 June 2026 12:59:27 British Summer Time Juan M. M=C3=A9ndez= Rey wrote:</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; Hi David,</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; Answering below</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; El viernes, 12 de junio de 2026 a las 13:18, David Goodenough <david.g= [email protected]> escribi=C3=B3:</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > I think that 3.8 also uses the scala_3 library. 3.8 was a kind of RC= for</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > 3.9 so they wanted to make the breaking changes first before jumping= to</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > what it an LTS release.</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; Good to know, and good to remember when reach the scala 3 stage, thanks!<= /p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > SBT and Scala-CLI will always use the cached versions of the librari= es it</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > finds from Maven (or which ever repository you specify), and if you<= /p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > update the dependencies on your build file or script it will always = go</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > and fetch the new version from the repository. The cache lives in th= e</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > user's directory, and I don't think there is a system wide cache tha= t</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > debian packages could populate.</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > This also applies to the compiler and all its support libraries.</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > So yes, the virtuslabs .debs do not try to package libraries, just t= he sbt</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > and scalacli. Because that is the way the scala build system works.<= /p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > Packaging the compiler and the libraries is only of use if you want = to run</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; > them manually, and no-one does that.</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; I believe we are agreeing at the end, but just to clarify, because I beli= eve</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; both ways servers different and compatible purposes:</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; - Your approach: Having sbt + scala-cli so a developer can use Scala on</= p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; Debian, with Coursier fetching their dependencies on demand. That's a</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; separate effort that can be pursued independently =E2=80=94 and would be = valuable</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; in its own right.</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; - My suggestion (and the RFP): package the compiler and libraries from</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; source so they can be build-dependencies for other Debian packages =E2=80= =94 Scala</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; applications like Spark, Metals, Joern, and the existing Scala rdeps. The= y</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; need to build from source, offline, in the archive. None of those can ent= er</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; Debian until the toolchain is there.</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; So as a recap, tools and libraries: they serve different users (yours the= </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; developer, "mine" the Debian packages) and the two efforts don'= t block each</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; other. That second goal is the one I'm after.</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; Let me know if I got this correct, our you found any flaw.</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; Best,</p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; </p> <p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">>= ; Juan</p> <br /><p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0= ;">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 an= d use .deb installed libraries.</p> <br /><p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0= ;">Likewise with any scala-cli scripts.</p> <br /><p style=3D"margin-top:0;margin-bottom:0;margin-left:0;margin-right:0= ;">So unless you can solve the centralized cache problem and force all buil= d systems to use it you are not going to be able to do it your way.</p> <br /><br /></body> </html> --nextPart23137232.EfDdHjke4D--