/!\ The content of this page is obsolete and kept only for historical reasons

Packaging Octave and its add-ons for Debian

The Octave packages are collectively maintained by the DOG (Debian Octave Group). This page should be used to coordinate the efforts in packaging the infrastructure for the Octave packages and add-ons.

[Update by RafaelLaboissiere on 2009-02-18]

The packaging of the Octave-Forge add-ons is done now through the octave-pkg-dev package. I am keeping the material below in this page just for historical reasons.

The new pkg scheme of octave-forge

Version 2.9.10 of Octave has support for the pkg scheme for easily installing third-party packages. Debian users can now, in principle, use this system for installing/uninstalling/upgrading their octave-forge packages. However, the DOG could also offer these octave-forge add-ons as deb packages, freeing the user from the hassle of installing all the software needed to build the packages. Below are some suggestions on how to proceed.

Internals of the pk scheme

(To someone who knows will the pkg scheme: please, put here a summary of how it works, in particular how the global_list file is generated and used as well as how the functions provided in the package are autoloaded at Octave startup.)

Ideas from ThomasWeber

General question: should we package octave-forge at all? I would say yes, otherwise we must drop all packages that need octave-forge either at build or execution time. Also, things like rebuilds with gcc-snapshots tend to avoid bugs upstream.

changes to pkg.m

I think we should try to expand pkg.m as much as possible for our needs. This has the benefit that we don't divert too much from upstream and that other distributions (Fedora) might be able to use this as well (obviously, changes should be pushed upstream).

Currently, an installed package consists of a single subdirectory, where all file (.oct, .m, ...) of a package go. While we can influence the subdirectory, we cannot split the content up. This makes it impossible to fulfill the FHS (very rough summary: architecture dependent files must go under /usr/lib, arch-independent files under /usr/share). This might be solvable via a few regular expressions and some dh_* magic for installation, but I'm not sure about de-installation. Or we ignore the global package list and put all files under directories where Octave finds them without any list file.

Installed packages should be autoloaded, no matter what the package says: I can hardly imagine installing a package and then not using it. (Well, consider a multi-user system or server. One user wants to work with SDPs, and another wants to work with FFTs. Why should each have their workspaces cluttered with the others' packages?) (Autoloading means just adding an entry to an internal variable telling which file is associated with which function. Calling this cluttering the workspace is an exageration -- RafaelLaboissiere)

Also, it's impossible to pass flags to configure. I don't know if there are packages that need external libraries, but I guess passing flags should be possible. My current favorite solution is the possibility of passing a struct to pkg(), which would make the package manager easily expandable (just add a new element to the struct). I'm however unsure how to integrate this with the way pkg.m parses its arguments.

Package dependencies are probably best ignored (using -nodeps). We can handle them easily within apt/dpkg. (Agreed -- RafaelLaboissiere)

package names

Names like octave-forge-physicalconstants are too long - should we drop the "forge" part for the packages? (Definitely yes! -- RafaelLaboissiere)

Ideas from RafaelLaboissiere

One of the keys to making this project successful is understanding how the global_list can be manipulated when a Debian package is installed/removed. It seems that the whole pkg scheme depends on the contents of this file (well, there is also the local_list file, but this is outside the realm of Debian packaging).

Well, I dont know much about this but it seems to me that both global_list and local_list are defined manually in pkg.m and that they are variables (persistent variables, whatever that means) and not files. Am I wrong in this? (?OlafurSigurdsson)

Variables declared persistent in a function retain their value in memory across different calls of the function. Of course, they disapear when Octave exits. In pkg.m, the global list is a structure which is stored in a file whose name is in the global_list string variable (which is, btw, persistent). I think (and hope) that it should be possible to manipulate the contents of this file in the postinst and postrm scripts (RafaelLaboissiere).

Suggestions from David Bateman

[The following was originally posted in the Octave maintainers mailing list on 2007-04-19. -- RafaelLaboissiere]

I had a look at your wiki, and yes you do need to manipulate the global and local lists to make a binary package. I tried to think ahead of the packaging issues and included an RPM example building process in octave-forge itself. I doubt it will work correctly under debian, but if you do "make srpms" under octave-forge it will build a set of source RPMS that could be used as an example of what I'm currently using on my system. Sorry I couldn't do the same for deb files as I don't understand debian packaging.

The %prep and %build sections of the SPEC file for one of the packages looks like

rm -fr signal-1.0.0
mkdir signal-1.0.0
cd signal-1.0.0
cp %{_sourcedir}/signal-1.0.0.tar.gz .
chmod a+r signal-1.0.0.tar.gz
mkdir -p install/signal
mkdir install/signal/inst

cd signal-1.0.0
HOME=`pwd` %{octave} -H -q --no-site-file --eval
cd install
mv signal-1.0.0/packinfo/* signal
rm -rf signal-1.0.0/packinfo
if [ -d signal-1.0.0/doc ]; then mv signal-1.0.0/doc signal; fi
if [ -d signal-1.0.0/bin ]; then mv signal-1.0.0/bin signal; fi
if [ -e signal-1.0.0/PKG_ADD ]; then mv signal-1.0.0/PKG_ADD signal; fi
if [ -e signal-1.0.0/PKG_DEL ]; then mv signal-1.0.0/PKG_DEL signal; fi
mv signal-1.0.0/* signal/inst
rm -fr signal-1.0.0.tar.gz
tar czf ../%{builtpackage} signal

where %{builtpackage} is now a binary package that can later be installed by the package manager. The section of the SPEC control this is

cd signal-1.0.0
rm -rf %{buildroot}
mkdir -p %{buildroot}%{_datadir}
cp %{builtpackage} %{buildroot}%{_datadir}

%{octave} -H -q --no-site-file --eval
rm %{_datadir}/%{builtpackage}

So to build the binary package out of the normal directories, you must

  1. Set the HOME variable to the build directory
  2. Set both the local_list and the global_list variables (to be sure) to point to a package file in the build directory that will later be removed

  3. Run the pkg install command on the source package

  4. Reconstruct a package from the installed package essentially copying everything from the install directory to the new packages /inst directory and relocating a few other files and directories.

Note there is also a section to supply hints to building the packages on the dependencies that the automatic SRPM build process attempts to use. Ideally I'd like to see some sort of automatic deb build process in octave-forge itself in a similar manner to the RPM process. Sure I know these will almost always need manual editing, but at least having most of the grunt work of building packages of the distributions would be a good thing.

Work done by Ólafur Jens Sigurðsson

Ólafur has already started to package the octave-forge components. His preliminary worked is already in SVN. Most of the packages are now in unstable/testing. See here.