Hi Andreas, sorry for not answering recently. The reason for this is that I'm actively investigating another way of doing the bootstrap since 2weeks and would have liked to have something to say. So, yes, I'm still on that front. I don't give up the first way I tried, but I try to see if I can't do another way that is less complex : having things in non-free may be easy and faster, but pulling all that to main afterwards may be difficult.. I'm not sure. Also, I feel like having less control over the process as I did, because I fear that some deps may generate "bigjars" and include .class files that weren't compiled but extracted from library jars provided to bootstrap... At the moment, my idea is to try to compile sbt by just providing all the scalac commands needed and try to do all the process "manually". And do that for all the jars upon which the previous scalac commands depends on. So for the deps that are not compiled with sbt, I could package them directly in main and for the one using sbt, try to do things by hand. I just hope that there won't be any dependency where I won't be able to use that process.. Sorry for not providing you any deadline or certainty on the outcome of this. F. On Wed, 15 Nov 2017 16:56:21 +0100, Andreas Tille <tille@debian.org> wrote: > Hi, > > I wonder whether somebody keeps on working for this and what help I > could possibly provide. > > Kind regards > > Andreas. > > On Tue, Sep 05, 2017 at 09:19:44AM +0200, Frederic Bonnard wrote: > > Forwarding to the correct debian-java mailing list.. > > > > --- > > > > Hi Thorsten, > > > > thanks for working on that and everybody that answered to help this > > topic to progress. I've been off my computer last week. > > > > > your package seems to consist mostly of jar files without the corresponding > > > sources. So I am afraid I have to reject it. > > > > That's right, there are several jars that are part of the embedded sbt > > binary distribution that is used to only build the current sbt. > > All started here : > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639910#118 > > > > There Mehdi Dogguy explained we can bootstrap sbt this way as long as we > > do not ship those binary jars in the Debian binary package. It seems > > this process has been followed for other softwares. > > > > That looked ok for me since the spirit of Debian is there : the > > different components to upload are DFSG compliant : the sources of sbt > > are there (2) and licenses of all files are DFSG compliant (10) (other > > DFSG points are ok too; no mention of specific distribution point or > > restriction, classical licenses). > > > > The only thing is that in main the set of components that I've pushed > > may Depends on each other for runtime, but a simultaneous push in main > > of those should in theory be ok (2.2.1 : None of the packages in the > > main archive area require software outside of that area to function.) > > > > If binary jars for compilation are a problem, what should be done when > > for example you have a font file (with DFSG compatible license) that is > > used for generating image files at build time and those generated images > > will be included in the binary package. Should that source package be > > refused because the project didn't include the source of the font file > > (which can come from another project) ? (that could be a font file or > > any image without the source but with a DFSG license still) > > > > Sorry to play the devil's advocate and being irritating, I'm not that > > kind :), just willing to understand. > > So, am I missing some clear and strict policy point or is that a > > question of interpretation. > > > > F. > > > > > > > > Thorsten > > > > > > > > > > > > === > > > > > > Please feel free to respond to this email if you don't understand why > > > your files were rejected, or if you upload new files which address our > > > concerns. > > > > > > > > > -- > http://fam-tille.de >
Attachment:
pgpB83jm8JqTQ.pgp
Description: PGP signature