Hello Mehdi/Emmanuel/all, back on that topic, I did some work and would need your feedback on it before going further.
What Mehdi said in his last comment, inspired me the following : For sbt source package, I created 4 "sources" tarball : 1. sbt_0.13.13~RC1.orig.tar.gz : this is the upstream source release of sbt : https://github.com/sbt/sbt 2. sbt_0.13.13~RC1.orig-bootstrapsbt.tar.xz : this is the binary (mainly sbt-launch.jar) of the previous sbt version, in our case : 0.13.12 previous 3. sbt_0.13.13~RC1.orig-bootstrapdeps.tar.xz : these are all the jars that sbt 0.13.12 binary would fetch when running against that particular project. 4. sbt_0.13.13~RC1.orig-launcher.tar.xz : additional source for the launcher : https://github.com/sbt/sbt-launcher-packag e 1 and 4 are simply the tarballs from upstream projects. 2 and 3 are created from debian/rules get-orig-source target. 2 is the binary tarball that upstream already provides, but it's a "minimal" sbt without all the jars needed to run. At launch time, it would detect that and will fetch all them. For 3, I use the sbt binary of 2, to fetch all the jars it needs online and I build a tarball from that. This enables to build the source of the project offline (forcing it) with all needed jars. The point is that the sbt package I built is "nude". If I install the package built, the 0.13.13~RC1 version of sbt would need a minimal set of jars that is missing (in the same way of 2) and "sbt" command would fail. So I did the same for all the dependencies needed by this minimal sbt, so that running "sbt" from the command line won't complain. That is, for all dependencies that are not already in Debian, I built a package and as most of them (if not all if I remember) are sbt projects, I did that 3-tarball-source, with the upstream project, a prebuild 0.13.12 minimal binary sbt and a tarball of binary jars dependencies for the latter. This enabled to build packages for : https://github.com/bmc/classutil https://github.com/bmc/grizzled-scala https://github.com/bmc/scalasti https://github.com/foundweekends/giter8 https://github.com/non/jawn https://github.com/json4s/json4s https://github.com/sbt/serialization https://github.com/sbt/test-interface https://github.com/scala/pickling https://github.com/harrah/sbinary https://github.com/scopt/scopt and have a working sbt command line without connecting online but using Debian's local maven-repo. There is much work to finalize this if that is ok, but indeed, before continuing I'd like to know if I'm on the good path. F. On Wed, 6 Jan 2016 01:58:13 +0100, Mehdi Dogguy <me...@dogguy.org> wrote: > Hi, > > On 05/01/2016 16:32, Emmanuel Bourg wrote: > > The "easiest" solution is probably to start with a non-free sbt package > > containing a prebuilt version of sbt, and then upload in main a sbt > > package depending on itself with the prebuilt sbt removed. I would use > > only one sbt package, instead of sbt-bootstrap in non-free and sbt in main. > > > > Note that you can very much include a working sbt binary in the source > package and use it the bootstrap sbt. The only condition that we must > respect is to not ship that binary in the package, but ship the built > binary only. This is done for many packages: OCaml for its bootstrap > and most probably ghc (didn't check tbh). Also, compiling gcc requires > a gcc. :-P > > My 2 cents, > > -- > Mehdi >
