Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

Recently, I upgraded my JDK from sun-jdk-1.4.1.02 to sun-jdk-1.4.1.03 as part
of
a routine update.  This caused the following problems.

(1) Browser plugin in /usr/lib/nsbrowser/plugins was not updated and so
referred
to sun-jdk-1.4.1.02.  The ebuild gave message below.

* Not creating symlink for the java plugin, because there already is a java
plugin installed.

This meant that the plugin was referring to sun-jdk-1.4.1.02 (which had been
removed) rather than the new package sun-jdk-1.4.1.03.

(2) The system lost java command capability on the console as the system VM was
set to sun-jdk-1.4.1.02 which had been removed.

(3) The sun-jdk-1.4.1.03 package is compiled using gcc3 and does not work with
mozilla-firebird-bin.  The browser recognises it as 1.4.1_02-b06 rather than
1.4.1_03-b02 as it should do and as mozilla nightly does correctly.

(4) No mention was made in the postinst of the ebuild that the browser plugin
and java-config settings were now referring to an obselete JDK and that one
should update their settings.

Here are some proposed changes.

(1) All java ebuilds add to postinst einfo/ewarn messages such as below.

* If this is an upgrade of your JRE/JDK and 
* this is set as your default java VM then
* please run java-config to reassign your VM.

* If your java browser plugin is dependent on this package
* then please revise your plugin location.

(2) Greater automation could be adopted although my guess is that the user base
will be divided on their opinions on this subject.

A simple check by every JRE/JDK ebuild could be made to see if it is the
current
system VM and if it is it could use java-config to reassign system VM to the
new
package as last step.  The user VM would be left untouched.  Or it could simply
spit out the command to reassign system VM as an einfo message.

(3) Some policy should be decided about what plugin symlinks are made to
/usr/lib/nsbrowser/plugins.  Are gcc3 plugins to be added or only gcc2 plugins
to save breaking compatibility with browsers?  The answer to this depends on
your default browser.

firebird-bin = gcc2
firebird-cvs & firebird = gcc3
mozilla = gcc3

Often I have wished that there were different plugin directories for gcc2 and
gcc3.  The argument against creating two different plugin directories is of
course that sometime in the future firebird-bin will be built with gcc3 whereas
right now the maintainer is using redhat 7.3 with gcc2.  Such a wait is
generally unpleasant and it is much easier to make changes on the user end.

As is evident, there are many issues which require thought here and both
JRE/JDK
ebuilds and the java-config script must share the load of dealing with these
issues.  If java-config is further refined to take account of changing VM's on
the fly and of browser plugins then the ebuild can simply use that
functionality.

This bug can serve as a focal point for change and contribution on this topic
and it has been made a normal bug rather than an enhancement since some things
are incorrect in their current state.

To extend change (3) a little more:

One can have a plugin directory for binaries in for example /opt/plugins and another for source packages in say /usr/lib/plugins and the browsers can simply symlink to these depending on whether they are binaries or source packages.

To add another proposed change about creating new browser plugins when upgrading J packages:

(4) A check can be made if the current java plugin symlink refers to package being unmerged and rather than leaving it there one can remove it and add a new one from new package.  I agree this is taking a considerable amount of liberty but certainly omitting new plugins on the basis that there are old and obselete plugins in the plugin directory is surely not suitable either.  If this change was not being made then a message about it would be useful too.

This is hairy; 

(1) Yes, the ebuild should know that if it's an upgrade of itself the plugin should be symlinked forcibly

(2) Are you sure this is the case after running env-update or logging in again?

(3) The present upstream maintainer of the mozilla-firebird binary builds at mozilla.org is using RedHat 7.3 and doesn't appreciate that GCC 3 is what is used by a massive number of users now. I'm trying to have him create a GCC 3 build.

In reply to your question, there may be no point in running env-update surely
as the jdk that the default system VM referred to has now been removed.  When I
reset the system vm to the new jdk and sourced profile all was well.

I can make a patch for the upgrade to not break, but for now it need to set
the system vm to the latest JDK JRE installed.

I know its not the better solution for this but it can fix a lot of problems.
What you think about it ?

In java.eclass:

java_pkg_postinst() {
-	if [ -z `java-config --java 2> /dev/null` ] ; then 
-		einfo "No default VM found, setting ${VMHANDLE} as default"
+		einfo "Setting ${VMHANDLE} as default"
+		einfo "Use java-config to reassign your VM."
		java-config --set-system-vm=${VMHANDLE}
+		/usr/sbin/env-update
+		source /etc/profile
-	fi
}

*** Bug 17881 has been marked as a duplicate of this bug. ***

Yes.  That sounds good.  I'm also glad it applies the settings in the current
terminal rather an outputting a message about sourcing /etc/profile.  But
when you say the latest jdk do you mean the highest version or the most recently
emerged jdk?

The most recently VM emerged its going to be set as the system default, cause
i cant find a way to make comment #0 point 2.

*** Bug 30577 has been marked as a duplicate of this bug. ***

Setting the system-vm to the latest emerged version is not a very good idea. On
My system, I've got both jdk-1.4 and jdk-1.5 installed. Jdk-1.5 however breaks
a few packages (because of the 'enum' keyword) and is not ready for production
use. I only use it for my personal projects. But with the current behaviour the
ebuild keeps setting it to the system default vm after an upgrade, and I have
to keep setting it back to 1.4. It even causes compilation failures when doing
an 'emerge -Du world'.

I think it should only set the default vm when the newly installed version is
an upgrade of the installed version. That means, it has to be the same package
and the same slot.

java guys what's the word on this bug it's 3+ months old. I just started
running into it myself.
---------------------------------------------------------------------------------
LoadPlugin: failed to initialize shared library
(m[/opt/blackdown-jdk-1.4.1_beta/jre/plugin/i386/mozilla/javaplugin_oji.so:
undefined symbol:
SetGlobalServiceManager__16nsServiceManagerPP17nsIServiceManager]
---------------------------------------------------------------------------------
This causes my freshly compiled mozilla to crash and burn at what seems to be
about every 3-4th webpage I visit which causes me to be less productive which
then results in less things getting fixed for gentoo users as a whole.

Downgrading mozilla is not an option either (GLSA-200409-26)

I'm looking for a definitive solution to this problem rather quickly so I can
be productive again. 

thanks in advance.

Thinking we should
1) force installation of the plugin and
2) change the plugin along with java-config --set-system-vm

any comments/objections?

Well considering my mozilla has crashed about 40 from the time I last commented
on this bug, I'm game and object nothing that gets me back to a state that's
functional.

Whatever you think best.  I've no objections.  I wanted to make bugzilla aware
of the problem.

i don't use mozilla, and absolutely hate applets
so i want to make sure i don't make it worse

One of the biggest problems is blackdown-jdk seems to download binaries
compiled with gcc 2.95.3, even though there should be logic in the ebuild to
determine the proper version to fetch. 

This is probably what's crashing mozilla.

there aren't any blackdown-jdk's in the tree any more that install a 2.95, and
i tested it, that doesn't cauz mozilla to crash (for me at least)

solar why are you still using blackdown-jdk-1.4.1_beta?
that was removed from the tree 17months ago

the way plugins are installed atm is incosisent and can leave symlinks around
that should be removed, i'm attempting to clean it up

but lots jdk/jre's in the tree

hrmm 17 months. Clearly you can tell I like updating java :)
I'll attempt to update right now and hope that it resolves the problem and report back (success/failures)

Created an attachment (id=40229) [details]
big-jre-jdk-plugin-cleanup.diff

since this (sorta majorly) changes the eclass
i would like some ppl to test & comment if i'm not being a dumbass

and a typo in the first few lines of that patch :X

(no, i didn't test _every_ ebuild yet, gonna do that when/if i commit)

Updated java. orig problem with unfedined references to symbol names appears to
have gone away. End result of mozilla still crashing is the same on anything
java related.

"libgnomevfs-WARNING **: Unable to create ~/.gnome directory: Bad address" and
I've updated just about everything else in the chain.

Thanks for your help but I'm now thinking the bug lies elsewhere with the
above.

I'll test your patches in about another 17 months :)

this patch won't fix your problem anyway, it's basicly just a cleanup, so that
last merged jre/jdk is always the plugin in use, and that it doesn't install 2
java plugins(like it would in same cases b4)
and made the ibm's check for gcc version too when installing the plugin

in the tree