| Summary: | java-osgi.eclass: 'Unable to uncompress correctly the original jar' | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ruslan Lopatin <ruslan.lopatin> |
| Component: | Eclasses | Assignee: | Java team <java> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | 2007.0 | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
The realpath is a symlink to readlink from sys-apps/coreutils-6.9-r1. Caster, could you have a look at this as you wrote the canonalise function when you fixed the eclass the first time. I remember that I only used readlink, I did not know about realpath (actually on my system -amd64- I don't even have realpath installed, so for me commons-logging merges fine). Can't we just use only readlink? What are the reasons you wrote the canonalise function this way? (In reply to comment #1) > The realpath is a symlink to readlink from sys-apps/coreutils-6.9-r1. Well that's wrong, realpath != readlink. The "real" realpath (app-admin/realpath or the one that's on bsd systems) does not need -f argument, in fact it reports it as invalid option. Did you make the symlink yourself? Because AFAIK coreutils does not make it. If you made it yourself then I'd close it as invalid. If something installs it, it needs to be fixed and as a workaround we could check if realpath is symlink to readlink. But I wouldn't add the check just if few users make wrong symlinks :) (In reply to comment #2) > Can't we just use only readlink? What are the reasons you wrote the canonalise > function this way? It's because of fbsd which doesn't have readlink supporting -f option (which is needed here), but has realpath in the system. Consulted it with Flameeyes, I still hope he will move the function to his portability.eclass one day :) (In reply to comment #3) > (In reply to comment #1) > > The realpath is a symlink to readlink from sys-apps/coreutils-6.9-r1. > > Well that's wrong, realpath != readlink. The "real" realpath > (app-admin/realpath or the one that's on bsd systems) does not need -f > argument, in fact it reports it as invalid option. > Did you make the symlink yourself? Because AFAIK coreutils does not make it. If > you made it yourself then I'd close it as invalid. If something installs it, it > needs to be fixed and as a workaround we could check if realpath is symlink to > readlink. But I wouldn't add the check just if few users make wrong symlinks :) > I removed realpath symlink and everything works now. It not belongs to any package anyway. But i am not sure how this symlink appeared. It is creates long time ago (15 May 2005). So, may be it was installed by some package and didn't removed correctly. I don't remember that i created it. |
Unable to emerge packages using java-osgi.eclass. Every attempt results to 'Unable to uncompress correctly the original jar'. Reproducible: Always Steps to Reproduce: emerge =dev-java/commons-logging-1.1-r4 The same for icu4j-3.6.1. Actual Results: >>> Install commons-logging-1.1-r4 into /var/tmp/portage/dev-java/commons-logging-1.1-r4/image/ category dev-java java.io.FileNotFoundException: (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:106) at java.io.FileInputStream.<init>(FileInputStream.java:66) at sun.tools.jar.Main.run(Main.java:205) at sun.tools.jar.Main.main(Main.java:1022) * * ERROR: dev-java/commons-logging-1.1-r4 failed. * Call stack: * ebuild.sh, line 46: Called src_install * environment, line 4049: Called java-osgi_newjar-fromfile 'src_install' 'src_install' 'target/commons-logging-1.1.jar' * environment, line 2252: Called _java-osgi_makejar-fromfile '/var/portage/dev-java/commons-logging/files/commons-logging-1.1-manifest' 'Apache Commons Logging' 'target/commons-logging-1.1.jar' '/var/portage/dev-java/commons-logging/files/commons-logging-1.1-manifest' * environment, line 424: Called die * The specific snippet of code: * cd "${_OSGI_T}/tmp_jar" && jar xf "${absoluteJarPath}" && cd - > /dev/null || diefunc "$FUNCNAME" "$LINENO" "$?" "Unable to uncompress correctly the original jar"; * The die message: * Unable to uncompress correctly the original jar This happens because _canonicalise() function calls realpath with wrong args: Instead of realpath "${@}" it should be realpath -f "${@}" Without -f option realpath returns nothing. The corrected _canonicalise() function works fine and package merged successfully.