Sorry to ping you on that again. Any one having feedback on the validity of that bootstrap process ? Mehdi ? Emmanuel ? :) Thanks,
F. On Fri, 18 Nov 2016 14:41:27 +0100, Frederic Bonnard <fre...@linux.vnet.ibm.com> wrote: > 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 > >
