Re: packaging system

[Stefan van der Walt]

Hi Soren

On Sat, Jun 18, 2005 at 11:51:09AM +0200, S?ren Hauberg wrote:
> I'm going to need a little hand-holding here, as don't quite understand 
> your post.

Sorry, I'll try to be a bit clearer.

> You want the installation routine to (before installation) check if a 
> file called pre-install.m exist, and if it does run it from Octave, 
> right? If so then that's just a minor change that can be done in a 
> minute. You also want a similar post-install.m, to be executed at the 
> end of installation? (btw, should these be .m files or shell
> scripts?)

Yes, that's the idea.  Each function (pre-install.m and
post-install.m) should take one argument: the struct describing all
aspects of the installation -- e.g. installation directory etc. etc.

> What I don't get is what these scripts should do. Could you
  elaborate a bit?

That is for the package admin to decide.  It gives him the flexibility
to change the installation in any way he requires, by executing
commands before and after the installation, and also by modifying the
installation struct.

For example, say a package requires that a certain file is present on
the system before installation, that can be done in the pre-install.m
(in addition to the standard package dependencies)

Or, after an installation, some special linking of devices or files
might be requires, which post-install.m can handle.

It's just intended as a way to generalise the process a bit.  I think
it's easier to implement such functionality in Octave than it would be
in a Makefile.  We can add a few choice functions to aid in that
process.

I might have missed it, but how do we intend to keep an index of all
functions installed?  Something that can aid in listing the contents
of toolboxes etc.  Paul Kienzle proposed the INDEX format, currently
used my Octave Forge -- it might be worth taking a look at it, or
using something similar.

Regards
Stefan

> 
> Stefan van der Walt wrote:
> >I still think that something like a pre- and post-install script would
> >be useful.  Why stop at being able to modify the installation prefix?
> >Why not create a standard structure with all installation variables,
> >populated before installation starts.
> >
> >The installing package then has an opportunity to modify this struct
> >in the pre-install script after which installation takes place.
> >Afterwards, the post-install script can do any additional
> >admin/cleanup needed while having access to that information still.
> >
> >Your package has everything in place to do this already.  It would
> >just require some minor modifications.
> >
> >Regards
> >Stefan
> >
> >On Fri, Jun 17, 2005 at 11:01:35PM +0200, S?ren Hauberg wrote:
> >
> >>Hi
> >>I've updated the code (it's still at http://hauberg.org/octave-package), 
> >>with the following changes:
> >>*) If the archive contains a directory, cd to that directory. This means 
> >>that package can keep it's files in a directory (e.g. PACKAGE-VERSION).
> >>*) A bit more error checking. Not enough though
> >>*) Support for uninstallation of packages. No dependency checking is 
> >>done during uninstallation.
> >>*) The installation prefix is defined by the global variable 
> >>OCTAVE_PACKAGE_PREFIX. If this variable is not defined an error is 
> >>issued. Packages will be install in OCTAVE_VALUE_PREFIX/PACKAGE-VERSION
> >>
> >>As long as the packages doesn't have to many errors the code is usable 
> >>in it's current state.
> >>
> >>/Søren
> >>
> >
> >
>