Bug#639910: Packaging sbt
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 <frediz@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 <mehdi@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
> >
Reply to: