packaging system

classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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
>

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

Søren Hauberg
Søren Hauberg wrote:
[snip]
> I'll write again when this is implemented
It is now implemented!

>> INDEX files are specifically aimed at describing toolboxes and their
>> content.  You can have many packages contributing functions to a
>> single toolbox.
Should the package system know about toolboxes? Couldn't a toolbox
simply be an empty package that depends on the packages that define the
toolbox?

/Søren

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

Stéfan van der Walt
On Sat, Jun 18, 2005 at 02:14:03PM +0200, S?ren Hauberg wrote:
> Søren Hauberg wrote:
> [snip]
> >I'll write again when this is implemented
> It is now implemented!

Excellent!

> >>INDEX files are specifically aimed at describing toolboxes and their
> >>content.  You can have many packages contributing functions to a
> >>single toolbox.
> Should the package system know about toolboxes? Couldn't a toolbox
> simply be an empty package that depends on the packages that define the
> toolbox?

In the end, one should be able to do

help('toolboxname')

And get something similar to the MATLAB output:

Signal Processing Toolbox

funname - Short Description

The Short Description can be dynamically extracted from each file on
its own -- we just need the funname -> toolbox relationship, as well
as toolbox descriptions.  If the package structure offers this, it's fine.

Regards
Stefan

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

Søren Hauberg
Stefan van der Walt wrote:
[snip]

> In the end, one should be able to do
>
> help('toolboxname')
>
> And get something similar to the MATLAB output:
>
> Signal Processing Toolbox
>
> funname - Short Description
>
> The Short Description can be dynamically extracted from each file on
> its own -- we just need the funname -> toolbox relationship, as well
> as toolbox descriptions.  If the package structure offers this, it's fine.
I see. I didn't know matlab had such a functionality. The package
structure offers the same, but only per package. So if a toolbox
consists of several packages, there would be a need for a
toolbox -> package1, ..., packageN
relationship.

So the question is, to which extend should packages and toolboxes
differ? Do we need toolboxes if we have packages?

/Søren
> Regards
> Stefan
>

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

John W. Eaton-6
On 18-Jun-2005, Søren Hauberg wrote:

| So the question is, to which extend should packages and toolboxes
| differ? Do we need toolboxes if we have packages?

I don't see why we would.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

Stéfan van der Walt
On Sat, Jun 18, 2005 at 11:41:50AM -0400, John W. Eaton wrote:
> On 18-Jun-2005, Søren Hauberg wrote:
>
> | So the question is, to which extend should packages and toolboxes
> | differ? Do we need toolboxes if we have packages?
>
> I don't see why we would.

So, you'd like to limit a package to one toolbox?  That doesn't make
sense to me.

Regards
Stefan

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

John W. Eaton-6
On 18-Jun-2005, Stefan van der Walt wrote:

| On Sat, Jun 18, 2005 at 11:41:50AM -0400, John W. Eaton wrote:
| > On 18-Jun-2005, Søren Hauberg wrote:
| >
| > | So the question is, to which extend should packages and toolboxes
| > | differ? Do we need toolboxes if we have packages?
| >
| > I don't see why we would.
|
| So, you'd like to limit a package to one toolbox?  That doesn't make
| sense to me.

Hmm.  It does to me.  If we implement dependencies in the package
system, then there is nothing preventing you from installing a package
that doesn't actually have any files of its own, but depends on
several other packages.  If you'd like, you can call your
dependency-only package a "toolbox".  I see no reason to complicate
things by introducing the concept of a "toolbox" as something that is
somehow different from a "package".  It seems to me that both are just
collections of functions.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

Stéfan van der Walt
On Sat, Jun 18, 2005 at 02:03:03PM -0400, John W. Eaton wrote:
> Hmm.  It does to me.  If we implement dependencies in the package
> system, then there is nothing preventing you from installing a package
> that doesn't actually have any files of its own, but depends on
> several other packages.  If you'd like, you can call your
> dependency-only package a "toolbox".  I see no reason to complicate
> things by introducing the concept of a "toolbox" as something that is
> somehow different from a "package".  It seems to me that both are just
> collections of functions.

Here's a scenario: I have a group of signal processing functions that
are not yet included in Octave.  Since the signal processing package
already exists, what do I call this?

How about a toolbox field in the package description then?

Regards
Stefan

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

Søren Hauberg
In reply to this post by John W. Eaton-6
John W. Eaton wrote:
[snip]
> Hmm.  It does to me.  If we implement dependencies in the package
> system, then there is nothing preventing you from installing a package
> that doesn't actually have any files of its own, but depends on
> several other packages.  If you'd like, you can call your
> dependency-only package a "toolbox".  I see no reason to complicate
> things by introducing the concept of a "toolbox" as something that is
> somehow different from a "package".  It seems to me that both are just
> collections of functions.
My main problem is that I want to avoid having to do too much
book-keeping. If we want to implement the
        help("toolboxname")
functionality, we have a problem with the "empty package" with many
dependencies. With out any special book-keeping the above help function
wouldn't present any functions since the toolbox doesn't provide any
functions.

Introducing a toolbox field in DESCRIPTION doesn't make sense to as the
package would then need to know which packages depends  on it.

The way I see things there are two options
1) Don't do toolboxes at all.
2) Start doing book-keeping. That is, introduce a some sort of graph
structure to keep track of dependencies.

Neither of these solutions appeal to me :-(

BTW, I'm having some problems with expressing myself since I'm a bit
hung over from last night. So, if I'm not making any sense just tell me ...

/Søren

>
> jwe
>

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

Stéfan van der Walt
Hi Soren

On Sun, Jun 19, 2005 at 12:26:14PM +0200, Søren Hauberg wrote:
> Introducing a toolbox field in DESCRIPTION doesn't make sense to as the
> package would then need to know which packages depends  on it.

Why?  There are a set set of toolboxes.  Your package must just know
to which toolbox it contributes?  The problem that we were discussing
earlier, is what happens when your package contributes to more than
one toolbox.

Anyway, I don't see it being a major hassle: include an INDEX file
with each package, and let Octave parse those index files whenever
someone wants help('toolbox').  We have the code to do so already.

Regards
Stéfan

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

Søren Hauberg
Stefan van der Walt wrote:
> On Sun, Jun 19, 2005 at 12:26:14PM +0200, Søren Hauberg wrote:
>>Introducing a toolbox field in DESCRIPTION doesn't make sense to as the
>>package would then need to know which packages depends  on it.
>
> Why?  There are a set set of toolboxes.  Your package must just know
> to which toolbox it contributes?  The problem that we were discussing
> earlier, is what happens when your package contributes to more than
> one toolbox.
If I write a package and someone else desides to create another package
that uses my packagee, how would I know?

> Anyway, I don't see it being a major hassle: include an INDEX file
> with each package, and let Octave parse those index files whenever
> someone wants help('toolbox').  We have the code to do so already.
I guess we can do that - I just don't see why. All the functions in a
package can be found in a seperate directory, so we have the information
the INDEX file would contain available. Or, are you suggesting that the
INDEX file also would include the functions from the dependend packages?

/Søren
> Regards
> Stéfan
>

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

Stéfan van der Walt
On Sun, Jun 19, 2005 at 08:06:24PM +0200, Søren Hauberg wrote:
> Stefan van der Walt wrote:
> >Why?  There are a set set of toolboxes.  Your package must just know
> >to which toolbox it contributes?  The problem that we were discussing
> >earlier, is what happens when your package contributes to more than
> >one toolbox.
> If I write a package and someone else desides to create another package
> that uses my packagee, how would I know?

I think we are missing each other here.  I don't see why that should matter?

> I guess we can do that - I just don't see why. All the functions in a
> package can be found in a seperate directory, so we have the information
> the INDEX file would contain available. Or, are you suggesting that the
> INDEX file also would include the functions from the dependend packages?

In the above paragraph you are making the assumption that any package
contains functions from only one toolbox, and vice versa (i.e. any
toolbox is made up of only one package).

If this is a design constraint that we specify beforehand, I think it
should be well motivated.  We must also keep in mind that packages
will not only be used by the official distributions -- people might
use it to create custom Octave distributions etc.

As I mentioned to John, it is not unreasonable to expect packages to
contain functions that complement an already existing toolbox.  Thus,
the toolbox and the package should be different entities.

Regards
Stefan

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

Bill Denney
In reply to this post by Stéfan van der Walt
On Sun, 19 Jun 2005, Stefan van der Walt wrote:

> Anyway, I don't see it being a major hassle: include an INDEX file
> with each package, and let Octave parse those index files whenever
> someone wants help('toolbox').  We have the code to do so already.

Here's what strikes me as the simplest solution: a modification to the
help function.

Toolboxes could work as follows:

They become packages with no specific functions.  When a package is part
of a toolbox, it is symlinked into the toolbox directory, and within the
toolbox directory is effectively nothing.  Then, when "help toolboxname"
is called, it will scan each subdirectory for functions.  This could be
done as follows:

OCTAVE_PACKAGE_DIR/package-1.1/
OCTAVE_PACKAGE_DIR/package2-4.8/
OCTAVE_PACKAGE_DIR/toolbox-1.0/
                                package-1.1 -> ../package-1.1
                                package2-4.8 -> ../package2-4.8

where the package directories are symlinks.

Another option would be to have a similar functionality, but have a single
file in the toolbox-1.0 directory (along with the package symlinks) named
toolbox.m (where toolbox is the name of the toolbox).  This file would
give a brief description when help is run on it, and perhaps tell you to
run it as as "toolbox" from the command line to get a list of functions
(where toolbox.m could be essentially generic with the exception of the
description).

Symlinks may interfere with octave's function finding routines (i.e. there
would be two locations in the directory tree where the same file is
located), so simply having each package drop a file into the toolkit
directory may work.

Bill

--
THE VIRTUAL WORLD NEWS -- "Hey, it's words, punctuation marks,
                            paragraphs--practically the New York Times!"

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

Stéfan van der Walt
On Sun, Jun 19, 2005 at 09:30:31PM -0400, Bill Denney wrote:

> On Sun, 19 Jun 2005, Stefan van der Walt wrote:
>
> >Anyway, I don't see it being a major hassle: include an INDEX file
> >with each package, and let Octave parse those index files whenever
> >someone wants help('toolbox').  We have the code to do so already.
>
> Here's what strikes me as the simplest solution: a modification to the
> help function.
>
> Toolboxes could work as follows:
>
> They become packages with no specific functions.  When a package is part
> of a toolbox, it is symlinked into the toolbox directory, and within the
> toolbox directory is effectively nothing.  Then, when "help toolboxname"
> is called, it will scan each subdirectory for functions.  This could be
> done as follows:

That's an interesting idea.  Another factor to take into account is
that toolboxes are divided into Categories.  The reason we have INDEX
files for octave forge is so that we can do classification of the
functions.  Quoting from main INDEX file:

# An index file has the following format:
#
#  toolbox >> Toolbox name
#  Category Name
#   fn fn fn
#   fn fn fn
#  Category Name
#   fn
#
# Toolbox and category definitions are on the left, function
# lists are indented.
#
# If no toolbox is specified, then the categories will go into
# extra.  Only use this if you are contributing a small number
# of specialized functions.

system >> System Utilities
Clock functions
 now
 date
 clock
 cputime
 tic
 toc
 etime gmtime
 ctime time localtime mktime
Date conversion
 is_leap_year
 asctime
 datenum
 datestr
 datevec
 weekday
 eomday

etc.

This isn't something that has to implement immediately, but since we
are designing a packaging structure, I believe it's worth taking into
account.

Regards
Stéfan

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

Søren Hauberg
In reply to this post by Bill Denney
Sorry about taking my time replying, but the weather is great in Denmark
  :-)

Bill Denney wrote:

> Toolboxes could work as follows:
>
> They become packages with no specific functions.  When a package is part
> of a toolbox, it is symlinked into the toolbox directory, and within the
> toolbox directory is effectively nothing.  Then, when "help toolboxname"
> is called, it will scan each subdirectory for functions.  This could be
> done as follows:
>
> OCTAVE_PACKAGE_DIR/package-1.1/
> OCTAVE_PACKAGE_DIR/package2-4.8/
> OCTAVE_PACKAGE_DIR/toolbox-1.0/
>                                package-1.1 -> ../package-1.1
>                                package2-4.8 -> ../package2-4.8
>
> where the package directories are symlinks.
Couldn't this create an infinite loop?

OCTAVE_PACKAGE_DIR/package-1.1/
                                package2-4.8 -> ../package2-4.8
OCTAVE_PACKAGE_DIR/package2-4.8/
                                package-1.1 -> ../package-1.1


> Another option would be to have a similar functionality, but have a
> single file in the toolbox-1.0 directory (along with the package
> symlinks) named toolbox.m (where toolbox is the name of the toolbox).  
> This file would give a brief description when help is run on it, and
> perhaps tell you to run it as as "toolbox" from the command line to get
> a list of functions (where toolbox.m could be essentially generic with
> the exception of the description).
In the end this is properly a good solution, the problem is that this
solution is very static. If the toolbox uses function F from package P
and P is updated with a change in F, then the toolbox would have to be
updated as well to reflect this change.

/Søren

> Symlinks may interfere with octave's function finding routines (i.e.
> there would be two locations in the directory tree where the same file
> is located), so simply having each package drop a file into the toolkit
> directory may work.
>
> Bill
>

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

Søren Hauberg
In reply to this post by Stéfan van der Walt
Stefan van der Walt wrote:
> That's an interesting idea.  Another factor to take into account is
> that toolboxes are divided into Categories.  The reason we have INDEX
> files for octave forge is so that we can do classification of the
> functions.  Quoting from main INDEX file:
I'm beginning to see why you are so keen on using the INDEX format. The
categories seem nice.
I do however don't like the idea of forcing people to create INDEX files
(it seems like a very boring thing to do), so if the INDEX format is to
be used I think we should have scripts to auto-generate such files. This
should be possible, right?

/Søren

>
> # An index file has the following format:
> #
> #  toolbox >> Toolbox name
> #  Category Name
> #   fn fn fn
> #   fn fn fn
> #  Category Name
> #   fn
> #
> # Toolbox and category definitions are on the left, function
> # lists are indented.
> #
> # If no toolbox is specified, then the categories will go into
> # extra.  Only use this if you are contributing a small number
> # of specialized functions.
>
> system >> System Utilities
> Clock functions
>  now
>  date
>  clock
>  cputime
>  tic
>  toc
>  etime gmtime
>  ctime time localtime mktime
> Date conversion
>  is_leap_year
>  asctime
>  datenum
>  datestr
>  datevec
>  weekday
>  eomday
>
> etc.
>
> This isn't something that has to implement immediately, but since we
> are designing a packaging structure, I believe it's worth taking into
> account.
>
> Regards
> Stéfan
>

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

Stéfan van der Walt
On Mon, Jun 20, 2005 at 08:40:57PM +0200, Søren Hauberg wrote:
> I do however don't like the idea of forcing people to create INDEX files
> (it seems like a very boring thing to do), so if the INDEX format is to
> be used I think we should have scripts to auto-generate such files. This
> should be possible, right?

It should be little or no trouble at all:

echo "Packagename >> Description" > INDEX
echo "Misc" >> INDEX
for f in `find . -name "*.m"`; do echo `basename $f .m`; done >> INDEX

Regards
Stéfan

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

Paul Kienzle
In reply to this post by Søren Hauberg

On Jun 20, 2005, at 2:40 PM, Søren Hauberg wrote:

> Stefan van der Walt wrote:
>> That's an interesting idea.  Another factor to take into account is
>> that toolboxes are divided into Categories.  The reason we have INDEX
>> files for octave forge is so that we can do classification of the
>> functions.  Quoting from main INDEX file:
> I'm beginning to see why you are so keen on using the INDEX format.
> The categories seem nice.
> I do however don't like the idea of forcing people to create INDEX
> files (it seems like a very boring thing to do), so if the INDEX
> format is to be used I think we should have scripts to auto-generate
> such files. This should be possible, right?

Being responsible for the initial cut, I can attest to its tedium.  It
also needs constant maintenance as functions get added and removed.  
The admin/make_index tool on octave-forge warns about unindexed and
missing functions.

In the absence of an INDEX file for a directory it would be easy to
treat all indexed functions as belonging to the same category.  You
need to get the category description from somewhere though.

The INDEX spec allows you to place the same function in multiple
categories.  E.g., some of the signal processing functions might also
be useful in image processing, so could be listed twice.  This
hopefully makes it easier for users to find what they need.  The
alphabetical list should only list each function once.

You can run make_index in a subdirectory to build a contents.m file in
the usual Matlab style.  INDEX could be one part of a larger
documentation system, with detailed docs for each category and tools
for automatically pulling together the category docs into a complete
manual.


= {ai;

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

Søren Hauberg
In reply to this post by John W. Eaton-6
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

Reply | Threaded
Open this post in threaded view
|

Re: packaging system

David Bateman-3
Søren,

I think a bit more complete dependency checking code might be good idea
to get into place early to save us some pain later. At the moment you
have a line "Depends:" in the DESCRIPTION file, that contains a list of
all packages that the current package depends on. May I suggest that
each package dependency has a seperate "Depends:" line of the form

Depends: PACKAGE [<|=|>] VERSION

to take into account the possible need for a particular version of a
package or newer than, or range of versions.. For example you might have

Depends: Signal >= 1.0.0
Depends: Signal < 2.0.0

To say that the current package needs version 1.x for the package
"Signal" and not any previous or newer versions, or

Depends: StupidPackage = 1.0.1

to say that version 1.0.1 of StupidPackage is the only one that is known
to work with the new package.

There are also issues of upgrading packages and circular dependencies
that might prevent installation. The way around this is to allow the
install/uninstall scripts to accept cell-arrays that have a list of the
packages to install/uninstall. The first thing to do in that case would
be to gather all of the existing, upgraded and new DESCRIPTION files and
check that the dependencies after the install will be met, and only then
start the install/uninstall of all of the packaging in the cell array.
So a typical call might be "install ({'Comm', 'Signal'});" to allow the
installation of Comm and Signal is each depends on the other. I don't
think we want to get fancy and automatically install dependent packages
as this means that we'd need a mechanism to automatically download
packages from within octave itself, which would just add another thing
octave depends on.

As for dependency check on uninstall, I see no issues in traversing the
package tree reading all of the DESCRIPTION files. I don't believe it
will be that slow. Getting the dependency stuff right will save us a lot
of pain in the future so I see this as time well spent (though I
understand its your time and not mine).

One further point, your install scription introduces a new dependency of
octave on the external application "tar". Are there any other new
dependencies? How will this dependency be handled in a cygwin build?
What about a mingw build? This might cause issues..... However, its a
secondary point...

In any case great job, as this is something that has been needed for a
long time...

Cheers
David

--
David Bateman                                [hidden email]
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph)
Parc Les Algorithmes, Commune de St Aubin    +33 1 69 35 77 01 (Fax)
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary

123