1,847
edits
Carandraug (talk | contribs) (→Version numbers: more dicussion, use of version modifer and mixing with -db modifier) |
(Warn about old, maybe outdated, content. File contains some dead links.) |
||
(6 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
{{Warning|This page has not been revisited since 2014. Please refer to the GNU Octave manual for information about {{manual|pkg}}.}} | |||
== Abstract == | == Abstract == | ||
This OEP refers to Octave's design of the pkg system. The purpose of this system | This OEP refers to Octave's design of the pkg system. The purpose of this system | ||
Line 25: | Line 27: | ||
See the user cases section below for several examples. | See the user cases section below for several examples. | ||
The definition of a package manager according to wikipedia: | |||
* Verifying file checksums to ensure correct and complete packages; | |||
* Verifying digital signatures to authenticate the origin of packages; | |||
* Applying file archivers to manage encapsulated files; | |||
* Upgrading software with latest versions, typically from a software repository; | |||
* Grouping of packages by function to reduce user confusion; | |||
* Managing dependencies to ensure a package is installed with all packages it requires. This resolved the problem known as Dependency Hell. | |||
== Available vs Loaded == | == Available vs Loaded == | ||
Line 87: | Line 98: | ||
associated file just like the db files for the local installs. To load an external | 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 (because | package, the path for the db file needs to be passed to pkg and the db named (because | ||
there may be more than | there may be more than one db. | ||
These are most like the less used type of packages and will require a bit more | These are most like the less used type of packages and will require a bit more | ||
Line 103: | Line 114: | ||
If the user decides to make a global package install (install the package using pkg while | If the user decides to make a global package install (install the package using pkg while | ||
running 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 | 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 | is meant to be handled by the system packaging tool. It is just not possible to make pkg | ||
Line 125: | Line 136: | ||
Also, supporting multiple packages versions means that the word "all" to refer to all | Also, supporting multiple packages versions means that the word "all" to refer to all | ||
packages has new limitations. Should we load only the latest version of each package? | packages has new limitations. Should we load only the latest version of each package? | ||
And if there's multiple packages with the same version on | And if there's multiple packages with the same version on various db, which one should | ||
be loaded? I'd propose the default to be: | be loaded? I'd propose the default to be: | ||
- load the latest version | - load the latest version available | ||
- 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 | ||
Line 134: | Line 145: | ||
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 | ||
names (makes it even easier to check | names (makes it even easier to check validity with isvarname). So package name | ||
must start with a letter, and otherwise be comprised of alphanumeric and underscores | must start with a letter, and otherwise be comprised of alphanumeric and underscores | ||
characters. Unlike variable names, package names will not be case sensitive since | characters. Unlike variable names, package names will not be case sensitive since | ||
Line 146: | Line 157: | ||
Actions dependent on a package version can be specified with a -version modifier for that | Actions dependent on a package version can be specified with a -version modifier for that | ||
action. It is however necessary to define the default order. Comparison operators | action. It is however necessary to define the default order. Comparison operators | ||
should be used to specify versions. If no | should be used to specify versions. If no comparison is use then greater than or | ||
equal is assumed. So that the following: | equal is assumed. So that the following: | ||
Line 156: | Line 167: | ||
: same as not specifying comparison | : same as not specifying comparison | ||
;pkg load -version >1.0.5 image | ;pkg load -version >1.0.5 image | ||
: load anything above that version (does it make sense | : load anything above that version (does it make sense supporting this? It's not a lot of trouble...) | ||
;pkg load -version =1.0.5 image | ;pkg load -version =1.0.5 image | ||
: load image package only if the same version (should we use == instead? Why not only =? Should not support both syntax) | : load image package only if the same version (should we use == instead? Why not only =? Should not support both syntax) | ||
;pkg load -version !1.0.5 image | |||
: load any image package available except 1.0.5 (because regressions do exist) | |||
For the other 2 | For the other 2 remaining comparisons (< and <=), the question used for > and >= | ||
is the same. Does it make sense to support both? For ''greater than'', the only | is the same. Does it make sense to support both? For ''greater than'', the only | ||
thing that makes sense is ''greater than or equal'' and for ''lesser than'', the | thing that makes sense is ''greater than or equal'' and for ''lesser than'', the | ||
Line 253: | Line 266: | ||
While using Octave 3.6.2, Denise installs the new version of the package | 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 | "pkg install -forge financial". The files for the previous version of the package | ||
are kept | are kept although "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 | 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. | will only load financial 1.0.4. | ||
Line 310: | Line 323: | ||
dependencies automatically, a message showing which packages will be installed | dependencies automatically, a message showing which packages will be installed | ||
is displayed before doing it. | is displayed before doing it. | ||
=== User case #7: Package testing === | |||
"pkg test" command that would run all tests for a given package. | |||
== Where to install things == | == 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.) | 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.) | ||
[[Category:Packages]] |