Re: gcj and etch freeze
gcj-4.1 in experimental is not just about gcjwebplugin; it contains a
backport of a classpath-0.92 prerelease and gcj from the current
trunk. it's this upgrade which makes gcj interesting for etch. If we
do want to include, it has to be tested with packages currently
depending on it (packages like OOo, eclipse, many more smaller
packages). I've tested myself just with eclipse and jython on i386 and
amd64, so we are missing tests for ia64, sparc, powerpc, alpha, s390,
mips, mipsel (besides the testsuite). I can't do these tests in the
next two weeks, so help on it would be appreciated.
Steve Langasek writes:
> On Sat, Aug 19, 2006 at 11:42:03AM +0200, Robert Millan wrote:
> > It's a little weird. The package that puts the plugin into firefox dir (via
> > symlink) is java-gcj-compat-plugin, but gcjwebplugin-4.1 contains the actualy
> > object. I suppose when a few versions of gcjwebplugin-X.Y exist,
> > java-gcj-compat-plugin will decide which one is more suitable by changing the
> > dependency and the symlink.
>
> That sounds like a terrible amount of complexity to me. I can't imagine why
> it would ever be beneficial to carry more than one version of gcjwebplugin
> around in the archive at a time.
gcjwebplugin doesn't have it's own source anymore. it's in classpath
(and gcj-4.1). gcjwebplugin-4.1 is compiled to native code and ensures
that the gij runtime is used with it.
Matthias
Reply to: