[Pkg-octave-devel] Packaging Octave 3.8

[Mike Miller]

On Fri, 20 Dec 2013 19:33:45 +0100, Sébastien Villemot wrote:
> Anyways, before we reach a consensus on that issue, would that be
> acceptable for everyone if I upload 3.8.0-rc1 in its current state (i.e.
> no splitting)? We can always decide to split later, since we are
> targeting experimental for the time being.

Thanks for uploading the rc1 and rc2 packages.

One minor issue I've noticed with the new release is the way the JRE is
dynamically linked in. With this configure option in debian/rules

  --with-java-homedir=/usr/lib/jvm/default-java/

you might think it would use only that path for Java support, but in
fact the following path is a built-in string in liboctinterp.so.2

  /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server

The result is that the binary package actually depends on the version of
Java that was the default-jdk when it was built, and not what
default-jre-headless is at run time. Fixing the build to only use the
default-java path should help with maintainability and might avoid
potential bugs.

Adding the option

  --with-java-libdir=/usr/lib/jvm/default-java/jre/lib/amd64/server

to my configure command fixes that. This would of course need to be
parameterized in some way to work on all ports, I'm not sure at the
moment what that would look like. Perhaps this should also be reported
upstream?

Secondly, I've noticed that installed forge packages remain installed,
but may not work with the updated octave packages. In particular,
oct-files are no longer on the path. I don't know if this has been
addressed previously, call for a binnmu on all forge packages?

Cheers,

-- 
mike