Changes

Jump to navigation Jump to search
2,799 bytes added ,  17:48, 18 November 2012
expanding explanantion of type of installs and one more user case
Line 7: Line 7:  
This document attempts to design a solution for this.
 
This document attempts to design a solution for this.
   −
The main idea of the solution is to keep database files with each package location
+
The main idea is to have multiple databases with information from installed packages
and dependencies, and allow for the merge of such files.
+
in different locations in the filesystem. While this is similar to the current implementation,
 +
we plan to design solutions for when package installations clash.
   −
To allow reinstallation of the packages, we propose to keep the source of the package.
+
This proposal also suggests to keep the source of the packages. This will allow for
This would also make it easier to run the tests of packages.
+
easy reinstall of packages (after an Octave upgrade) and test of .oct files from
 +
packages (since their tests are in the .cc sources).
   −
== Rationale and examples ==
+
== Rationale ==
This design is meant to allow the following:
+
This design is meant to make allow the following:
  * keeping multiple versions of the same package installed and load a specific one
+
* keep multiple versions of the same package installed side-by-side
  * keep packages installed for multiple versions of Octave, specially in the case of
+
* keep multiple versions of Octave in a system using the same installed packages
    .oct files which need to be rebuilt for each octave function
+
* deal with dependencies correctly when multiple Octave and packages co-exist
  * reinstall a package from its cache after installing new octave version
+
* allow use of packages that may have been installed anywhere
  * run the tests from packages (find tests in .cc sources)
+
* reinstall a package
  * clean the package cache
+
* test installed packages
  * usage of alternate database files
+
 
  * usage of packages in remote directories which may not be available at all
+
See the user cases section below for several examples.
    times
      
== Available vs Loaded ==
 
== Available vs Loaded ==
 
To avoid problems reading this document, the distinction between available and loaded
 
To avoid problems reading this document, the distinction between available and loaded
package should be done early. An available package is a package that is currently
+
package should be done early.
available to pkg to loading, unloading or reinstall. It is already installed but not necessarily loaded.
+
 
A loaded package is an installed package whose functions have been added to Octave's function search
+
An available package is a package that is currently available to pkg for loading,
path.
+
unloading or reinstall. It is already installed but not necessarily loaded.
 +
 
 +
A loaded package is an installed package whose functions have been added to Octave's
 +
function search path.
    
== Types of package installs ==
 
== Types of package installs ==
This design supports 3 types of package installations: global (relative to the octave installation), local (user specific) and external (in any other place). Note that Octave itself can be installed in some different ways. It might be a system-wide installation (located somewhere in /usr/local/ for example), a local installation of a normal user (somewhere on /home/user/anywhere), or installed in the home directory of a system user (can be anywhere).
+
This design supports 3 types of package installations: global (relative to the
 +
Octave installation), local (user specific) and external (in any other place).
 +
 
 +
;global install
 +
: available from startup to everyone.
 +
;local install
 +
: available from startup only for the user that installed it.
 +
;external install
 +
: needs to be made available first. Octave install has no information about it.
 +
 
 +
Note that Octave itself can be installed in some different ways. It might be a system-wide
 +
installation (located somewhere in {{Path|/usr/local/}} for example), a local installation
 +
of a normal user ({{Path|/home/user/anywhere}}), or installed in the home
 +
directory of a system user (anywhere really).
    
=== Global installs ===
 
=== Global installs ===
 
Packages installed globally will be available to everyone from startup. This is the
 
Packages installed globally will be available to everyone from startup. This is the
type of package installation that a system administrator would do for example. The
+
type of package installation that a system administrator would most likely do. The
 
meaning of global here is relative to the Octave installation though. If an Octave
 
meaning of global here is relative to the Octave installation though. If an Octave
installation is local (installed by a user in ~/usr/local), a global installation
+
installation is local (installed by a user in {{Path|~/my-builds}}), a global installation
 
of a package will still place its files in the home directory of the user (in
 
of a package will still place its files in the home directory of the user (in
~/usr/local/ as well).
+
{{Path|~/my-builds}}).
    
A global installation is performed automatically if the user installing the package
 
A global installation is performed automatically if the user installing the package
has write permissions to those directories (localfcnfiledir and localapioctfiledir).
+
has write permissions to those directories (''localfcnfiledir'' and ''localapioctfiledir'').
 
In case it has no permissions, a local package installation is performed instead.
 
In case it has no permissions, a local package installation is performed instead.
    
=== Local installs ===
 
=== Local installs ===
 
Local packages are specific to a user. They are located in that user home directory
 
Local packages are specific to a user. They are located in that user home directory
into ann .octave directory. As with global package installations, they are available
+
into an {{Path|.octave}} directory. As with global package installations, they are available
 
from startup. Unlike global, they are user specific, only available to the user that
 
from startup. Unlike global, they are user specific, only available to the user that
 
installed it. A local install for a user can be an external install for some other
 
installed it. A local install for a user can be an external install for some other
 
user.
 
user.
 +
 +
This are the type of package installation done by users that want to have the latest
 +
package version before is available in their system repository, but are not going to
 +
build Octave themselves. Also to be used by those who run Octave in a system that they
 +
do not maintain where Octave is installed but not packages.
    
=== External installs ===
 
=== External installs ===
 
These are like local packages but in a non-standard location. Octave does not know
 
These are like local packages but in a non-standard location. Octave does not know
about this installations at startup even if the installation was done with the same
+
about this installations at startup even though they might have been installing the
Octave version. These can be packages installed in a filesystem that is not always
+
same Octave that is running at the moment. These can be packages installed in a
mounted, local packages installs from another user in the same system, or anything
+
filesystem that is not always mounted, local packages installs from another user
else really.
+
in the same system, or anything else really.
   −
An external package was installed with pkg, it is simply not constantly tracked down
+
An external package was still installed with pkg, the difference being that the
by Octave. An external package install will have a .db associated file just like the
+
record is not kept by Octave after it. An external package install will have a db
.db files for the local installs. To load an external package, the path for the .db
+
associated file just like the db files for the local installs. To load an external
file needs to be passed to pkg and the db named. Then packages from there can be
+
package, the path for the db file needs to be passed to pkg and the db named (because
loaded.
+
there may be more than onde db.
   −
For example, after starting an Octave session, one can load two .db files. One is
+
These are most like the less used type of packages and will require a bit more
the labdev (/mnt/labdev/octave_packages.db) and the other is the friendA
+
knowledge (they will need to point pkg to a .db file, that is all). They will be
(/home/friendA/.octave/octave_packages.db). Once these two external db are loaded,
+
mostly used for places that develop their own packages and people who don't want to
the packages associated with it are made available to pkg and can be loaded normally.
+
install the package themselves, instead simply using a local install of others as
It's possible that the same package name and version exists in both dbs hence the
+
an external package.
need to name them (so it's possible to specify from which one should a package be loaded).
+
 
 +
=== Playing nice with downstream packagers ===
 +
The recommended method for installing Octave and its packages is to use their OS packaging
 +
system. Downstream packagers should have the packaging systems make global installs of the
 +
packages. If a user wants to install a new version of a package that is not yet available
 +
on its system repository, it should make a local package install (default since has a normal
 +
user he won't have write permissions to the Octave directory).
 +
 
 +
If the user decides to make a global package install (install the package using pkg while
 +
runnig Octave with sudo), then he's trying to act as system administrator and should know
 +
what he's doing. If he breaks it, its his own fault. Installation of system-wide software
 +
is meant to be handled by the system packaging tool. It is just not possible to make pkg
 +
cover all of them.
 +
 
 +
=== User case #1 ===
 +
Jenny is using Octave on the department cluster. She is not the administrator but
 +
there's already a system-wide installation of Octave with the general and
 +
signal image installed. She starts Octave and has these 2 packages available to
 +
her. These are globally installed packages, available to everyone that starts
 +
Octave.
 +
 
 +
But Jenny also requires the image package and she installs it with "pkg install -forge image". She
 +
does not have permissions to administer the system so the image package is installed
 +
locally in her home directory. When she starts Octave, she now has 3 packages available,
 +
general and signal package which are global (available to everyone that starts Octave), and
 +
the image package which is local (available only to her).
 +
 
 +
Jenny's supervisor is working on a new package (img_analysis) that he makes available
 +
for all his students and wants Jenny to use it. Rather than sending them the packages,
 +
he wants them to use the package he has installed on his own home directory and tells
 +
them to load it as an external package. Jenny uses
 +
"pkg load-db boss /home/supervisor/.octave/octave_packages.db" to make his supervisor
 +
packages available to her. She now has 4 available packages, the new one (img_analysis)
 +
being an external package. However, relative to her supervisor, the same package is a
 +
local installation.
 +
 
 +
The next time she starts Octave, there is no trace of the external packages, pkg still
 +
only have 3 available packages so she adds the "pkg load-db" command to her {{Path|.octaverc}}
 +
file.
 +
 
 +
In this case however, her supervisor would do better in installing his img_analysis package
 +
in some other place to avoid clash with his own local packages. For example, he could
 +
have installed it at {{Path|/home/supervisor/group/octave}}. Or he could have a filesystem
 +
on the network that his students could mount whenever they needed it.
    
== Package names ==
 
== Package names ==
Line 94: Line 159:  
be loaded? I'd propose the default to be:
 
be loaded? I'd propose the default to be:
   −
# load the latest version availale
+
- load the latest version availale
# load the local install of the package
+
- load the local install of the package
# load the global install of the package
+
- load the global install of the package
# load the package from the external .db, starting from the latest added in case there's more than one.
+
- load the package from the external .db, starting from the latest added in case there's more than one.
    
For package names, the proposal is to limit package names to the same as variable
 
For package names, the proposal is to limit package names to the same as variable
Line 105: Line 170:  
it would create problems when installing packages in filesystems that are not case
 
it would create problems when installing packages in filesystems that are not case
 
sensitive (creating directories named Image and image would not be possible in FAT
 
sensitive (creating directories named Image and image would not be possible in FAT
or HFS systems).
+
systems).
 +
 
    
== User cases ==
 
== User cases ==
=== Case 1 ===
+
 
 +
=== User case #2 ===
 
Denise installs Octave 3.4.3 and installs the latest version of the financial (1.0.4) and
 
Denise installs Octave 3.4.3 and installs the latest version of the financial (1.0.4) and
 
image (2.0.0) package with "pkg install -forge financial image". After installing the packages,
 
image (2.0.0) package with "pkg install -forge financial image". After installing the packages,
Line 135: Line 202:  
will only load financial 1.0.4.
 
will only load financial 1.0.4.
   −
==== comments ====
+
=== User case #3 ===
 
  −
shouldn't `rebuild` be used instead of `reinstall` ?
  −
 
  −
=== Case 2 ===
   
Owen is stuck using the financial package 1.0.4 because some of his code no
 
Owen is stuck using the financial package 1.0.4 because some of his code no
 
longer works in the latest versions. However the latest version of financial
 
longer works in the latest versions. However the latest version of financial
Line 149: Line 212:  
while "pkg load financial" always loads the latest version of the package.
 
while "pkg load financial" always loads the latest version of the package.
   −
=== Case 3 ===
+
=== User case #4 ===
 
Lisa is using Octave in a remote machine on the biochemistry department.  The
 
Lisa is using Octave in a remote machine on the biochemistry department.  The
 
system administrator installed Octave 3.6.2, signal package 1.2.0, and
 
system administrator installed Octave 3.6.2, signal package 1.2.0, and
Line 162: Line 225:  
does not want to make the update and tells her to build it herself locally
 
does not want to make the update and tells her to build it herself locally
   −
=== Case 4 ===
+
=== User case #5 ===
 
Diana is a student that wants to run her code in the departmental cluster. However,
 
Diana is a student that wants to run her code in the departmental cluster. However,
 
the system does not have an installation of Octave and she needs to install it on
 
the system does not have an installation of Octave and she needs to install it on
Line 183: Line 246:  
to her own list of available packages. which she can load.
 
to her own list of available packages. which she can load.
   −
==== comments ====
+
=== User case #6 ===
 
  −
:Why not store the "packages.db" together with the packages? instead of loading the a packages database file. Then, Diana could just say {{Codeline|pkg addpath ~Ligia/octave}}
  −
:: Because she might want to use some of her packages, not all. This adding the .db file to her instance of Octave will not load the package, she still needs to load it. And she may want to load only some of them.
  −
 
  −
=== Case 5 ===
   
John is a professor of biomechanics and uses Octave on his classes. Most of the
 
John is a professor of biomechanics and uses Octave on his classes. Most of the
 
exercises he gives to the class require the use of multiple packages in Octave
 
exercises he gives to the class require the use of multiple packages in Octave

Navigation menu