| Summary: | Java JDK/JRE packages won't set nsplugin automatically when upgrading from gen-1 to gen-2 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Rodrigo Severo <rodrigo> |
| Component: | New packages | Assignee: | Java team <java> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | normal | CC: | truedfx |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Patch that corrects nsplugin for binary packages. | ||
|
Description
Rodrigo Severo
2006-09-29 03:27:31 UTC
Created attachment 98366 [details, diff]
Patch that corrects nsplugin for binary packages.
Already tested. Seems to be fine.
I think it's normal that .tbz2 package contains stuff based on useflag, i.e. you determine it at build time, not merge time. So if you build that .tbz2 with nsplugin, you merge it with nsplugin. If you don't build it with nsplugin, you won't merge it with nsplugin. Or does that not work here? The only part of the install which would be affected by differences between building and merging system, is making the nsplugin selected if there's none selected yet, and that's already done in pkg_postinst by the eclass. Otherwise I don't see a problem here? Please, clarify "is ineffective". I don't see what's the problem here either. (In reply to comment #4) > Please, clarify "is ineffective". I don't see what's the problem here either. I emerged the binary package without problem: no errors nor warnings. After that firefox had no java plug-in. This is what I mean by ineffective. If I emerge the binary package with the patched version of the ebuild, firefox has the expected java plug-in. I changed no USE flags between both emerges. (In reply to comment #2) > I think it's normal that .tbz2 package contains stuff based on useflag, i.e. > you determine it at build time, not merge time. So if you build that .tbz2 with > nsplugin, you merge it with nsplugin. If you don't build it with nsplugin, you > won't merge it with nsplugin. Or does that not work here? Absolutely correct. Unless we're both missing the point of this report, there is no bug here. USE flags have no effect and are supposed to have no effect when merging a binpkg, and in the general case, that's not even possible. (In reply to comment #6) > Absolutely correct. Unless we're both missing the point of this report, there > is no bug here. USE flags have no effect and are supposed to have no effect > when merging a binpkg, and in the general case, that's not even possible. Maybe I am misunderstanding the expected behaviour of a binary package merge. I expected that merging a binary package would give me the same effects (including the java plugin in firefox in this example) as merging the normal package. In other words, using: USE="nsplugin" emerge -av =dev-java/sun-jre-bin-1.5.0.08-r1 in one machine (which creates my binary package) and then USE="nsplugin" emerge -avk =dev-java/sun-jre-bin-1.5.0.08-r1 in another machine (which uses the previously created binary package) would configure the java plugin for firefoxess on both machines and not only on the first as it is the case now. Isn't this the expected behaviour? If it isn't please close this bug as invalid but please direct me to some place where I can get a better understanding of binary packages expected behaviour first. (In reply to comment #7) Thanks for explaining clearer; if that indeed doesn't work correctly, this is a legitimate bug report. From your earlier comments, it seemed (at least to me) as if you were saying that USE="-nsplugin" emerge -av =dev-java/sun-jre-bin-1.5.0.08-r1 USE="nsplugin" emerge -avK =dev-java/sun-jre-bin-1.5.0.08-r1 did not install the plugin. (In reply to comment #8) > (In reply to comment #7) > > Thanks for explaining clearer; I thank you for taking the time to understand my issue. > From your earlier comments, it seemed (at least to me) > as if you were saying that > > USE="-nsplugin" emerge -av =dev-java/sun-jre-bin-1.5.0.08-r1 > USE="nsplugin" emerge -avK =dev-java/sun-jre-bin-1.5.0.08-r1 I wasn't but just to help me clarify my understanding of emerge flags, the option between -k or -K wouldn't really change the issue here would it? As far as I used "emerge -av" first, "emerge -avk" and "emerge -avK" would give me the same results latter won't they? I think the use of the -N flag might have some affect in this issue but I'm way off topic here. Please disregard my previous post. I didn't noticed use used '-nsplugin' in the first line. Tried to reproduce it, and I've got nsplugin set both when emerging from the ebuild (and building the binpkg) and when merging the binpkg itself. Note also that the fix you propose makes no sense, there is no need to alter the image in preinst(). The install_mozilla_plugin() function just creates symlinks to the plugin so it's visible to the eselect java-nsplugin. The only action that should be executed during the merge and is not part of the image, is setting the nsplugin if there's none set yet (meaning, the file /usr/lib/nsbrowser/plugins/javaplugin.so) doesn't exist, and that's done in the eclass pkg_postinst() function by calling eselect java-nsplugin $VMHANDLE. And as I've just tested, it works with binpkg fine as well. So maybe you got some stray "/usr/lib/nsbrowser/plugins/javaplugin.so" file from old version, preventing the postinst step. In any case, after merging the binpkg, the nsplugin should be listed in "eselect java-nsplugin list". (In reply to comment #11) > Tried to reproduce it, and I've got nsplugin set both when emerging from the > ebuild (and building the binpkg) and when merging the binpkg itself. Note also > that the fix you propose makes no sense, there is no need to alter the image in > preinst(). The install_mozilla_plugin() function just creates symlinks to the > plugin so it's visible to the eselect java-nsplugin. > > The only action that > should be executed during the merge and is not part of the image, is setting > the nsplugin if there's none set yet (meaning, the file > /usr/lib/nsbrowser/plugins/javaplugin.so) doesn't exist, and that's done in the > eclass pkg_postinst() function by calling eselect java-nsplugin $VMHANDLE. And > as I've just tested, it works with binpkg fine as well. So maybe you got some > stray "/usr/lib/nsbrowser/plugins/javaplugin.so" file from old version, > preventing the postinst step. In any case, after merging the binpkg, the > nsplugin should be listed in "eselect java-nsplugin list". Well, after I (re)-emerged the binpkg, I effectivelly got the plugin set in firefox. I bet I now have the nsplugin listed in eselect java-nsplugin list as you say (I can't test it as the machine is off and at home now). Maybe it was really just a case of (re)-emerging and my "fix" had nothing to do with my second try working. If it seems as a no-issue to you, I will let it rest. (I have the patch in case I experience a different reality :) Thanks again for your attention. Well if you can and care to reproduce it, feel free to reopen :) (In reply to comment #13) > Well if you can and care to reproduce it, feel free to reopen :) Just tried in a another machine. During the final steps of Java update I did a emerge -aktv1 '=dev-java/sun-jdk-1.4.2.12*' '=sun-jre-bin-1.5*' as per java-check-environment request. Firefox had no java plugin after that. I did emerge -aktv1 '=dev-java/sun-jdk-1.4.2.12*' '=sun-jre-bin-1.5*' again, without applying my patch. Firefox got java plugin as expected. Well, after all my patch isn't necessary at all. The way to get the expected behaviour is just to emerge the same packages twice :) I won't reopen this bug as the real issue here is something else. If you want my help to find it, please let me know. Thanks again for your attention and help. OK I bet the glitch is that there was an older (gen-1) version of '=sun-jre-bin-1.5*' installed which owned the plugin file. When merging the new version, eclass postinst() is executed before merging the image, it sees the plugin is there (the old version is still installed), thus it doesn't try to set the plugin to own. Then image is merged and then old version is unmerged, taking its plugin away. Because that's the order of phases portage uses, we can't do much about it. But still, even after first merge you could use eselect java-nsplugin to set the plugin. And this will happen both with binpkgs and ebuilds, no difference here. FWIW, I've updated the eclass slightly earlier today, so it informs you (with einfo) that it's either setting nsplugin or isn't setting, because the file already exists. In either case it also points you to eselect java-nsplugin. CANTFIX as it's caused by portage order of phases. (In reply to comment #15) > FWIW, I've updated the eclass slightly earlier > today, so it informs you (with einfo) that it's either setting nsplugin or > isn't setting, because the file already exists. In either case it also points > you to eselect java-nsplugin. I think this is enough. This way it won't leave the user without the java plugin and a quest to understand what to do. Some intructions are much better than nothing. (In reply to comment #17) > (In reply to comment #15) > > FWIW, I've updated the eclass slightly earlier > > today, so it informs you (with einfo) that it's either setting nsplugin or > > isn't setting, because the file already exists. In either case it also points > > you to eselect java-nsplugin. > Well, when I'm trying to emerge java-jre-bin (nsplugin USE flag is set) on AMD64 machine, I get >>> Original instance of package unmerged safely. * JREs and 1.5+ JDKs are not supported for use with generation-1. * This is because generation-1 is only for use for building packages. * Only generation-2 should be used by end-users, * where all JREs and JDKs will be available * You have no system nsplugin set, setting it to sun-jre-bin-1.5. !!! Error: Usage: set [32bit or 64bit] [nsplugin-vm] exiting. * You can change nsplugin with eselect java-nsplugin. When I run manually $ eselect java-nsplugin Available 32-bit Java browser plugins Available 64-bit Java browser plugins $ no nsplugins are listed (In reply to comment #18) That is an unrelated issue. Please open a separate bug. |
