OEP:pkg: Difference between revisions

← Older edit

OEP:pkg (view source)

Revision as of 05:36, 11 June 2020

3,996 bytes added , 11 June 2020

Mark as outdated.

Siko1056

Bureaucrats, Administrators

1,860

edits

@@ 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 ==
 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.
+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 ==
@@ Line 87: / Line 98: @@
 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
-there may be more than onde db.
+there may be more than one db.
 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
-runnig Octave with sudo), then he's trying to act as system administrator and should know
+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
 is meant to be handled by the system packaging tool. It is just not possible to make pkg
@@ Line 110: / Line 121: @@
 == Package names ==
 For the parsing of the commands and files, some limitations on package names are required. This will
-limit what pkg commands can do. For example, if a package name is allowed to use score, then
+limit what pkg commands can do. For example, if a package name is allowed to use a hyphen, then
 commands such as "pkg load image-2.0.0" can no longer be used to load a specific package version.
 Something such as "pkg load image::2.0.0" would have to be used. Using this alternative syntax
@@ Line 125: / Line 136: @@
 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?
-And if there's multiple packages with the same version on varios db, which one should
+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:
-- load the latest version availale
+- load the latest version available
 - load the local 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
-names (makes it even easier to check validaity with isvarname). So package name
+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
 characters. Unlike variable names, package names will not be case sensitive since
@@ Line 140: / Line 151: @@
 sensitive (creating directories named Image and image would not be possible in FAT
 systems).
+== 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
+not allow for dev versions, beta or release candidates releases such x.y.z-rc0, x.y.z+, etc
+We have compare_versions in core to check for version numbers, whatever is decided
+should be used with compare_version (or compare_version should be made to support it).
 == User cases ==
-=== User case #1 ===
+=== User case #1: global, local and external ===
 Jenny is using Octave on the department cluster. She is not the administrator but
 there's already a system-wide installation of Octave with the general and
@@ Line 173: / Line 243: @@
 on the network that his students could mount whenever they needed it.
-=== User case #2 ===
+=== User case #2: keeping tarball ===
 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,
@@ Line 181: / Line 251: @@
 tests in the package (using the cached package to run the tests in the .cc files).
+==== different package versions ====
 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
@@ Line 196: / Line 266: @@
 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
-are kept altough "pkg load financial" will only load the latest version. However, when
+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
 will only load financial 1.0.4.
-=== User case #3 ===
+=== User case #3: installing and loading different package versions ===
 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
@@ Line 210: / Line 280: @@
 while "pkg load financial" always loads the latest version of the package.
-=== User case #4 ===
+=== User case #4: Local installation of packages and Octave ===
 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
-general 1.0.0. Lisas uses all of them but she also requires the image package.
+general 1.0.0. Lisa 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
@@ Line 220: / Line 290: @@
 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
+one bug that has been annoying her for a long time but the system administrator
 does not want to make the update and tells her to build it herself locally
-=== User case #5 ===
+=== User case #5: users (no sudo) sharing Octave installation with local & global packages ===
 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
@@ Line 244: / Line 314: @@
 to her own list of available packages. which she can load.
-=== User case #6 ===
+=== User case #6: Automatic dependency tracking ===
 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
@@ Line 250: / Line 320: @@
 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
+it simply lists a bunch of package as dependencies. Since pkg solves this
 dependencies automatically, a message showing which packages will be installed
 is displayed before doing it.
-=== Where to install things ===
+=== User case #7: Package testing ===
+"pkg test" command that would run all tests for a given package.
+== 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.)
+[[Category:Outdated pages]]