Re: packaging system

[Stefan van der Walt]

On Sat, Jun 18, 2005 at 01:25:31PM +0200, S?ren Hauberg wrote:
> >It takes a lot of effort to geta system like this into place, so I
> >thought we might as well make it flexible.  That doesn't necessarily
> >mean a lot of additional effort.
> Depends on how flexible it is :-)

True!

> You said in another mail the pre-install.m should be able to alter the 
> installation struct (a structure containing various details on the 
> installation, e.g. installation directory etc). This would give the 
> packager alot of power, but why should the packager be able to alter the 
> installation directory?

The idea was that you could send the structure through a couple of
processes, and at the end of it simply feed it to the installer.  I
remember, for example, that you said you might want to install to a
non-standard directory.  Now, all you need to do is create an
installer that sets that field in the struct.  But yes, if the package
maintainer can manipulate those fields it might give him too much
power.  Then again, so does allowing him to do system("...").

> My concern is that if we give the packager to much power, the 
> installation script will have to perform alot of checking on what the 
> package does to make sure it doesn't screw things up. Of course, if the 
> packager doesn't have enough power the package system ends up unused.

Octave's security is (by default) weak.  Users are allowed to do
almost anything -- so any script you run, you are basically at the
coder's mercy.  Maybe we can anly allow pre- and post- install access
to a select subset of functions?  How would one do this?  We don't
have namespaces.  Maybe a special mode for Octave?  Like octave
--install scriptname.m.

> >>P.S. Where can I get some information on the INDEX format
> >It's a very simple format -- look at the files included with Octave
> >Forge.  We have C++, Octave and Python parsers for it already :)
> OK, so this is a file format to list which packages contains which 
> files, right? I don't see the advantage of using this fileformat instead 
> of putting the files from different packages in seperate directories. Am 
> I missing the obvious?

INDEX files are specifically aimed at describing toolboxes and their
content.  You can have many packages contributing functions to a
single toolbox.

Regards
Stefan