Re: packaging system

[Søren Hauberg]

I don't think we should make security an issue, if the packager want's 
to screw things up it will be possible (using system(...), the Makefile, 
 configure, ...). We should however be careful not to make it to easy 
to screw things up by mistake (I'm assuming most packagers are not evil).

I still don't see why the packager should control where stuff get's 
installed (the user should control this). But since this only requires a 
small change in code, I'll implement it, and then we'll see.

So the installation structure will contain:
 *) install_dir (installation directory)
 *) name (package name)
 *) version (package version)
 *) What else...?

The pre-install.m file should contain a function:
function install_struct = pre_install(install_struct)

The file post-install.m file should contain a function:
function post-install(install_struct)

I'll write again when this is implemented
/Søren

Stefan van der Walt wrote:
> 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