Editing OEP:pkg

Jump to navigation Jump to search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Latest revision Your text
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 27: Line 25:
  
 
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 98: Line 87:
 
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 one db.
+
there may be more than onde 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 114: Line 103:
  
 
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
+
runnig 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 136: Line 125:
 
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 various db, which one should
+
And if there's multiple packages with the same version on varios 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 available
+
- load the latest version availale
 
- 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 145: Line 134:
  
 
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 validity with isvarname). So package name
+
names (makes it even easier to check validaity 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 157: Line 146:
 
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 comparison is use then greater than or
+
should be used to specify versions. If no comparsion is use then greater than or
 
equal is assumed. So that the following:
 
equal is assumed. So that the following:
  
Line 167: Line 156:
 
: 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 supporting this? It's not a lot of trouble...)
+
: load anything above that version (does it make sense supportung 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)
Line 173: Line 162:
 
: load any image package available except 1.0.5 (because regressions do exist)
 
: 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 >=
+
For the other 2 remainig 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 266: Line 255:
 
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 although "pkg load financial" will only load the latest version. However, when
+
are kept 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
 
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 323: Line 312:
 
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]]
+
[[Category:Development]]

Please note that all contributions to Octave may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see Octave:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)

Templates used on this page: