Hi Tony, > I'm still making my way through the packaging, but it looks fine so far. > It does feel very odd to upload source packages with those large > bootstrap dependency tarballs when some of the dependencies are already > in the archive. That's right. Honestly I did all that some time ago and I don't remember of a specific issue that would have prevented me from doing so (I still think I tried this at some point..) So yes we may have some redondant jars. Actually sbt as it is delivered, consist in a single jar. When you launch it, it fetches all its runtime dependencies online ; if it can't, it fails. So I consider this full set of jars as the working sbt, runnable and usable to go further, the one that upstream may have delivered for offline use if they had decided to do so. That ensured me less trouble by relying on a well "tested" upstream sbt, before going further. That also helps focusing on the missing runtime dependencies, leaving the build dependencies for later because bootstraping sbt in Debian will first need to have a Debian sbt running, and thus with available runtime dependencies in Debian. > Can you remind me of what the plan is once everything > hits experimental/unstable? I vaguely recall it being discussed, so a > pointer is fine. I just want to understand what comes next. What we will have once we have that last package in experimental is a runnable sbt. Which means, that doesn't fail and exit if it doesn't have access to the online jars repositories. That's the bare minimum set of jars I needed to have sbt start without error using the local Debian jar repository only. Having it start and display help without failing on some runtime dependency missing is not enough then to make some package needing sbt as "make" tool to build properly. Especially sbt itself and those other core dependencies I packaged for experimental. So I see 2 tasks next : - continue to package the runtime dependencies for sbt to be able to build packages of people interested by sbt as build tool : we have to keep in mind that we're working on sbt for others to package their software (especially my sponsor Andreas :) ) - fill the gap of the sbt build dependencies, that is get rid of those embedded sbt tarballs by providing all the packages for the latter, in Debian. Thus we will need to package all the missing build dependencies needed to build each of the core packages (and recursively..) that belong to that initial set (all the binary .jars embedded and listed in d/copyright etc) A big tree of dependencies will be revealed step by step and those will need to be packaged to be able to build sbt with sbt in Debian. I didn't check that deeply, but I think there are many packages to create given all the .jars I had to go through in d/copyright and that were dragged as runtime dependencies of the embedded sbt binary for the sbt core packages (and think of this recursively). One way of doing in both tasks, could be to continue to use embedded and ugly sbt binary tarballs for some time : - to ease the work (expecially concerning the recursive aspect : I have no estimate of the depth) - while still offering sbt usability to packagers (else I fear we'll need to wait too long for packaging completion of the full runtime/build dependency tree of sbt and its components, to deliver something complete : sbt and other packages that can build sbt and those other packages) I hope you have a better idea of what's next (sorry, that's not easy for me to explain) F. > > Thank you, > tony
Attachment:
pgpw5UoUMGIXC.pgp
Description: PGP signature