Joe Smith <unknown_kev_cat <at> hotmail.com> writes: > I'm not so certain about bycode-compiling eclipse with gcj.
>From http://www.backports.org/~mkoch/unstable/ eclipse_3.1-10.diff.gz it appears that first the (bootstrap) ecj compiler is built using gcj, then the rest of eclipse is compiled with the natively compiled bootstrap ecj. See eclipse-3.1/debian/rules for details. > Also note that Kaffe includes some classes that are not a part of GNU > classpath, so it is possible a program may work fine on kaffe, but not on a > different free interpreter/native-compiler. Yes. Kaffe acts as a melting pot for some class libraries that usually find their way into GNU Classpath sooner or later. Meanwhile, they are all available from the respective upstream projects wherefrom they were merged into Kaffe. See the file THIRDPARTY in Kaffe's source code for details. There are different philosophies applied by different free runtimes, targeting different users, essentially. Some people prefer to have a lean VM, and to rely on excellent packagers to integrate it with other libraries into one nice runtime environment, others prefer to do the integration beforehand to make it easier for users and developers who don't use systems with excellent packagers. But the core class library foundation is pretty much the same for all GNU Classpath 0.18 using runtimes, for example, whether they ship their own copy or not. > > It'd be impossible to move it main, afaik, if it only depended and worked > > on non-free software. > > true. However if it has a depends of [free software] *OR* [non-free > software], it is allowable. Yes. It's not necessary, though, afaik, simply depending on java-virtual-machine/java2-runtime should do the trick as well, as the non-free VMs should provide that just like the free VMs. And that's what the package does, afaict by the diffs, so I believe we are having a hypothetical discussion. > > If you want to avoid a $freevm download completely, you'd have to > > make sure that the eclipse 3.1 package and all its dependencies build > > and work fine on the non-free software in question, and don't > > mess with the non-free software's licensing restrictions, for example. > > It seems unlikely that any changes needed to support a free JVM will break > the running of > the program on the official JVM. Remember that the upstream version is > intended to be run > on the official JVM, so we know that that works. There is no official JVM that has ever ran through the official compatiblity test suite on Debian Sarge afaik, so one can't assume that an 'official' JVM will fully behave as advertised in a configuration which it wasn't certified for. See the various threads about the crashing-on-startup IBM JDK on powerpc last year. One can test, though, and through testing achieve a certain degree of confidence that a VM in question, nevermind whether its free or non-free, certified or not, does in fact successfully run the software you want to package on Debian. > I can see no reason why there would be licencing issues. I am aware of no > JVM that prohibits running of > java bytecode that can also be run on a JVM that is licenced differently. I was thinking about some of the more esoteric clauses in non-free VM licenses, like restrictions on sub/supersetting of certain namespaces. Though I don't recall whether that was a restriction on redistribution or on use, I believe that clause got shifted around a bit between the two areas in between the releases. That has little to do with eclipse itself, but may matter for some dependencies of it, for example, if they sub- or superset some official Java technology API. The dependency graph of a big Java application like cocoon, Eclipse or JOnAS can be very huge. But then, it's still a very far fetched scenario. A more likely licensing issue would be a DD not being interested in agreeing to license terms for some non-free VM, since he wouldn't want to install non-free software on his box (who would, anyway? ;). Then it'd be up to users of non-free VMs to help the DD keep the package in a good shape wrt to the non-free VMs, with patches, bug reports and praise, when things work ;) cheers, dalibor topic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
