Re: packaging system

[Søren Hauberg]

Hi
First a warning: this post is way to long, so feel free to skip it...

As I've said earlier I've written a first draft of an implementation. So 
 I thought I'd give an overview of what this currently does, so here goes:

Installation:

1)  Unpack the archive
2)  Read the DESCRIPTION file
3)  Make sure the package isn't already installed
    (should it be possible to install two versions of the same package?)
4)  Check dependencies
5)  If a file named pre-install.m is shipped with the package,
    call it from Octave. pre-install will be given information about
    the installation. Note: it is not allowed to change this information
    (more on this later).
6)  If the subdirectory src exists and it contains a file named
    configure,
    execute: ./configure --prefix=INSTALLDIR
7)  If the subdirectory src exists and it contains a file named
    Makefile, execute: "make" and "make install".
    (Note: the install target is supposed to copy files to a directory
     called inst. The package installer will copy files from inst to the
     installation directory. When make and make install is executed an
     environment variable INSTALLDIR will exist).
8)  Copy all files in the directory inst to the installation directory.
9)  If a file called INDEX is shipped with the package copy it to the
    installation directory. If not one will be autogenerated based on
    the information in DESCRIPTION.
10) Add the following line to ~/.octave-packages:
    INSTALLDIR/PACKAGENAME-VERSION
    This is the only real book-keeping that's being done.
11) If a post-install.m is shipped with the package call it (it will be
    given information about the package as arguments).
12) Besides this the DESCRIPTION file (and possible the Makefile) will
    be copied to the installation directory.

Note1:
The only real book-keeping that's being done is 
INSTALLDIR/PACKAGENAME-VERSION
being added to ~/.octave-packages. It is easy to extract the package
name and version from this information. It is also easy to modify
Octave's path based on ~/.octave-packages since each line just have to
be added to the path. The problem with this approach is

1) The installation directory has to follow the naming scheme
   PACKAGENAME-VERSION, which is why pre-install can't change the
   installation directory.
2) Dependency checking at uninstall time can't be done only based on
   this information. The uninstaller would have to check all the
   DESCRIPTION files, which is a bit of a pain.
3) Other stuff I haven't realized...

The advantage is that this is easy to implement (took little effort from 
my part), and not much data about the installed packages are kept, 
meaning there's less data to make sure hasn't been corrupted for some 
reason.

Note2:
If no INDEX file is being shipped one will be autogenerated. In this
case the DESCRIPTION must contain a list of categories under which the
function falls (example: "Categories: testing, more testing"). The INDEX
file will then be created like this:
NAME >> TITLE
CATEGORI(1)
  function names

where NAME is the package name, TITLE is a one line description of the 
package, and CATEGORI(1) is the first element of the comma seperated 
list given by Categories.

Note3:
There has been some discussion on toolboxes, that is collection of 
packages. This can be achived by having an empty package that depends on 
the packages that are needed in the toolbox. In order to implement the
"help toolboxname"
functionality, toolboxes would have to ship with a handcrafted INDEX 
file (although we could properly create scripts to ease this task). One 
problem with this approach is that if one of the packages the toolbox 
consist of is updated the toolbox might break or the INDEX file for the 
toolbox might not be correct any longer.

The main question is if such an approach (not necessarily the 
implementation) is good enough, or do we need a more powerful approach 
(this is quite simple, but then again so is the approach used by R - 
this is basicly a copy of the R approach) ?

As always the code is at http://hauberg.org/octave-package

The current implementation works quite well (I'm sure there is bugs I 
haven't seen) on various test packages that I've created.

Once again sorry about the way to long post
/Søren