Summary: | app-eselect/eselect-java: incompatible with SYMLINK_LIB=no | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexander Tsoy <alexander> |
Component: | Current packages | Assignee: | Java team <java> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | candrews, chris, dschridde+gentoobugs, xaviermiller |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 506276 |
Description
Alexander Tsoy
2015-05-21 00:45:58 UTC
The code quoted above was actually part of the java-nsplugin module, which was dropped in 0.2.0 at the end of 2015. However, I believe this is still an issue due to the following line in the java-vm module. VM_BASE="${EROOT}/usr/lib/jvm/" I'll have a play with it. Ugh, this is more complicated than I thought. For starters, eselect only provides you with a relatively dumb way to get all the libdirs, not the primary one. I guess we'd have to use $(get_libdir) at build time to write this into the module but then it would break without a remerge if someone does the migration later? I'm thinking it may be more sensible to move to a location like /usr/libexec but I would have to ensure a smooth migration. /usr/libexec/eselect-java/run-java-tool.bash looks for /usr/lib/jvm/${GENTOO_VM} in some instances. This script is run every time you call java or javac so anything I do in here will need to be cheap. java-vm-2.eclass also gets it wrong as it sets JAVA_VM_DIR="/usr/lib/jvm". java-config duplicates the eselect functionality so that will be broken too. Perhaps it's time to finally remove that functionality. After discussing this in #gentoo-dev, I decided to leave things in /usr/lib. It didn't affect the 17.1 migration in the way that I thought it did, the libexec migration was too much of a headache, and this isn't such a bad location anyway. Since the original issue was already fixed, I'll close this now. |