| Summary: | Installing a Generation-1 java ebuild with DEPEND on >=virtual/jdk-1.4 fails without =virtual/jdk-1.4* already installed | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jon Severinsson <jon> |
| Component: | New packages | Assignee: | Java team <java> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | 2006.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 145682 | ||
| Bug Blocks: | |||
|
Description
Jon Severinsson
2006-08-17 12:53:09 UTC
Well, so don't mix stable and unstable stuff, very simple. This stuff will be taken care of then the new java goes stable. Are you (the java team) really prepared to stabilize hundreds of packages at once, some of which isn't even owned by you? I just searched portage, and found 341 ebuilds in 221 packages that uses the generation 1 java build-system and depends on >=virtual/jdk-1.4. Unless you fix them (as I proposed) you MUST remove all 341 ebuilds from portage, stabilize the new java-build-system, and stabilize a new version of all 221 packages IN A SINGLE COMMIT, or there will be breakage in the stable tree! I think doing such a huge commit would be crazy, and thus I think that generation 2 will, for at least a short while, have to co-exist with generation 1 in stable. For that to work, this bug has to be fixed! It's no big problem right now (I'm an experienced user, and are expecting occasional temporary breakages as I use some unstable stuff), but unless fixed it will grow out of proportions when it hits stable. I'd suggest that you leave the stabilization handling up to our java team. I certainly don't expect them to be backporting fixing for tons of ebuilds, that's a huge waste of time... We have mailing lists for questions, use gentoo-java or gentoo-dev ML to ask, not bugzilla. http://www.gentoo.org/main/en/lists.xml I know of the mailing lists, I'm a subscriber of gentoo-java@lists.gentoo.org, and I a m using it for for QUESTIONS. However this isn't a question, its a BUG REPORT, and bug reports are supposed to go to BUGZILLA, not to the mailing lists. Also, please note that, in the above mentioned mailing list, the java team EXPLICITLY asked for STABLE users to test the new java build-system, and report any bugs to BUGZILLA. The idea was to help them make sure that the their planed INCREMENTAL stabilization efforts would be bug-free. So, would you please just assign this bug to the java team, so they can continue their great work on preparing for a bug-free stabilization. (In reply to comment #4) Also, please note that, in the above mentioned mailing list, the java team > EXPLICITLY asked for STABLE users to test the new java build-system, and report > any bugs to BUGZILLA. The idea was to help them make sure that the their planed > INCREMENTAL stabilization efforts would be bug-free. Sigh... They also explicitely told you to *not* mix old and new ebuilds as that *plain* *won't* *work*. So, don't do it and complain then that it doesn't work. It doesn't, we know that already. http://www.gentoo.org/proj/en/java/java-upgrade.xml#doc_chap2 > They also explicitely told you to *not* mix old and new ebuilds as > that *plain* *won't* *work*. So, don't do it and complain then that it > doesn't work. They told us not to mix the old and new BUILD SYSTEMS, which I haven't done. My entire java BUILD SYSTEM is unstable (all packages listed at http://www.gentoo.org/proj/en/java/java-upgrade.xml#doc_chap2 is in my package.keywords). However, the three packages with this bug I have had problems with so far, net-dns/libidn, dev-java/antlr and dev-java/gjdoc, is NOT part of the build system, and is NOT on that list. So I HAVE followed instructions, and still found this bug. (In reply to comment #6) > > They also explicitely told you to *not* mix old and new ebuilds as > > that *plain* *won't* *work*. So, don't do it and complain then that it > > doesn't work. > > They told us not to mix the old and new BUILD SYSTEMS, which I haven't done. My > entire java BUILD SYSTEM is unstable (all packages listed at > http://www.gentoo.org/proj/en/java/java-upgrade.xml#doc_chap2 is in my > package.keywords). Yes, this is true as the point of having two generations is to be able to have both generation 1 and generation 2 packages installed for normal java libraries/applications. > > However, the three packages with this bug I have had problems with so far, > net-dns/libidn, dev-java/antlr and dev-java/gjdoc, is NOT part of the build > system, and is NOT on that list. So I HAVE followed instructions, and still > found this bug. > Well please post the error messages then. (In reply to comment #0) > net-dns/libidn-0.5.15 uses the generation 1 build system, but depends on > >=virtual/jdk-1.4 instead of =virtual/jdk-1.4* > > As no JDK >=1.5 provides a generation 1 VM they won't work. Why would a >=1.5 need to provide a generation 1? 1.5 does not work in generation 1 or why else would we have made generation 2? >=virtual/jdk-1.4 ebuilds work fine with generation 1 stuff have around. If they don't work with 1.5 the DEPEND will be changed to =virtual/jdk-1.4* when it is migrated to generation 2. > > Yes, I'm using mixed branches (mostly stable, but with the new java > build-system in /etc/portage/package.keywords), and unstable libidn (0.6.5-r1) > is ported to the generation 2 build-system, but as the new java build-system > will go stable before net-dns/libidn-0.6.5-r1 (as net-dns/libidn-0.6.5-r1 > depends on it) pure stable users will, in the near future, be affected by this > bug. > > The same goes for every other generation 1 ebuild in portage. I haven't looked > for them, but I assume there is more generation 1 ebuilds depending on > >=virtual/jdk-1.4 instead of =virtual/jdk-1.4* that need to be fixed as well. > >=virtual/jdk-1.4 or >=virtual/jdk-1.3 was the standard way to mark depends in generation 1. Usually packages work with 1.5 without problems when use the generation 2 tricks so we can keep the >=virtual/jdk-1.4 atom in generation 2 too. (comment split in 2 due to size) (In reply to comment #7) > (In reply to comment #6) > > > They also explicitly told you to *not* mix old and new ebuilds as > > > that *plain* *won't* *work*. So, don't do it and complain then that it > > > doesn't work. > > > > They told us not to mix the old and new BUILD SYSTEMS, which I haven't done. > > My entire java BUILD SYSTEM is unstable (all packages listed at > > http://www.gentoo.org/proj/en/java/java-upgrade.xml#doc_chap2 is in my > > package.keywords). > > Yes, this is true as the point of having two generations is to be able to have > both generation 1 and generation 2 packages installed for normal java > libraries/applications. Thank you > > However, the three packages with this bug I have had problems with so far, > > net-dns/libidn, dev-java/antlr and dev-java/gjdoc, is NOT part of the build > > system, and is NOT on that list. So I HAVE followed instructions, and still > > found this bug. > > Well please post the error messages then. Thought this was obvious: * There was a problem determining which VM to use for generation-1 * You may need to set your generation-1 VM again, and run env-update && source/etc/profile * Also, make sure you have followed the Java Upgrade Guide: * http://www.gentoo.org/proj/en/java/java-upgrade.xml [ !! ] !!! ERROR: net-dns/libidn-0.5.15 failed. Call stack: ebuild.sh, line 1555: Called dyn_setup ebuild.sh, line 668: Called pkg_setup ebuild.sh, line 1248: Called java-pkg_pkg_setup java-pkg.eclass, line 51: Called die !!! Expected VMHANDLE to be defined in the env, but it wasn't !!! If you need support, post the topmost build error, and the call stack if relevant. (In reply to comment #8) > > Thought this was obvious: > I don't usually investigate into java build reports without the actual error because many people have broken environments that can be easily seen from the actual error messages so I would just be wasting my time trying to reproduce the issue of someone reporting that a package does not emerge. (In reply to comment #8) > > * There was a problem determining which VM to use for generation-1 > * You may need to set your generation-1 VM again, and run env-update && > source/etc/profile > * Also, make sure you have followed the Java Upgrade Guide: > * http://www.gentoo.org/proj/en/java/java-upgrade.xml > [ !! ] > > !!! ERROR: net-dns/libidn-0.5.15 failed. > Call stack: > ebuild.sh, line 1555: Called dyn_setup > ebuild.sh, line 668: Called pkg_setup > ebuild.sh, line 1248: Called java-pkg_pkg_setup > java-pkg.eclass, line 51: Called die > > !!! Expected VMHANDLE to be defined in the env, but it wasn't > !!! If you need support, post the topmost build error, and the call stack if > relevant. > I guess you are using a package.masked version of java-config. See http://planet.gentoo.org/developers/nichoj (In reply to comment #8) > > Thought this was obvious: > > * There was a problem determining which VM to use for generation-1 > * You may need to set your generation-1 VM again, and run env-update && > source/etc/profile > * Also, make sure you have followed the Java Upgrade Guide: > * http://www.gentoo.org/proj/en/java/java-upgrade.xml > [ !! ] > > !!! ERROR: net-dns/libidn-0.5.15 failed. > Call stack: > ebuild.sh, line 1555: Called dyn_setup > ebuild.sh, line 668: Called pkg_setup > ebuild.sh, line 1248: Called java-pkg_pkg_setup > java-pkg.eclass, line 51: Called die > > !!! Expected VMHANDLE to be defined in the env, but it wasn't > !!! If you need support, post the topmost build error, and the call stack if > relevant. > This is not caused by the depend >=jdk-1.4. This is caused by you not following the java upgrade guide properly. You could argue that changing the depend to =jdk-1.5 would pull the 1.4 jdk for you (which would set it as generation-1 jdk automatically if it's not set yet) but a) altering such number of ebuilds would be insane b) you still need to run env-update && source /etc/profile which is probably not possible during emerging of multiple packages. Yes it's a limitation of the old system that you need to take care yourself that it's configured properly before you try to build something with it. But at least it tells you what to do (read the upgrade guide) if it breaks. (In reply to comment #7) > (In reply to comment #0) > > net-dns/libidn-0.5.15 uses the generation 1 build system, but depends on > > >=virtual/jdk-1.4 instead of =virtual/jdk-1.4* > > > > As no JDK >=1.5 provides a generation 1 VM they won't work. > > Why would a >=1.5 need to provide a generation 1? 1.5 does not work in > generation 1 or why else would we have made generation 2? >=virtual/jdk-1.4 > ebuilds work fine with generation 1 stuff have around. If they don't work with > 1.5 the DEPEND will be changed to =virtual/jdk-1.4* when it is migrated to > generation 2. I'm not saying that virtual/jdk-1.5 should provide a generation 1 VM. That's not the problem, but rather a description on why (In reply to comment #7) > (In reply to comment #0) > > net-dns/libidn-0.5.15 uses the generation 1 build system, but depends on > > >=virtual/jdk-1.4 instead of =virtual/jdk-1.4* > > > > As no JDK >=1.5 provides a generation 1 VM they won't work. > > Why would a >=1.5 need to provide a generation 1? 1.5 does not work in > generation 1 or why else would we have made generation 2? >=virtual/jdk-1.4 > ebuilds work fine with generation 1 stuff have around. If they don't work with > 1.5 the DEPEND will be changed to =virtual/jdk-1.4* when it is migrated to > generation 2. I'm not saying that virtual/jdk-1.5 should provide a generation 1 VM. That's not the problem, but rather a description on why >=virtual/jdk-1.4 is a problem. On my brand new system I had no jdk installed. Because the depend was >=virtual/jdk-1.4, the most recent version available was pulled. So I ended up with dev-java/sun-jdk-1.5.0.08, which doesn not provide a generation 1 VM, and thus an ebuild that couldn't be compiled. My point is that all generation 1 ebuilds must depend on "=virtual/jdk-1.4*" (or "|| ( =virtual/jdk-1.4* =virtual/jdk-1.3*)", and not ">=virtual/jdk-1.4", (or ">=virtual/jdk-1.3"), whether or not the migrated generation 2 version of the same ebuild will work with virtual/jdk-1.5 or not. > >=virtual/jdk-1.4 or >=virtual/jdk-1.3 was the standard way to mark depends in > generation 1. Usually packages work with 1.5 without problems when use the > generation 2 tricks so we can keep the >=virtual/jdk-1.4 atom in generation 2 > too. Yes, you can keep >=virtual/jdk-1.4 and >=virtual/jdk-1.3 in generation 2. What you can't do is keep >=virtual/jdk-1.4 or >=virtual/jdk-1.3 in generation 1, as no virtual/jdk-1.5 will work for any generation 1 ebuild. (In reply to comment #10) > (In reply to comment #8) > > > > * There was a problem determining which VM to use for generation-1 > > * You may need to set your generation-1 VM again, and run env-update && > > source/etc/profile > > * Also, make sure you have followed the Java Upgrade Guide: > > * http://www.gentoo.org/proj/en/java/java-upgrade.xml > > [ !! ] > > > > !!! ERROR: net-dns/libidn-0.5.15 failed. > > Call stack: > > ebuild.sh, line 1555: Called dyn_setup > > ebuild.sh, line 668: Called pkg_setup > > ebuild.sh, line 1248: Called java-pkg_pkg_setup > > java-pkg.eclass, line 51: Called die > > > > !!! Expected VMHANDLE to be defined in the env, but it wasn't > > !!! If you need support, post the topmost build error, and the call stack if > > relevant. > > I guess you are using a package.masked version of java-config. See > http://planet.gentoo.org/developers/nichoj No, I'm not. I'm doing a clean install without any package.unmask file. I only have a package.keywords file containing the stuff listed at http://www.gentoo.org/proj/en/java/java-upgrade.xml#doc_chap2 (In reply to comment #11) > (In reply to comment #8) > > > > Thought this was obvious: > > > > * There was a problem determining which VM to use for generation-1 > > * You may need to set your generation-1 VM again, and run env-update && > > source/etc/profile > > * Also, make sure you have followed the Java Upgrade Guide: > > * http://www.gentoo.org/proj/en/java/java-upgrade.xml > > [ !! ] > > > > !!! ERROR: net-dns/libidn-0.5.15 failed. > > Call stack: > > ebuild.sh, line 1555: Called dyn_setup > > ebuild.sh, line 668: Called pkg_setup > > ebuild.sh, line 1248: Called java-pkg_pkg_setup > > java-pkg.eclass, line 51: Called die > > > > !!! Expected VMHANDLE to be defined in the env, but it wasn't > > !!! If you need support, post the topmost build error, and the call stack if > > relevant. > > > > This is not caused by the depend >=jdk-1.4. This is caused by you not > following the java upgrade guide properly. a) I'm not upgrading (it's a clean install) b) I am following the (relevant) parts of the guide. The problem is the >=jdk-1.4. Basically the depend says that 1.5 is satisfactory, when in fact it does not work. > You could argue that changing the > depend to =jdk-1.4 would pull the 1.4 jdk for you (which would set it as > generation-1 jdk automatically if it's not set yet) but > a) altering such number of ebuilds would be insane Perhaps, but the only other option (stabilizing 221 ebuilds in one commit, see Comment #2) is even worse... > b) you still need to run env-update && source /etc/profile which is probably > not possible during emerging of multiple packages. Yes it's a limitation of > the old system that you need to take care yourself that it's configured > properly before you try to build something with it. But at least it tells you > what to do (read the upgrade guide) if it breaks. Yes, but if it had depended on =jdk-1.4* instead of >=jdk-1.4 the instructions ( (In reply to comment #10) > (In reply to comment #8) > > > > * There was a problem determining which VM to use for generation-1 > > * You may need to set your generation-1 VM again, and run env-update && > > source/etc/profile > > * Also, make sure you have followed the Java Upgrade Guide: > > * http://www.gentoo.org/proj/en/java/java-upgrade.xml > > [ !! ] > > > > !!! ERROR: net-dns/libidn-0.5.15 failed. > > Call stack: > > ebuild.sh, line 1555: Called dyn_setup > > ebuild.sh, line 668: Called pkg_setup > > ebuild.sh, line 1248: Called java-pkg_pkg_setup > > java-pkg.eclass, line 51: Called die > > > > !!! Expected VMHANDLE to be defined in the env, but it wasn't > > !!! If you need support, post the topmost build error, and the call stack if > > relevant. > > I guess you are using a package.masked version of java-config. See > http://planet.gentoo.org/developers/nichoj No, I'm not. I'm doing a clean install without any package.unmask file. I only have a package.keywords file containing the stuff listed at http://www.gentoo.org/proj/en/java/java-upgrade.xml#doc_chap2 (In reply to comment #11) > (In reply to comment #8) > > > > Thought this was obvious: > > > > * There was a problem determining which VM to use for generation-1 > > * You may need to set your generation-1 VM again, and run env-update && > > source/etc/profile > > * Also, make sure you have followed the Java Upgrade Guide: > > * http://www.gentoo.org/proj/en/java/java-upgrade.xml > > [ !! ] > > > > !!! ERROR: net-dns/libidn-0.5.15 failed. > > Call stack: > > ebuild.sh, line 1555: Called dyn_setup > > ebuild.sh, line 668: Called pkg_setup > > ebuild.sh, line 1248: Called java-pkg_pkg_setup > > java-pkg.eclass, line 51: Called die > > > > !!! Expected VMHANDLE to be defined in the env, but it wasn't > > !!! If you need support, post the topmost build error, and the call stack if > > relevant. > > > > This is not caused by the depend >=jdk-1.4. This is caused by you not > following the java upgrade guide properly. a) I'm not upgrading (it's a clean install) b) I am following the (relevant) parts of the guide. The problem is the >=jdk-1.4. Basically the depend says that 1.5 is satisfactory, when in fact it does not work. > You could argue that changing the > depend to =jdk-1.4 would pull the 1.4 jdk for you (which would set it as > generation-1 jdk automatically if it's not set yet) but > a) altering such number of ebuilds would be insane Perhaps, but the only other option (stabilizing 221 ebuilds in one commit, see Comment #2) is even worse... > b) you still need to run env-update && source /etc/profile which is probably > not possible during emerging of multiple packages. Yes it's a limitation of > the old system that you need to take care yourself that it's configured > properly before you try to build something with it. But at least it tells you > what to do (read the upgrade guide) if it breaks. Yes, but if it had depended on =jdk-1.4* instead of >=jdk-1.4 the instructions (You may need to set your generation-1 VM again, and run env-update && source/etc/profile) would have been correct. As it is now, I first have to install a dependency that isn't listed in DEPEND, and then follow the given instructions. I'm a power user and was able to figure that out, however, when the new build system goes stable ordinary users will be hit by this, and they won't. By doing a very simple, non-intrusive change to DEPEND in affected ebuilds you'll will solve it. I'm just saying that you only have three options: 1) Change >=jdk-1.4 to =jdk-1.4* 2) Remove 341 ebuilds and stabilize another 221 in a single commit 3) Break the stable tree for ordinary users (and getting 100 duplicates of this bug report) And I think that option 1 above is the most sane (or least insane) way to go (In reply to comment #13) > 1) Change >=jdk-1.4 to =jdk-1.4* > 2) Remove 341 ebuilds and stabilize another 221 in a single commit > 3) Break the stable tree for ordinary users (and getting 100 duplicates of this > bug report) > And I think that option 1 above is the most sane (or least insane) way to go 4) hack java-pkg.eclass to contain DEPEND="=virtual/jdk-1.4*" which will affect all those 341 ebuilds instantly. (In reply to comment #14) > (In reply to comment #13) > > I'm just saying that you only have three options: > > 1) Change >=jdk-1.4 to =jdk-1.4* > > 2) Remove 341 ebuilds and stabilize another 221 in a single commit > > 3) Break the stable tree for ordinary users (and getting 100 duplicates of > > this bug report) > > And I think that option 1 above is the most sane (or least insane) way to go > 4) hack java-pkg.eclass to contain DEPEND="=virtual/jdk-1.4*" which will > affect all those 341 ebuilds instantly. Which basically is another way of implementing the change mandated in option 1). I see two problems with this though. Firstly it will require jdk-1.4 where jdk-1.3 would suffice, and secondly some ebuilds inheriting java-pkg.eclass always requires java, and some only does if the "java" USE-flag is specified. If those issues can be resolved hacking java-pkg.eclass would be just as good as editing all 341 ebuilds individually. Yeah this seems to be something that we have to think about when stabilizing but the title is way missleading. aria elog # USE="java" emerge -pvt libidn These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild N ] net-dns/libidn-0.5.15 USE="java nls -doc -emacs" 0 kB [ebuild N ] virtual/jre-1.5.0 0 kB [ebuild N ] virtual/jdk-1.5.0 0 kB [ebuild N ] dev-java/sun-jdk-1.5.0.07-r3 USE="-X -alsa -doc -examples -jce -nsplugin" 0 kB [ebuild N ] dev-java/java-config-1.3.0-r2 0 kB [ebuild N ] dev-java/java-config-2.0.26-r5 0 kB [ebuild N ] dev-java/java-config-wrapper-0.10-r2 0 kB This output is with nothing java installed on my server. Your emerge output looks like the same I had first time around. The second time, when I had sun-jdk-1.5 installed I only got: jon@jon ~ $ emerge -pvt libidn These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild N ] net-dns/libidn-0.5.15 USE="emacs java nls -doc" 1,925 kB Total size of downloads: 1,925 kB And the same error (as posted in Comment #8). Regarding title, this bug have had a bad track record. Your title would be the sixth one, none of them both correct and all-inclusive. (Your title is poor as the same problem occurs even if a 1.5 jdk is installed, but no 1.4 jdk is). Let's hope this sixth one will do. It's still missing that >=virtual/jdk-1.3 is equally bad as >=virtual/jdk-1.4, but you can't get everything in a one-liner. Just to note that our java-upgrade guide has these two notes: Important: The Generation-1 system VM MUST be a 1.4 JDK. If you do not already have one, then you must emerge one. For details about why this is necessary, please see this post. Note: You MUST have a generation-1 1.4 JDK in every case. This is required to build generation-1 packages, and for generation-2 packages that do not compile with Java 1.5. I also added actual code in there for emerge =virtual/jdk-1.4 Let's hope GLEP 42 gets implemented soon so that more likely read the upgrade guide. So, I think that the best fix to this problem is to make java-config-1.3.x post-depend on || ( =virtual/jdk-1.4* =virtual/jdk-1.3* ). The reason for this is that anytime that we have generation-1 around, and consquently java-config-1, we NEED to have a 1.4 or 1.3 JDK around. Having it as a PDEPEND satisfies this. I will begin testing this fix, and assuming it goes well, will commit it in the next week. Alright, so my other solution seems to have other side effects, ie bug #145682, so that solution is out. As is, we can't really fix per se, as in, do something in the eclasses / ebuilds to prevent this, short of updating EVERY SINGLE generation-1 ebuild out there, which would take forever. That time would be better spent stablizing the new Java system, and then ebuilds using it. I was able to improve the output though, so if you happened to miss all the points in the upgrade guide, you'll also get the info when the emerge fails: * There was a problem determining which VM to use for generation-1 * This is because the way Java is handled on Gentoo has drastically changed. * There does not seem to be a 1.4 or 1.3 JDK installed. * You should probably install =virtual/jdk-1.4* or =virtual/jdk-1.3* * It is important to have either a 1.4 or 1.3 JDK installed * in order for the old and new Java systems to coexist * Details about this can be found at: * http://overlays.gentoo.org/proj/java/wiki/Why_We_Need_Java14 * You should run, and follow the advice of: * /usr/bin/java-check-environment * You will also likely want to follow the Java Upgrade Guide: * http://www.gentoo.org/proj/en/java/java-upgrade.xml * If you have problems with the guide, please see: * http://overlays.gentoo.org/proj/java/wiki/Common_Problems !!! ERROR: dev-java/jdepend-2.8.1 failed. Call stack: ebuild.sh, line 1555: Called dyn_setup ebuild.sh, line 668: Called pkg_setup ebuild.sh, line 1248: Called java-pkg_pkg_setup java-pkg.eclass, line 65: Called die !!! Expected VMHANDLE to be defined in the env !!! If you need support, post the topmost build error, and the call stack if relevant. This is the best we can do for now. Marking fixed. |
