661
edits
OEP:pkg: Difference between revisions
Jump to navigation
Jump to search
no edit summary
Carandraug (talk | contribs) (→Package names: fix list syntax) |
Carandraug (talk | contribs) No edit summary |
||
| Line 26: | Line 26: | ||
== Available vs Loaded == | == Available vs Loaded == | ||
To avoid problems reading | 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 | |||
available to pkg to | 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 | A loaded package is an installed package whose functions have been added to Octave's function search | ||
path. | path. | ||
| Line 37: | Line 36: | ||
=== Global installs === | === Global installs === | ||
The meaning of global is relative to the Octave installation. If an Octave installation is local, a global | 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 | |||
~/usr/local/ | 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 | |||
of a package will still place its files in the home directory of the user (in | |||
~/usr/local/ as well). | |||
A global installation is performed automatically if the user installing the package | |||
has write permissions to those directories (localfcnfiledir and localapioctfiledir). | |||
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 | |||
into ann .octave directory. As with global package installations, they are available | |||
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 | |||
user. | |||
=== External installs === | === External installs === | ||
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 | |||
Octave version. These can be packages installed in a filesystem that is not always | |||
mounted, local packages installs from another user in the same system, or anything | |||
else really. | |||
An external package was installed with pkg, it is simply not constantly tracked down | |||
by Octave. An external package install will have a .db associated file just like the | |||
.db files for the local installs. To load an external package, the path for the .db | |||
file needs to be passed to pkg and the db named. Then packages from there can be | |||
loaded. | |||
For example, after starting an Octave session, one can load two .db files. One is | |||
the labdev (/mnt/labdev/octave_packages.db) and the other is the friendA | |||
(/home/friendA/.octave/octave_packages.db). Once these two external db are loaded, | |||
the packages associated with it are made available to pkg and can be loaded normally. | |||
It's possible that the same package name and version exists in both dbs hence the | |||
need to name them (so it's possible to specify from which one should a package be loaded). | |||
== Package names == | == Package names == | ||
| Line 66: | Line 94: | ||
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 local 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. | |||
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 78: | Line 106: | ||
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 | ||
systems). | systems). | ||
== User cases == | == User cases == | ||