Imported From: https://issues.scala-lang.org/browse/SI-9299?orig=1
Reporter: Fernando Racca (fracca)

@adriaanm said:
We'll be very happy to take pull requests to fix this at https://github.com/scala/scala-dist, but we don't have time to work on this ourselves. I'm sorry we can't be of help here, but the process to get included in Debian takes a lot of time, and sbt and scala installs are relatively straightforward: untar the archive.

@SethTisue said:
there is some good discussion about this at scala/scala-lang#295. (that ticket is closed; further discussion would better go here in JIRA)

@adriaanm said:
Or at https://github.com/scala/scala-dist/issues.

Adam Conrad (adconrad) said:
While some of the other issues brought up on the referenced ticket are of varying importance and interesting, there's really just one thing that needs to change to make things easier on distributions:

You need to make sure that release n+(reasonable_int) can be built with release n-(int)'s compiler.

That's it. Yes, many languages are self-hosting, C being the canonical example, but lots of effort is put in to make sure people can use a compiler from several years ago (or, in the case of C, a completely different compiler on another OS from 1979) to build the new one.

With that one policy change (and yes, it's a matter of policy, not a magic bugfix, people need to pay attention, and your development workflow has to involve always rebuilding using both your blessed "old" version, and your latest, to make sure both work), then distros only have to bootstrap once (which we're fine with), and never again. And everyone rejoices.

@adriaanm said:
Hi Adam, that's already the case. In our terminology, the starr compiler is used to begin the bootstrap, and it is downloaded from maven. Currently, we're using 2.11.6 to build 2.11.7 (https://github.com/scala/scala/blob/2.11.x/versions.properties#L11)

Adam Conrad (adconrad) said:
"You can build 2.11.7 with 2.11.6, released a few months ago" doesn't quite address my point. Sure, if downstream packagers are always on top of every release, that works, but if they intentionally (or accidentally) skip a release, having tight version requirements guarantees a rebootstrap.

@adriaanm said:
To be clear, you can build 2.11.x with any 2.11.y. It's trickier to bootstrap with an older major version (2.10.x building 2.11.y), but it's possible too. What exactly have you tried and what isn't working?

Adam Conrad (adconrad) said:
To be honest, I'm a third party in this, as I'm not the one who did the packaging in the Debian archive, I'm just an Ubuntu developer who was planning to rebootstrap the Debian packages in Ubuntu.

Indeed, the Debian packages declare a build-dep on scala >= 2.11, which matches your statement that any 2.11 can be used to build the next 2.11. What isn't clear to me is how many months/years back that takes me (I can't sort out when 2.11.0 came out), nor what this means for the future. Will 2.12 be buildable with 2.11, or will a switch to 2.12 mean a rebootstrap of all 2.12 releases with 2.12.0?

I'm not complaining about the current state of affairs. They are what they are, whatever that is, but trying to mitigate future pain.

@adriaanm said:
2.11.0 was released a little over 14 months ago (https://github.com/scala/scala/releases/tag/v2.11.0). 2.12.0 is planned for Q1 2016. In principle, the core of 2.12.0 will very likely compile on 2.11.x. You can then build the 2.12 modules with 2.12.0. In practice, we don't test this (we could/should), as we build 2.12.0 with milestones/RCs of 2.12.

Adam Conrad (adconrad) said:
Right, so that's probably the policy/practice I'm asking to change here. If 2.11->2.12 was an officially tested and supportable thing, we could relax out build-dependency requirements and not feel like we're forced to rebootstrap on every major upstream release.

And, if it's just the core (which makes sense) that carries that guarantee (or, really, even just a subset of the core), that just means changing the bootstrap method to be multiple stages to allow one to get from A to D through B and C without reinventing that wheel themselves.

Indeed, one can't build the majority of GCC without a recent GCC (and, often, without the very same version you're building), but the upstream build process takes this into account and lets you just pass CC=foo and it sorts out a bootstrap compiler to build the real compiler to build the rest of the suite, so this isn't something we need to figure out over and over again.

@soc said:
What I'm wondering is whether packaging Scala is actually the thing that should get priority.
Wouldn't it be more helpful to ship a current version of SBT first? People can then easily pick the Scala version they need, instead of having some random global version (which is just not even remotely how Scala development works).

Don't take me wrong, I'm a fan of package managers, but I think the quest to manually re-package every Java/Scala/... compiler/framework/library under the sun is doomed to fail. Is there any actual package in Debian that would depend on Scala?

@adriaanm said:
Good point Simon.

To clarify my message, I fully expect it to be possible to bootstrap 2.11.7 from 2.10.x, but we don't guarantee this since we don't have the resources right now to test this workflow. If someone were to try this and came to rely one it, we would be happy help make sure it doesn't regress. We're not super policy driven or constrained -- a CI job (we can take care of that) and someone to ping when it breaks would suffice.

@SethTisue said:
Note that it's settled that Scala's old ant-based build will be removed very soon from the 2.12.x branch, in favor of the new sbt build.

There was some discussion recently about the implications of this for Debian et al at scala/scala#5311 ; that discussion can continue here.

just noticed that #10172 is a duplicate of this. there is some relevant discussion there

new thread about a new effort to tackle this: https://contributors.scala-lang.org/t/question-about-building-scala-and-sbt-proper/2811

Closing, as this isn't actionable within the scala/scala repo itself.

there's another new thread on this at https://contributors.scala-lang.org/t/bootstrapping-of-the-scala-compiler/6242