Re: Packaging sbt
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: