1,860
edits
OEP:pkg: Difference between revisions
Jump to navigation
Jump to search
Mark as outdated.
Carandraug (talk | contribs) m (fix headline level) |
(Mark as outdated.) |
||
| (8 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 142: | Line 153: | ||
== Version numbers == | == Version numbers == | ||
=== specifying version === | |||
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 | |||
should be used to specify versions. If no comparison is use then greater than or | |||
equal is assumed. So that the following: | |||
;pkg load image | |||
: loads latest version of the image package. If package is not installed, give error | |||
;pkg load -version 1.0.5 image | |||
: load the latest version greater than or equal to 1.0.5. If no such version found, give error | |||
;pkg load -version >=1.0.5 image | |||
: same as not specifying comparison | |||
;pkg load -version >1.0.5 image | |||
: 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 | |||
: 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 remaining comparisons (< and <=), the question used for > and >= | |||
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 | |||
only think that makes sense is ''only lesser than'' since people will mark them | |||
as the first release that implemented, or the first release that no longer had, | |||
a specific feature. | |||
Whatever code is used on this section should also be used for solving package | |||
dependencies. | |||
Should versions take precedence over the database for loading order? For example, | |||
if there is a global installation of image 1.0.5 and a 2.0.0 version on an external | |||
database named labdev, what version should be loaded? | |||
;pkg load image | |||
: load version 1.0.5 from global (database takes precedence over version) | |||
;pkg load -version >1.0.0 image | |||
: load version 1.0.5 from global (database takes precedence over version) | |||
;pkg load -version >2.0.0 image | |||
: load version 2.0.0 from labdev (only version that meets the requirements) | |||
;pkg load -version >1.0.0 -db labdev image | |||
: load version 2.0.0 from labdev (while database takes precedence, labdev was specified so we load the latest) | |||
Should the -db modifier make pkg ignore completely version? If a system has signal | |||
version 1.0.0 on an external named labdev, and 1.2.0 on a global, what should be loaded? | |||
;pkg load signal | |||
: load version 1.2.0 from global | |||
;pkg load -db labdev image | |||
: load latest version from global or from labdev? | |||
=== version definition === | |||
The current implementation only accepts versions on the format x.y.z. This does | The current implementation only accepts versions on the format x.y.z. This does | ||
not allow for dev versions, beta or release candidates releases such x.y.z-rc0, x.y.z+, etc | not allow for dev versions, beta or release candidates releases such x.y.z-rc0, x.y.z+, etc | ||
| Line 203: | 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 260: | 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:Outdated pages]] | |||