sun-java versions

[sktsee]

On Mon, 25 Jan 2010 18:06:41 -0800, NoOp wrote:

[snip] 
> 
> I'll have a go at creating a .deb tomorrow. Perhaps we could get Patton
> to write a script to automate this afterwards? I'm sure you are more
> than capable, but Patton likes to develop scripts & this might be an
> ideal project for him :-)

Theres's a couple of caveats to using a java-package created deb verses 
the sun-java packages from multiverse that you need to be aware of. The 
first is that java-package only creates one deb that is not an update to 
the sun-java packages. It uses a different directory layout putting jre 
in /usr/lib/j2re1.6-sun rather than /usr/lib/jvm/java-6-sun-1.6.0.xx/jre. 
If you don't remove the sun-java packages first, you'll have two java 
installations that may or may not mess with each other. I removed all sun-
java packages before installing. I also removed the java-common package 
because I wasn't sure if the update-java script included in java-common 
is aware of non-Ubuntu provided java packages. Since I only have one java 
install per machine, I went ahead and got rid of it. If you keep it 
installed, you may have to tweak it a little.

The second caveat has to do with the bug report I filed yesterday, 
https://bugs.launchpad.net/ubuntu/+source/java-package/+bug/512546.
Basically, the deb's post-install script creates a number of symlinks in 
etc/alternatives and one points to a java plugin directory that Sun 
didn't include in the jre6-18 update. This causes the post-install script 
to fail, and the package is not cleanly installed. Commenting a snippet 
out of the make-jpkg post-install and pre-remove templates allows you to 
create a deb that can be installed/removed without error. The relevant 
files and code are in the bug report.

[snip]
> 
> Ah. But then you run into the same issues as other similar packages...
> SeaMonkey comes to mind - where 'supposed' "security" fixes are applied
> to outdated packages. But if you go through the security notices you
> find: 1) outdated versions, 2) patches that are only "selectively"
> applied. I've not bothered to check with OpenJDK, but can't help but
> wonder if the same/similar situation may apply.

Seamonkey is in universe, so by definition it is "Community Supported". 
That means it's in the same boat as sun-java. Whether it gets updated or 
not really seems to depend on the whim of the maintainer, or some other 
MOTU and clearing the SRU process. I think if there has been a CVE bug 
filed against a universe/multiverse package it gets attention, but there 
are some glaring examples of where it doesn't, as in the case of sun-
java.  OpenJDK, on the other hand, is in main and therefore supported by 
Canonical, so it should get more love. That's the theory, at least :)

-- 
sktsee