== Abstract ==
This document attempts to design a solution for this.
The main idea
of the solution is to keep database files with each package location and dependencies, and allow for the merge of such files.
To allow reinstallation of the packages, we propose to keep the source of the package. This would also make it easier to run the tests of packages.
and examples ==This design is meant to allow the following: * keeping multiple versions of the same package installed and load a specific one * keep packages installed for multiple versions of Octave , specially in the case of .oct files which need to be rebuilt for each octave function * reinstall a package from its cache after installing new octave version * run the tests from packages (find tests in .cc sources) * clean the package cache * usage of alternate database files * usage of packages in remote directories which may not be available at all times
Case 1 ===
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,
tests in the package (using the cached package to run the tests in the .cc files).
Later, Denise installs Octave 3.6.2 but keeps the previous version of Octave on the
system since some of her old code no longer runs correctly. Loading the financial
While using Octave 3.6.2, Denise installs the new version of the package
"pkg install -forge financial". The files for the previous version of the package
altough "pkg load financial" will only load the latest version. However, when
Denise is using Octave 3.4.3, as financial 1.2.0 requires Octave 3.6.0, pkg load
will only load financial 1.0.4.
= comments ==== 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
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 ===
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
Lisas uses all of them but she also requires the image package.
However, the system administrator does not have time to access security issues
with the package and tells her to install that package locally. She runs "pkg
When Octave 3.6.3 is released, Lisa wants to use the new version since it fixes
one bug that has been
aanoying her for a long time but the system administrator
does not want to make the update and tells her to build it herself locally
Case 4 ===
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 pkg addpath ~Ligia/octave === Case 5 ===
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
metapackage for his student listing all required packages. The students install
it with "pkg install -url path-to-his-metapackage". The metapackage has no file
it simply lists a bunch of package
has dependencies. Since pkg solves this
dependencies automatically, a message showing which packages will be installed
is displayed before doing it.
= == Where to install things
These should not be hardcoded and taken from octave_config_info. There's many paths there whose purpose is explained on octave sources [http://hg.savannah.gnu.org/hgweb/octave/file/default/build-aux/common.mk buil-aux/common.mk] (see the ''Where To Install Things'' and ''Octave-specific directories'' sections on that file.)