Re: [Pkg-octave-devel] Status of the octaviz package
Hi,
I spent some time over the weekend with Octaviz (and now I know more
about shared libs than I ever wanted to).
Short summary for people new to this: current Octaviz packages put a
shared library under /usr/lib/octave-x.y.z, where x.y.z is determined at
comile time. If Octave is upgraded, Octaviz can't find this library
anymore and breaks; thus, for every new version of Octave, a new version
of Octaviz is needed.
> 1) Check the Debian Policy about putting libraries in /usr/lib from
> packages that do not really provide general purpose libraries
> (liboctaviz is very specific to Octave and Octaviz).
This is probably not possible (putting into /usr/lib). Quote from Policy
10.2:
"Shared object files (often .so files) that are not public libraries,
that is, they are not meant to be linked to by third party executables
(binaries of other packages), should be installed in subdirectories of
the /usr/lib directory. Such files are exempt from the rules that govern
ordinary shared libraries, except that they must not be installed
executable and should be stripped."
> 2) Since Octaviz is compiled against the version of Octave currently
> in
> sid, if the package installs the library in /usr/lib, it may break
> with future versions of Octave. I already asked in
> octave-maintainers
> if it is possible to make the /usr/lib/octave-<version> directory
> "API-versioned", but I got no response.
I took a different approach. The library (liboctaviz.so) is put
under /usr/lib/octaviz/ and the relevant .oct files get this directory
as an -rpath setting. AFAIK, setting/using rpath is not liked very much
in Debian. However, I think the conditions mentioned in the following
mail are fulfilled for Octaviz:
http://lists.debian.org/debian-devel/2002/07/msg02030.html
The packag works as far as I can test it (compiled on Sarge).
Unfortunately, I can't test it directly on unstable, due to the moving
oct libvtk4 to libvtk4c2.
Any suggestions?
Regards
Thomas
Reply to: