Re: Current status of your swt-gtk package
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
Reply to: