The ebuild uses java-pkg_newjar renaming the default class filename from jxl.jar to jexcelapi.jar. This causes a problem with other packages like g-octave/io which expects jxl.jar.
How exactly does the g-octave/io package expect jxl.jar to be somewhere? Let's dig into this... https://github.com/rafaelmartins/octave-overlay/blob/master/g-octave/io/io-1.0.20.ebuild https://github.com/rafaelmartins/octave-overlay/blob/master/eclass/g-octave.eclass http://svn.code.sf.net/p/octave/code/trunk/octave-forge/main/io/DESCRIPTION http://svn.code.sf.net/p/octave/code/trunk/octave-forge/main/io/PKG_ADD In fact, their code is not looking in the directories we install them to; the octave eclass and/or ebuilds should likely be corrected to properly look up the jar files and correct the lookup code, not the other way around. See java-pkg_getjar. http://www.gentoo.org/proj/en/java/java-devel.xml Besides that, dependencies (jexcelapi) and USE flags (since jexcelapi / java is optional as per the earlier DESCRIPTION link) are missing as well. Forwarding this bug to the g-octave maintainer; it's unrealistic for the Java herd to change installed file paths, change their reverse dependencies and stabilize everything again every time some package expects something in some place. This results in unnecessary bumps, file location conflicts and maintenance burden... We're however happy to help if there are problems implementing g-octave changes.
There is no problem with g-octave. I'm just asking to rename jexcelapi.jar to jxl.jar (this is the official name of the java class). I'm not asking to change its location. --- /tmp/jexcelapi-2.6.8.ebuild 2013-05-28 23:20:37.000000000 +0200 +++ /usr/portage/dev-java/jexcelapi/jexcelapi-2.6.8.ebuild 2013-05-28 23:20:46.000000000 +0200 @@ -40,7 +40,7 @@ } src_install() { - java-pkg_newjar jxl.jar ${PN}.jar + java-pkg_dojar jxl.jar java-pkg_dohtml index.html tutorial.html use doc && java-pkg_dojavadoc docs Nothing else should be changed. That's all :-)
(In reply to Fabio Rossi from comment #2) > There is no problem with g-octave. There is and it is detailed in Comment #1; it doesn't use Gentoo Java standards, doesn't look the jar up and doesn't list jexcelapi as an optional dependency. > I'm not asking to change its location. Yet, it needs to look up the path; this makes its name totally irrelevant. A name change breaks stuff instead of fixing things that are broken by design...
g-octave ebuilds are automatically generated, as you can see. If you can provide a patch to the io pkg sources, I can add it to g-octave database, and it will got applied by the automated ebuilds. I won't patch it myself though, because I don't know it enough. Thanks
Rafael, I'm looking into the io package to fix the problem. Besides patching the io package it'd be good also to manage the runtime dependencies. I see two options: 1) add the dependencies to RDEPEND 2) add an einfo() notice in pkg_postinst() The RDEPEND could be filled by using a proper DESCRIPTION file in the io package but this should be fixed upstream from what I have understood (if I patch locally the file using /var/cache/g-octave/patches/ than we have the common chicken-and-egg problem) How is possible to manage this with g-octave independently from upstream? What do you suggest?
The ebuild generator also struggles getting LICENSE right.
dependencies and licenses conversion from DESCRIPTION for ebuild are defined here: https://github.com/rafaelmartins/g-octave-db/blob/master/info.json patches are welcome.
einfo messages can't be added, sorry
