Jump to navigation Jump to search


2,799 bytes added, 16:48, 18 November 2012
expanding explanantion of type of installs and one more user case
This document attempts to design a solution for this.
The main idea of the solution is to keep database files have multiple databases with each package locationinformation from installed packagesand dependenciesin different locations in the filesystem. While this is similar to the current implementation, and allow we plan to design solutions for the merge of such fileswhen package installations clash.
To allow reinstallation of the packages, we propose This proposal also suggests to keep the source of the packagepackages.This will allow forThis would also make it easier to run the tests easy reinstall of packages (after an Octave upgrade) and test of .oct files frompackages(since their tests are in the .cc sources).
== Rationale and examples ==This design is meant to make allow the following: * keeping keep multiple versions of the same package installed and load a specific oneside-by-side * keep packages installed for multiple versions of Octave, specially in a system using the case of .oct files which need to be rebuilt for each octave functionsame installed packages * reinstall a package from its cache after installing new octave versiondeal with dependencies correctly when multiple Octave and packages co-exist * run the tests from allow use of packages (find tests in .cc sources)that may have been installed anywhere * clean the reinstall a package cache * usage of alternate database filestest installed packages * usage of packages in remote directories which may not be available at all timesSee the user cases section below for several examples.
== Available vs 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 currentlyavailable to pkg to for 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 searchpath.
== Types of package installs ==
This design supports 3 types of package installations: global (relative to the octave 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 (somewhere on {{Path|/home/user/anywhere}}), or installed in the home directory of a system user (can be anywherereally).
=== Global installs ===
Packages installed globally will be available to everyone from startup. This is the
type of package installation that a system administrator would most likely do for example. The
meaning of global here is relative to the Octave installation though. If an Octave
installation is local (installed by a user in {{Path|~/usr/localmy-builds}}), a global installation
of a package will still place its files in the home directory of the user (in
{{Path|~/usr/local/ as wellmy-builds}}).
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 packages are specific to a user. They are located in that user home directory
into ann 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
installed it. A local install for a user can be an external install for some other
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 ===
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 though they might have been installing the sameOctave versionthat is running at the moment. These can be packages installed in a filesystem that is not alwaysmounted, local packages installs from another user in the same system, or anythingelse really.
An external package was still installed with pkg, it the difference being that therecord is simply not constantly tracked downkept by Octaveafter it. 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 .dbfile needs to be passed to pkg and the db named. Then packages from (becausethere can may beloadedmore than onde db.
For exampleThese are most like the less used type of packages and will require a bit moreknowledge (they will need to point pkg to a .db file, that is all). They will bemostly used for places that develop their own packages and people who don't want toinstall the package themselves, after starting instead simply using a local install of others asan external package. === Playing nice with downstream packagers ===The recommended method for installing Octave session, one can load two and its packages is to use their OS packagingsystem.db filesDownstream packagers should have the packaging systems make global installs of thepackages. One If a user wants to install a new version of a package that isnot yet availableon its system repository, it should make a local package install (default since has a normaluser he won't have write permissions to the labdev Octave directory). If the user decides to make a global package install (/mnt/labdev/octave_packages.dbinstall the package using pkg whilerunnig Octave with sudo) , then he's trying to act as system administrator and should knowwhat he's doing. If he breaks it, its his own fault. Installation of system-wide softwareis meant to be handled by the other system packaging tool. It is the friendAjust not possible to make pkg(/home/friendA/cover all of them.octave/octave_packages === User case #1 ===Jenny is using Octave on the department cluster.db)She is not the administrator butthere's already a system-wide installation of Octave with the general andsignal image installed. Once She starts Octave and has these two external db 2 packages available toher. These are loadedglobally installed packages,available to everyone that startsOctave. But Jenny also requires the image package and she installs it with "pkg install -forge image". Shedoes not have permissions to administer the system so the image package is installedlocally in her home directory. When she starts Octave, she now has 3 packages associated with it available,general and signal package which are made global (available to pkg everyone that starts Octave), and can be loaded normallythe image package which is local (available only to her).ItJenny's possible supervisor is working on a new package (img_analysis) that he makes availablefor all his students and wants Jenny to use it. Rather than sending them the packages,he wants them to use the same package name he has installed on his own home directory and version exists in both dbs hence thetellsneed them to name them (so load it's possible as an external package. Jenny uses"pkg load-db boss /home/supervisor/.octave/octave_packages.db" to make his supervisorpackages available to specify from which her. She now has 4 available packages, the new one should (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 stillonly 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 be loaded)in some other place to avoid clash with his own local packages. For example, he couldhave installed it at {{Path|/home/supervisor/group/octave}}. Or he could have a filesystemon the network that his students could mount whenever they needed it.
== Package names ==
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
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
or HFS systems). 
== 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
image (2.0.0) package with "pkg install -forge financial image". After installing the packages,
will only load financial 1.0.4.
==== comments ==== shouldn't `rebuild` be used instead of `reinstall` ? === Case 2 User case #3 ===
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
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
system administrator installed Octave 3.6.2, signal package 1.2.0, and
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,
the system does not have an installation of Octave and she needs to install it on
to her own list of available packages. which she can load.
==== comments ==== :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 User case #6 ===
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

Navigation menu