Compiling Scala and Sbt for Debian distro

On top of being a lot of work, I don’t think that this is enough to get your package in Debian, quoting from Reject FAQ for Debian's NEW-Queue :

Serious violations (direct rejects even if we only find one point)

Generated files: Your package contains generated files (such as compressed .js libraries) without corresponding original form. They’re not considered as the preferred form of modification, so you will either have to provide corresponding original form, or remove them from your tarball, eventually depending on an already available packages to provide missing features.

Decompiling Scala classfiles into Java source files is definitely not going to produce anything that can be called “the preferred form of modification”, even if it’s technically source code.

As I said last time we discussed this, you’ll need an exemption from the normal rules to get an up-to-data scalac in the archive, this is the only sane way to do it. Debian has many other bootstrapped compilers in their archive, which must have gotten in through some process, you just need to figure out what that process is, I suggest asking on the relevant Debian mailing-list.

5 Likes

3 posts were split to a new topic: Off-topic: Digression about GPL licenses

Seconded.

This is the answer, this is the only answer, this has always been the answer every time this has come up over the years. There is only one answer to this.

5 Likes

Since Scala 2.11 and sbt 0.13 are in Debian, it would require building Scala 2.12.0 with Scala 2.11 and an old sbt 0.13. This is the loose thread that was missed during the Scala 2.12 rollout, and was probably difficult since it was the first release without the Ant build config.

Unfortunately, it’s a difficult inflection point because there’s a good chance there are a lot of intermediate builds during Scala 2.12 development because of binary breaking changes that were made.

Yep: Question about building scala and sbt proper - #10 by smarter

The Scala 2.12 compiler is written in Scala 2.12 and uses the Scala 2.12 standard library. Compiling it with 2.11 isn’t an option.

(I’m seconding Guillaume, but I’m trying to put it in the plainest possible terms.)

1 Like

Sorry for my ignorance, but how is the very first Scala 2.12 version (v2.12.0-M1) built, if not with the last 2.11 release?

From my discussions with the Debian team, it means that a package can not contain binary code built from somewhere else. It means all packages must be built from source code that can be built using Debian built tools on debian servers. So an uncompressed .js source file is ok, beccause its the original source. But a generated .js file must be generated from the original source (another example: IDL definition file) on a Debian server, not by an external machine.

So my assumption is that by decompiling scala into java, that source code (as long as the Scala license allows) could be used to build a minamal scala runtime to be included on debian tooling server (dont remember what that server infrastructure was called at the moment) so that it can be used as a legal tool to build a proper scala distribution on the proper Debian build servers. (actually releases: testing, unstable etc, which have their separate build environments and tools available)

I dont remeber the exact history of the GCC development, but I think that the first version of GCC was written by hand by Richard Stallman in 1984. I dont know how it was built. that part is quite scetchy, but several other languages are mentioned, so maybe one of those language environments were free.

And a generated .java file must be generated from the original .scala source, except you’re proposing to upload directly to a Debian server some generated java files, do you see how this is as problematic as generated js files?

I would prefer that solution myself, but the Debian team does not. I discussed this with them the last time and they were adament that the only acceptable solution was to build from scratch using debian tools.

I even suggested simply adding scala to the non-free repository, but they allways shifted the discussion back into how to build it for Debian properly.

The current Scala and Sbt are as @smarter hints, built by the the source package containing a downloaded scala and sbt in a build-lib/ directory. The maintainers did not know this, so they explicitly told me that that was not an option for how to proceed. I think the current Sbt package (0.13) has been, or is going to be, removed from the the proper Debian releases, because of that infraction.

So if this is the only solution, then I ask for help on how to argue the case, by concrete examples and such. Or by figuring out how to get an acceptable Debian build using scala. I know that the tooling server can be used to build early version of tools to use to install on the proper build servers. But I dont know the Debian infrastructure or rules well enough, so any suggestion is valuable.

Just ask them how Rust got into the archive.

2 Likes

I understand what you say, but notice it states “corresponding original form”, which is not the same as “actual original code”

I might be wrong in my assumption, but my argument is the nuance that the IDL file is the source, while the js file isnt. The java file, on the other hand, is a reverse engineered file. Dont know if that argument will pass by the Debian team, but I will ask the Debian team if possible.

My understanding is that they are concerned with the source code being built on Debian servers from scratch and that its is free, not neccesarily that the code has to be “the actual handwritten original source code file”. The source code must be included so its humanly readable and compilable independently of any external tools or dependencies. Thats Debians primary concern as I understand it.

What ? Original means original, there’s no such thing as a “non-actual original”.

Which mean in particular that it’s not the preferred form of modification, which is how Reject FAQ for Debian's NEW-Queue defines “generated files”. Without this rule, you could just take any random binary, disassemble it into gas syntax and call the result “source code”. It’s text so it’s technically human-readable, but it would of course never be accepted into Debian.

2 Likes

This question is getting too Debian specific, so I’ll move the discussion over to the Debian devel mailing-list. Please join the discussion on the Debian list to help figure out a way to get Debian approval.

Havent gotten around to it yet, but yes. Do you know of other examples I can argue on the Debian mail list?

Haskell, OCaml and more: Bootstrapping (compilers) - Wikipedia

3 Likes

If that was the only hurdle you had to clear, you might be fine. But it isn’t the only hurdle; the compiler was re-bootstrapped several dozen times between 2.11.6 and 2.12.9. (And then a bunch more times after that to get to 2.13.0.)

link?

Lets explore this.

But first I’d like to mentionen that I checked the latest Debian releases (stable, unstable, testing)
All of them does contain scala 2.11., but no Sbt. Sbt was removed because of the infraction in bootstrapping. So I will not dwell on how scala 2.11 got into Debian. But at least now we got the neccesary tools to build Sbt the proper way in Debian (Just need help from the Sbt team to work out the command lines that is needed to build Sbt manually, and then script it.)
So this is some good news.

Next, how was the version re-bootstrapped? what tools, compilers, languages… and versions was used?