[arch-dev-public] [arch-general] Azureus

[Jan de Groot]

On Sun, 2008-04-13 at 02:12 -0500, Simo Leone wrote:
> On Sat, Apr 12, 2008 at 01:48:58PM +0200, Jan de Groot wrote:
> > I could update it again. The reason for patching it during froscon was
> > that upstream azureus doesn't work with GNU java. 
> > 
> Why do we care? What's wrong with depending on Sun's java package?

Because sun's java is non-free and it's not that much work to make it
working with GNU java. Azureus makes use of some com.sun.* classes that
aren't marked for public use by sun. If Sun decides to change their
com.sun.* class structure in the next java, azureus won't work with that
either.

> > Another thing was that
> > the jarfile contains a lot of Windows and Mac OS X related things, the
> > update manager doesn't work happily together with pacman packages and
> > the upstream distribution contains either outdated copies of libraries
> > where we have packages for, or just references to outdated copies that
> > are incompatible with our installed versions.
> > 
> Now some of that can be a problem.
> 
> > I had a look at the source, I can reduce some patches, as most are not
> > needed anymore. Back then, I wrote two patches to remove some com.sun.*
> > usage, they don't apply anymore and I have to check if they're still
> > needed and if so, rewrite them.
> > 
> See first response.

The patches I used on the old azureus are quite simple. They replace
every call to some function that only exists in sun's java with a
generic call that works on every java platform. They're not rocket
science.

> > Another thing I stumbled on were the dependencies:
> > >=dev-java/bcprov-1.35:0
> > >=dev-java/commons-cli-1.0:1
> > >=dev-java/log4j-1.2.8:0
> > >=dev-java/swt-3.4_pre6-r1:3.4
> > 
> > That's what gentoo lists as dependencies (there's no clear reference of
> > dependencies in the upstream source at all... just compile errors with
> > weird missing references when you don't have these installed).
> > 
> > -bcprov is packaged
> > -commons-cli isn't
> > -neither is log4j
> > -swt is at 3.3.x
> > 
> > Azureus 3.0.5.0 needs swt 3.4 development version (3.4M6 is current). If we don't want to
> > update swt to the development version, we're tied to the much older
> > 3.0.4.2 release, which needs some additional patches to compile from
> > source.
> > 
> > 
> Augh. Maybe we should go back to using the ones included with the
> jarfile, since I think the java policy we've got is basically... "split
> it if you can, don't bother if it's a hassle". This is starting to sound
> like a hassle to me.

Note that swt includes native bindings to gecko, gtk, etc. In our case,
swt needs to have the location of libgtkmozembed.so hardcoded into the
binary. The binary shipped with azureus doesn't do that specifically for
our distribution. If swt would be all about a stupid jar file, we could
just include it in the azureus package, but as there's native libraries
involved, I don't think it's a good idea to have parallel installations
of swt.