[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: packaging system
From: |
Søren Hauberg |
Subject: |
Re: packaging system |
Date: |
Tue, 21 Jun 2005 21:35:05 +0200 |
User-agent: |
Mozilla Thunderbird 1.0.2 (X11/20050404) |
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
- Re: packaging system, (continued)
- Re: packaging system, Bill Denney, 2005/06/19
- Re: packaging system, Stefan van der Walt, 2005/06/20
- Re: packaging system, Søren Hauberg, 2005/06/20
- Re: packaging system, Stefan van der Walt, 2005/06/20
- Re: packaging system, Paul Kienzle, 2005/06/20
- Re: packaging system, Søren Hauberg, 2005/06/20
- Re: packaging system,
Søren Hauberg <=
- Re: packaging system, David Bateman, 2005/06/22
- Re: packaging system, Stefan van der Walt, 2005/06/22
- Re: packaging system, David Bateman, 2005/06/22
- Re: packaging system, Stefan van der Walt, 2005/06/22
- Re: packaging system, David Bateman, 2005/06/22
- Re: packaging system, Bill Denney, 2005/06/22
- Re: packaging system, Stefan van der Walt, 2005/06/22
- Re: packaging system, Stefan van der Walt, 2005/06/22
- Re: packaging system, Søren Hauberg, 2005/06/22
- Re: packaging system, David Bateman, 2005/06/22