diff --git a/doc/changes/changes45.xml b/doc/changes/changes45.xml
index d28bef520c..539b8dabc6 100644
--- a/doc/changes/changes45.xml
+++ b/doc/changes/changes45.xml
@@ -627,7 +627,7 @@ In addition, there is now
a better error management if package loading fails for packages that use
the new functionality to log package loading messages
(see
+
+
+README
+-
+README
+
+The filename may optionally have an extension, e.g. .txt or .md.
+
+This should contain
how to get it
instructions (covering the
+way of getting it with the ⪆ distribution and from the ⪆ website,
+if applicable), as well as installation instructions and names
+of the package authors and their email addresses. These installation
+instructions should be repeated or referenced from the package's
+documentation, which should be in the doc directory
+(see
+
+
+CHANGES
+-
+For further versions of the package, it will be also useful to have a
+CHANGES file that records the main changes between versions
+of the package.
+
+The filename may optionally have an extension, e.g. .txt or .md.
+
+
+
+LICENSE
+-
+The file which explains conditions on which the package is distributed.
+
+We advise all package authors to make clear in the documentation of their
+package the basis on which it is being distributed to users. Technically,
+this is the terms of the license which you give the users to copy, modify
+and redistribute your software (of which you presumably own the copyright)
+for their purposes.
+
+⪆ itself is distributed under the GNU General Public License version 2,
+a popular
free software
license which allows users to redistribute it
+freely under the same terms, and requires that any software which
+incorporates ⪆ (technically, any derived work
) also be distributed
+under those terms. We would encourage you to consider the GPL for your
+packages, but you might wish to be more restrictive (for instance
+forbidding redistribution for profit) or less restrictive (allowing
+your software to be incorporated into commercial software).
+
+The filename may optionally have an extension, e.g. .txt or .md.
+Some packages also use different filenames, like COPYING.
+
+
+configure, Makefile.in
+-
+These files are typically only used by packages which have a non-⪆ component,
+e.g. some C code (the files of which should be in the src
+directory). The configure and Makefile.in files of the
+Example package provide prototypes (or they may be created
+using the PackageMaker mentioned above). The configure
+file typically takes a path path to the ⪆ root directory as argument
+and uses the value assigned to GAParch in the file sysinfo.gap,
+created when ⪆ was compiled to determine the
+compilation architecture, inserts this in place of the string @GAPARCH@
+in Makefile.in and creates a file Makefile. When make is
+run (which, of course, reads the constructed Makefile), a directory
+bin (if necessary) and subdirectories of bin with the path equal
+to the string assigned to GAParch in the file sysinfo.gap should
+be created; any binaries constructed by compiling the code in src should
+end up in this subdirectory of bin.
+
+
+
+PackageInfo.g
+-
+PackageInfo.g
+Every ⪆ package must have a PackageInfo.g
+file which contains meta-information about the package (package name, version,
+author(s), relations to other packages, homepage, download archives, etc.).
+This information is used by the package loading mechanism and also for
+the redistribution of a package with ⪆. The Example package's
+PackageInfo.g file is well-commented and can be used as a
+prototype (see also
+
+init.g, read.g
+-
+init.g
+read.g
+A ⪆ package must have a file init.g.
+Typical init.g and read.g files should normally consist
+entirely of
declaration
and implementation
parts of
+the package are separated (and this is recommended), there should be a
+read.g file.
+The declaration
part
+of a package consists of function and variable name declarations and
+these go in files with .gd extensions; these files are read in via
+ReadPackage commands in the init.g file. The implementation
part
+of a package consists of the actual definitions of the functions and
+variables whose names were declared in the declaration
part, and
+these go in files with .gi extensions; these files are read in via
+ReadPackage commands in the read.g file. The reason for following the
+above dichotomy is that the read.g file is read after the init.g
+file, thus enabling the possibility of a function's implementation to
+refer to another function whose name is known but is not actually defined
+yet (see declaration
and
+implementation
parts) should go in the package's lib directory
+(see below).
+
+
+doc
+-
+GAPDoc format
+This directory should contain the package's documentation, written in an
+XML-based documentation format supported by the ⪆ package &GAPDoc;
+(see
+
+lib
+-
+This is the preferred place for the ⪆ code of the package, i.e. the
+.g, .gd and .gi files (other than PackageInfo.g,
+init.g and read.g). For some packages, the directory gap
+has been used instead of lib; lib has the advantage that it is
+the default subdirectory of a package directory searched for by the
+
+
+src
+-
+If the package contains non-⪆ code, e.g. C code, then this source
+code should go in the src directory. If there are .h
+
include
files you may prefer to put these all together in a separate
+include directory. There is one further rule for the location of kernel
+library modules or external programs which is explained in
+
+
+tst
+-
+It is highly recommended that a package should have test files, which then
+should go in the tst directory. For a deposited package, a test file
+with a basic test of the package (for example, to check that it works as
+expected and/or that the manual examples are correct) may be specified in the
+PackageInfo.g to be included in the ⪆ standard test suite
+and run as a part of the ⪆ release preparation.
+More specific and time consuming tests are not supposed to be a part of the
+⪆ standard test suite but may be placed in the tst directory
+with further instructions on how to run them.
+See Section
+
+
+
+All other files can be organised as you like. But we suggest that you
+have a look at existing packages and use a similar scheme, for
+example, put examples in the examples subdirectory, data
+libraries in extra subdirectories, and so on.
+
+Sometimes there may be a need to include an empty directory in the
+package distribution (for example, as a place to store some data that
+may appear at runtime). In this case package authors are
+advised to put in this directory a short README file describing
+its purpose to ensure that such directory will be included in the
+redistribution.
+
+Concerning the ⪆ code in packages, it is recommended to use only
+documented ⪆ functions, see obsolete
variables
+(see obsolete
variables).
+
+
+
+
+
+Writing Documentation and Tools Needed
+
+If you intend to make your package available to other users it is
+essential to include documentation explaining how to install and use your
+programs.
+
+Concerning the installation you should produce a README file which
+gives a short description of the purpose of the package and contains
+proper instructions how to install your package. Again, check out some
+existing packages to get an idea how this could look like.
+
+Documentation for ⪆ package should be prepared in an XML-based
+documentation format that is defined in and can be used with the &GAPDoc;
+package (see test
in version 1.0.
+The package documentation consists of one autoloaded book; the SixFile
+component is needed by the ⪆ help system. Package dependencies (picked
+for the purposes of this example) require at least ⪆ 4.9 and &GAPDoc;
+package at version at least 1.6, and these conditions will be checked when the
+package will be loaded (see method
+for the same-named object.
+
+To demonstrate the definition of a function via a
+DeclareOperation/InstallMethod pair,
+the method method
for making a
+fruit cake (forgive the pun).
+
+Thirdly, functions or variables with SetXXX or HasXXX names
+(even if they are defined as operations) should be avoided as these may
+clash with objects associated with attributes or properties (attributes
+and properties XXX declared via the DeclareAttribute and
+DeclareProperty commands have associated with them testers of form
+HasXXX and setters of form SetXXX).
+
+Fourthly, it is a good idea to have some convention for internal
+functions and variables (i.e. the functions and variables you don't
+intend for the user to use). For example, they might be entirely
+CAPITALISED.
+
+Additionally, there is a recommended naming convention that the ⪆ core
+system and ⪆ packages should not use global variables starting in the
+lowercase. This allows to reserve variables with names starting in lowercase
+to the ⪆ user so they will never clash with the system. It is extremely
+important to avoid using for package global variables very short names
+started in lowercase. For example, such names like cs, exp,
+ngens, pc, pow which are perfectly fine for local
+variables, should never be used for globals. Additionally, the package must
+not have writable global variables with very short names even if they are
+starting in uppercase, for example, C1 or ORB, since they
+also could be easily overwritten by the user.
+
+It is a good practice to follow naming conventions used in ⪆ as
+explained in phantom
variables may then remain
+unnoticed and, as a result, there will be no warnings if the user occasionally
+uses the same name as a local variable name in a function. Even more
+dangerous is the case when the user variable with the same name already exists
+before the package is loaded so it will be silently overwritten.
+
+
+
+
+
+
+Package Dependencies (Requesting one ⪆ Package from within Another)
+
+needed package
+suggested package
+dependencies
+It is possible for one ⪆ package A, say,
+to require another package B.
+For that, one simply adds the name and the (least) version number of the
+package B to the NeededOtherPackages component of the
+Dependencies component of the PackageInfo.g file of the package
+A.
+In this situation, loading the package A forces that also the package
+B is loaded, and that A cannot be loaded if B is not
+available.
+
+
+If B is not essential for A but should be loaded if it is
+available
+(for example because B provides some improvements of the main system
+that are useful for A)
+then the name and the (least) version number of B should be added to
+the SuggestedOtherPackages component of the
+Dependencies component of the PackageInfo.g file of A.
+In this situation, loading A forces an attempt to load also B,
+but A is loaded even if B is not available.
+
+
+Also the component Dependencies.OtherPackagesLoadedInAdvance in
+PackageInfo.g is supported, which describes needed packages that
+shall be loaded before the current package is loaded.
+See needed
or suggested
.
+For example, declaring package as needed
when suggested
+might be sufficient may prevent loading of packages under Windows for
+no good reason.
+
+
+It is not appropriate to explicitly call
+bootstrapping
problem arises of defining functions before they are
+called.
+The same problem occurs in the ⪆ library, and it is resolved there
+by separating declarations (which define global variables such as
+filters and operations)
+and implementations (which install global functions and methods)
+in different files.
+Any implementation file may use global variables defined in any declaration
+file.
+⪆ initially reads all declaration files (in the library they have a
+.gd suffix) and afterwards reads all implementation files
+(which have a .gi suffix).
+
+Something similar is possible for ⪆ packages:
+if a file read.g exists in the home directory of the package,
+this file is read only after all the init.g files of all
+(implicitly) required ⪆ packages are read.
+Thus one can separate declaration and implementation for a ⪆ package
+in the same way as is done for the ⪆ library,
+by creating a file read.g,
+restricting the
+-
+ If package A suggests or needs package B
+ and package B does not need or suggest any other package
+ then first init.g of B is read,
+ then read.g of B,
+ then init.g of A,
+ then read.g of A.
+
+-
+ If package A suggests or needs package B
+ and package B (or a package that is suggested or needed by B)
+ suggests or needs package A
+ then first the files init.g of A and B are read
+ (in an unspecified order)
+ and then the files read.g of A and B
+ (in the same order).
+
+
+
+
+In general, when ⪆ is asked to load a package then first the dependencies
+between this packages and its needed and suggested packages are inspected
+(recursively), and a list of package sets is computed such that no cyclic
+dependencies occur between different package sets and such that no package
+in any of the package sets needs any package in later package sets.
+Then ⪆ runs through the package sets and reads for each set first all
+init.g files and then all read.g files of the packages in the
+set.
+(There is one exception from this rule:
+Whenever packages are autoloaded before the implementation part of the ⪆
+library is read, only the init.g files of the packages are read;
+as soon as the ⪆ library has been read, the read.g files of these
+packages are also read, and afterwards the above rule holds.)
+
+
+IsPackageMarkedForLoading
+It can happen that some code of a package depends on the availability of
+suggested packages, i.e., different initialisations are performed
+depending on whether a suggested package will eventually be loaded or not.
+One can test this condition with the function
+cyclic dependency
as in the second example above,
+suppose that B provides a new function f or a new global record
+r, say, which are declared in the declaration part of B.
+Then the code in the implementation part of A may contain
+calls to the functions defined in the declaration part of B.
+However, the implementation part of A may be read
+before the implementation part of B.
+So one can in general not assume that during the loading of A,
+the function f can be called, or that one can access components of
+the record r.
+
+
+If one wants to call the function f or to access components of the
+record r in the code of the package A then the problem is
+that it may be not possible to determine a cyclic dependency between A
+and B from the packages A and B alone.
+A safe solution is then to add the name of B to the component
+Dependencies.OtherPackagesLoadedInAdvance of the PackageInfo.g
+file of A.
+The effect is that package B is completely loaded before the file
+read.g of A is read, provided that there is no cyclic
+dependency between A and B,
+and that package A is regarded as not available in the case that
+such a cyclic dependency between A and B exists.
+
+
+A special case where Dependencies.OtherPackagesLoadedInAdvance
+can be useful is that a package wants to force the complete ⪆ library
+to be read before the file read.g of the package A is read.
+In this situation, the package name
"gap" should be added
+to this component in the PackageInfo.g file of A.
+
+
+autoreadable variables
+In the case of cyclic dependencies, one solution for the above problem
+might be to delay those computations (typically initialisations)
+in package A that require package B to be loaded
+until all required packages are completely loaded.
+This can be done by moving the declaration and implementation of the
+variables that are created in the initialisation into a separate file
+and to declare these variables in the init.g file of the package,
+via a call to Semantic Versioning
,
+see http://semver.org/ for further recommendations on its use.
+
+Since version information is duplicated in several places throughout the
+package documentation, for &GAPDoc;-based manuals you may define the
+version and the release manual in the comments in PackageInfo.g
+file close to the place where you specified its Version and
+Date components, for example
+
+##
+##
+##
+## <#/GAPDoc>
+]]>
+notify
+-
+starting &GAP; with no packages (except needed for &GAP;) using -r -A options
+and calling LoadPackage("packagename");
+
+-
+starting &GAP; with no packages (except needed for &GAP;) using -r -A options
+and calling LoadPackage("packagename" : OnlyNeeded );
+
+-
+starting &GAP; in the default configuration (with no options)
+and calling LoadPackage("packagename");
+
+-
+starting &GAP; in the default configuration (with no options)
+and calling LoadPackage("packagename" : OnlyNeeded );
+
+-
+finally, together with all other packages using
+
+
+The test of loading all packages is the most subtle one. Quite often
+it reveals problems which do not occur in the default configuration
+but may cause difficulties to the users of specialised packages.
+
+For your convenience, make testpackagesload called in the &GAP;
+root directory will run all package loading tests listed in this subsection
+and write their output in its dev/log directory.
+
+It will produce four files with test logs, corresponding to the
+four cases above (the letter N in the filename stands for
+needed
, A stands for autoloaded
):
+
+-
+dev/log/testpackagesload1_...
+
+-
+dev/log/testpackagesloadN1_...
+
+-
+dev/log/testpackagesloadA_...
+
+-
+dev/log/testpackagesloadNA_...
+
+
+Each file contains small sections for loading individual packages: among those,
+you need to find the section related to your package and may ignore all other
+sections. For example, the section for the Example package looks like
+
+so it has clearly passed the test. If there are any error messages displayed
+between Loading ... and Loaded ... lines, they will signal on
+errors during loading of your package.
+
+Additionally, this test collects information about variables created since
+the library was read (obtained using Choosing a License for the Distribution of Your Package
+from http://www.gap-system.org/Packages/Authors/authors.html and also
+https://choosealicense.com/ for further details.
+
+
+In the past many &GAP; packages used the text
+We adopt the copyright regulations of &GAP; as detailed in the copyright
+notice in the &GAP; manual
or a similar statement. We now advise to be
+more explicit by making the exact reference to the GPL license, for example:
+
+
+packagename is free software; you can redistribute it
+and/or modify it under the terms of the
+http://www.fsf.org/licenses/gpl.html
+as published by the Free Software Foundation; either version 2 of the License,
+or (at your option) any later version.
+
+and also including a copy of the full text of the license.
+
+
+
+
+
+Releasing a GAP Package
+
+Currently, the &GAP; distribution provides archives in four different
+formats.
+
+
+.tar.gz
+-
+ a standard UNIX tar archive, compressed with gzip
+
+.tar.bz2
+-
+ a standard UNIX tar archive, compressed with bzip2
+
+.zip
+-
+ an archive in zip format, where text files should have
+ UNIX style line breaks
+
+-win.zip
+-
+ an archive in zip format, where text files should have
+ Windows style line breaks
+
+
+
+For convenience of possible users it is sensible that you provide an
+archive of your package in at least one of these formats.
+
+For example, if you wish to supply a .tar.gz archive,
+you may create it with the command
+
+ tar -cvzf packagename-version.tar.gz packagename
+
+\noindent
+Because the release of the &GAP; package is independent of the version
+of &GAP;, a &GAP; package should be wrapped up in separate file that
+can be installed onto any version of &GAP;. In this way, a package can
+be upgraded any time without the need to wait for new &GAP; releases.
+To ensure this, the package should be archived from the &GAP; pkg
+directory, that is all files are archived with the path starting at the
+package's name.
+
+GAPDocManualLab
+The archive of a &GAP; package should contain all files necessary for the
+package to work. In particular there should be a compiled documentation,
+which includes the manual.six, manual.toc and manual.lab
+file in the
+documentation subdirectory which are created by &GAPDoc; while &TeX;ing
+the documentation.
+(The first two files are needed by the &GAP; help system,
+and the manual.lab file is needed if the main manuals or another
+package is referring to your package.
+Use the command GAPDocManualLab( packagename ); to create this file
+for your help books if you use &GAPDoc;.)
+
+
+For packages which are redistributed via the &GAP; website,
+we offer an automatic conversion of any of the formats listed
+above to all the others (note that this, as well as wrapping
+the &GAP; distribution as a single archive containing the
+core system and all currently redistributed packages, will
+change file timestamps, so one should not rely on them anywhere
+in the package).
+
+
+To use the conversion and repackaging service, you can provide any of
+the four archive formats or even more than one, however you should
+adhere to the following rule: text files in .tar.gz
+and .tar.bz2 archives must have UNIX style line breaks,
+while text files in -win.zip archives must have
+DOS/Windows line breaks.
+
+
+The package wrapping tools for the &GAP; distribution and webpages
+then will use a sensible list of file extensions to decide if a file
+is a text file (being conservative, it may miss a few text files).
+These rules may be prepended by the application of rules from the
+PackageInfo.g file:
+
+-
+if it has a .TextFiles component, then consider the given files
+as text files before &GAP; defaults will be applied;
+
+-
+if it has a .BinaryFiles component, then consider given files
+as binary files before &GAP; defaults will be applied;
+
+-
+if it has a .TextBinaryFilesPatterns component, then apply it
+before &GAP; defaults will be applied;
+
+
+
+
+Utility functions from the lib/lbutil.g file in &GAP;, namely
+DosUnixLinebreaks, UnixDosLinebreaks, MacUnixLinebreaks
+may be helpful. They are described in the comments to their source code.
+
+
+For packages hosted on GitHub publishing package release and establishing its
+website can be very efficiently automated using two tools:
+ReleaseTools (https://github.com/gap-system/ReleaseTools) and
+GitHubPagesForGAP (https://github.com/gap-system/GitHubPagesForGAP).
+
+
+
+
+
+
+The homepage of a Package
+
+If you want to distribute your package you should create its homepage containing
+some basic information, archives for download,
+the README file with installation instructions,
+and a copy of the package's PackageInfo.g file.
+
+The responsibility to maintain this homepage is with the package
+authors/maintainers.
+
+If you tell the &GAP; Group about your package
+(say, by mail to support@gap-system.org)
+we may consider either
+
+-
+adding a link to your package homepage from the &GAP; website
+(thus, the package will be an undeposited contribution);
+
+-
+or redistributing the current version of your package as a part of
+the &GAP; distribution (this, the package will be deposited),
+also ;
+
+
+In the latter case we can also provide some services for producing several
+archive formats from the archive you provide (e.g., you produce a .tar.gz
+version of your archive and we produce also a .tar.bz2, .zip
+and a -win.zip version from it).
+
+Please also consider submitting your package to the &GAP; package refereeing
+process (see http://www.gap-system.org/Contacts/submit.html for
+further information).
+
+For packages hosted on GitHub publishing package release and establishing its
+website can be very efficiently automated using two tools:
+GitHubPagesForGAP (https://github.com/gap-system/GitHubPagesForGAP)
+and ReleaseTools (https://github.com/gap-system/ReleaseTools).
+
+
+
+
+
+
+Some things to keep in mind
+
+
+
+-
+Some packages still use for their manuals the old
gapmacro
format,
+support for which may be discontinued in the future. We encourage authors
+of those packages to eventually convert their documentation &GAPDoc;.
+New packages are recommended to use &GAPDoc;, which, for example, is
+capable of creating HTML documentation with MathJax support, allows
+easy extraction of examples from documentation for testing, etc. One could
+also use the AutoDoc which simplifies writing documentation
+by generating most of the &GAPDoc; code automatically.
+
+
+-
+The concept of an autoloaded package, which existed before &GAP; 4.5,
+has been integrated with the needed
+and suggested mechanism that exists between packages. &GAP; itself
+now
needs
certain packages (for instance &GAPDoc;) and suggests
others
+(typically the packages that were autoloaded). The decisions
+which packages &GAP; should need or suggest are made by developers based on
+technical criteria. They can be easily overridden by a user
+using the new gap.ini
+(see
+
+-
+Optional ~/.gap directory for user's customisations which may
+contain e.g. locally installed packages (see
+
+-
+Packages loading mechanism allows to make loading packages more
+informative, while avoiding confusing the user with warning and error
+messages for packages they didn't know they were loading.
+For example, many messages are stored but not
+displayed using the function
+
+
+
+
+
+
+
+
+Package release checklists
+
+The following checklists should be useful to package authors and maintainers, as
+well as to everyone involved in the depositing and refereeing of &GAP; packages.
+
+
+Checklist for releasing a new package
+
+
+
+-
+ Test that the package:
+
+ -
+ does not break testinstall.g and teststandard.g,
+ and does not slow them down noticeably
+ (see
+ -
+ may be loaded in various configurations (see
+ -
+ follows the guidelines of Section
+
+
+
+
+-
+ PackageInfo.g file:
+
+ -
+ correctly specifies package version, release date, and package authors;
+
+ -
+ passes validation using
+ -
+ besides mandatory components, which are required to pass validation,
+ also has relevant optional components (such as, for example, URLs of
+ public source code repository and issue tracker; hints to distinguish
+ binary and text files in case of non-standard file names and extensions,
+ etc.);
+
+
+
+
+-
+ Package documentation:
+
+ -
+ is built and included in the package archive together with
+ its source files;
+
+ -
+ states the same version, release date and package authors
+ as specified in the PackageInfo.g file;
+
+ -
+ has the same version, release date and package authors
+ details as stated in the PackageInfo.g file;
+
+ -
+ is searchable using the &GAP; help system in all formats
+ (text, HTML and PDF);
+
+ -
+ is clear about the license under which the package is distributed,
+ and refers to the LICENSE file which should be included in
+ the package;
+
+
+
+
+
+-
+ Package archive(s):
+
+ -
+ have correct permissions for all files and directories after their
+ unpacking (755 for directories and executables, if any; 644 for other
+ files);
+
+ -
+ contain files with correct line breaks for the given format
+ (see Section
+ -
+ contain no hidden system files and directories that are not supposed
+ to be included in the package, e.g. .gitignore,
+ .git etc.;
+
+
+
+
+-
+ Package availability:
+
+ -
+ not only the package archive(s), but also the
+ PackageInfo.g and README files
+ are available online;
+
+
+
+
+
+
+
+
+
+Checklist for upgrading the package for the next major release of &GAP;
+
+&GAP; ecosystem is not static: both the core &GAP; system and packages
+redistributed with &GAP; are in constant development. &GAP; has a policy
+that changes that may have a disruptive effect on packages redistributed
+with &GAP; should only be introduced in major &GAP; releases. When the next
+&GAP; major release is prepared, a beta version for package authors will be
+made available in order to give them an opportunity to check and update,
+if necessary, their packages for the public release of the next major version
+of &GAP;.
+
+
+The following checklist will help you to check how well your package is
+ready to work with the next major release of &GAP;
+
+
+
+
+-
+Check that the package functionality works as expected,
+package tests run with no discrepancies, and manual examples
+correspond to new version of &GAP;. This is a convenient opportunity
+to polish existing and add new tests, and improve manual examples.
+
+
+-
+Revise package dependencies: check that the PackageInfo.g file
+has correct list of needed and suggested packages
+(see Section
+
+-
+Revise licensing information:
+check that the package states clearly under which conditions it is distributed
+and includes a LICENSING file with the text of a license
+(see Section
+
+-
+Rebuild the package documentation to update cross-references to main &GAP;
+manuals and, if relevant, to the documentation of other &GAP; packages.
+This will ensure that cross-references from the package manual to the main &GAP;
+manuals are correct and that the &GAP; help system will be able to navigate to
+the more precise location in the package manual. This will also improve the layout of
+the package documentation by picking up the changes in documenting tools.
+
+
+-
+Check if the package still relies on some obsolete variables
+(see Chapter
+
+-
+Check for any specific advice in release notes for the beta release for
+package authors.
+
+
+
+
+
+
+
+
+
diff --git a/doc/ref/overview.xml b/doc/ref/overview.xml
index d3bd4a3044..9fd2f9596f 100644
--- a/doc/ref/overview.xml
+++ b/doc/ref/overview.xml
@@ -24,8 +24,8 @@ the &GAP; language, and use them in just the same way as the programs
which form part of the system (the library
). Indeed, we actively
support the contribution, refereeing and distribution of extensions to
the system, in the form of &GAP; packages
. Further details of this
-can be found in chapter -
By default, some needed and suggested &GAP; packages
-(see