This text is intended to help you get started installing a new XEmacs and its packages from start. For details see the 'Startup Paths' and 'Packages' sections of the XEmacs info manual.
An overview of existing packages and their purpose may be found in the
XEmacs 21
Packages CVS Repository document
and under the XEmacs source tree in etc/PACKAGES.
Q: Do I need to have the packages to compile
XEmacs?
A: No.
Q: I really liked the old way that packages were
bundled and do not want to mess with packages at
all.
A: You can grab all the packages at once like you
used to with old XEmacs versions, skip to the
'Sumo Tarball'
section below. The win32 binary kit for Windows includes these Sumo packages as well.
The XEmacs package system is still being developed. Please expect a few minor hurdles on the way.
In order to reduce the size and increase the maintainability of XEmacs, the majority of the Elisp that came with previous releases have been unbundled. They have been replaced by the package system. Each elisp add-on (or groups of them when they are small) now comes in its own tarball that contains a small search hierarchy.
You select just the ones you need. Install them by untarring them into the right place. On startup XEmacs will find them, set up the load path correctly, install autoloads, etc, etc.
On startup XEmacs looks for packages in so called
package hierarchies. These can be specified by the
package-path parameter to the
configure script.
However by default there are following three system wide hierarchies,
$prefix/lib/xemacs/site-packages$prefix/lib/xemacs/mule-packages$prefix/lib/xemacs/xemacs-packages$prefix/share/xemacs
instead of $prefix/lib/xemacs.
where $prefix is the value of the prefix
parameter to the configure script.
From within a running XEmacs you may type M-x
describe-installation RET to find the value of
Package path. M-x describe-variable RET
configure-package-path RET will reveal the package path
that was used to configure your XEmacs binary.
Packages for a native Windows build are also configured to be
picked up in sub-directories site-packages,
mule-packages, and xemacs-packages.
However these are all relative to variable
PACKAGE_PREFIX as defined in nt/xemacs.mak
or on the nmake command line.
nt/xemacs.mak
! if !defined(PACKAGE_PREFIX) PACKAGE_PREFIX=c:\Program Files\XEmacs ! endif
If you need to install XEmacs packages in places other than what
configure-package-path defines, you may do so
after setting the EMACSPACKAGEPATH environment variable.
Some package descriptions and links to other resources can be found on the XEmacs-related Packages page.
Choose one of the following options:
Those with little time, cheap connections and plenty of disk space
can install all packages at once using the Sumo tarballs. Download
the file
xemacs-sumo-<date>.tar.gz
from the FTP site.
For an XEmacs compiled with Mule you also need
xemacs-mule-sumo-<date>.tar.gz
Note: They are called 'Sumo Tarballs' for good reason. They are currently about 21MB and 6MB (gzipped) respectively.
Install them by
cd $prefix/lib/xemacs ; gunzip -c <tarballname> | tar xf -
Note: in recent beta XEmacs (since about 21.5)
packages should be untarred in $prefix/share/xemacs,
not $prefix/lib/xemacs.
As the Sumo tarballs are not regenerated as often as the individual packages, it is recommended that you use the automatic package tools afterwards to pick up any recent updates.
Fetch the packages from the FTP site,
CDROM whatever. The filenames
have the form name-<version>-pkg.tar.gz and are gzipped
tar files. For a fresh install it is sufficient to untar the file at
the top of the package hierarchy. For example if we are installing the
'xemacs-base' package in version 1.27:
mkdir $prefix/lib/xemacs/xemacs-packages \ # if it does not exist yet
cd $prefix/lib/xemacs/xemacs-packages
gunzip -c ...../xemacs-base-1.27-pkg.tar.gz | tar xf -
For MULE related packages, it is best to untar in the
mule-packages hierarchy, i.e. for the mule-base package, version 1.25
mkdir $prefix/lib/xemacs/mule-packages # if it does not exist yet
cd $prefix/lib/xemacs/mule-packages
gunzip -c ...../mule-base-1.25-pkg.tar.gz | tar xf -
Note: in recent beta XEmacs (since about 21.5)
both regular and MULE packages should be untarred in
$prefix/share/xemacs/xemacs-packages and
$prefix/share/xemacs/mule-packages, respectively.
XEmacs comes with some tools to make the periodic updating and installing easier. It will notice if new packages or versions are available and will fetch them from the FTP site.
Unfortunately this requires that a few packages are already in place. You will have to install them by hand as above or use a Sumo tarball. This requirement will hopefully go away in the future. The packages you need are:
After installing these by hand, you can start XEmacs. (It is a good idea to use 'xemacs -vanilla' here as your startup files might need things now moved to packages.)
M-x customize-group RET package-get RET and
customize package-get-remote. (You cannot use
customize-variable as the variable is not known
before loading the package code.)
M-x
pui-add-install-directory. Please make sure you also have
a corresponding copy of the package index there.M-x pui-list-packages RET.
XEmacs will now first try to fetch a new version of
the package index from the FTP site.
Error in process
filter: (ftp-error FTP Error: ... 229 Entering Extended
Passive Mode ..., your efs is too old and the index
has not been updated, even though one is
shown. Fetch and install an efs update by hand, as explained
above. You don't need to worry about the currently installed
efs; just unpack the efs package in your
xemacs-packages directory.
Error in process
filter: (ftp-error FTP Error: ... 500 Unknown command
..., or any similar `500' error message, your index
has not been updated either. Then you need to use a
different XEmacs mirror: your ftp client sends extended
commands that the server doesn't understand and efs does not
handle the resulting error messages.
~/.xemacs, maybe it will ask to create this
directory. You will also be asked if you want to load the
package database. Confirm all those questions.Can't check signature: Public key
82EDF2C1D1DD84CD not found. (The key id might be
different.) Then you don't have the public key of the
person who signed the package index - at time of this
writing, Norbert Koch.
gpg --keyserver hkp://wwwkeys.pgp.net --recv-key 82EDF2C1D1DD84CD(Of course, you need to use the public key id from XEmacs' error message in the gpg command.) You might get a warning that the HKP interface is experimental - don't worry, it works. Then comes the message that a public key got imported.
gpg --import
with that file.
M-x package-get-update-base RET. This time
it'll finish with the message `Updated package
database'.The message was
corrupt' and if you have the GPG key imported,
try again updating the package index, maybe again
another time. Sometimes, verification with GPG does not
succeed for unknown reasons.M-x
customize-variable RET
package-get-require-signed-base-updates RET.
But this should be the last resort, as verifying
downloads is an important security measure.*Packages* with
an overview of available and installed packages, including a
short description. In this buffer you can select which packages
you want by using the mouse or typing RET.x to begin installing packages.New packages can only be used by XEmacs after a restart.
It is a good idea to keep packages that are MULE-only separate by putting them in the mule-packages hierarchy. Non-Mule XEmacsen will ignore packages in mule-packages so it is safe to have that directory in the package path of a Non-Mule XEmacs.
This is difficult to say. When in doubt, install a package. If you administrate a big site it might be a good idea to just install everything. A good minimal set of packages for XEmacs-latin1 would be:
Unfortunately the package system currently provides neither dependencies nor conflicts. This will be a future enhancement. The above set includes most packages that are used by others.
As mentioned before, an overview of existing packages and their
purpose may be found at ../Develop/packages.html
and under the XEmacs source tree in etc/PACKAGES.
As the exact files and their locations contained in a package may
change it is recommended to remove a package first before installing a
new version. In order to facilitate removal, each package contains a
pkginfo/MANIFEST.pkgname file which lists all the files
that belong to the package. The function
package-admin-delete-binary-package can be used to remove
a package; it uses the manifest information internally.
Note that the interactive package tools included with XEmacs already do this for you. It is recommended to use them unless you need to script the package upgrade/removal process.
In addition to the system wide packages, users can have their own
packagee hierarchies (mule-packages and xemacs-packages) installed
in ~/.xemacs. If you want to install packages there
using the interactive tools, you need to set the variable
'pui-package-install-dest-dir' to
~/.xemacs yourself.
The site-packages hierarchy replaces the old
site-lisp directory. XEmacs no longer looks into a
site-lisp directly by default. A good place to put
site-start.el would be in
$prefix/lib/xemacs/site-packages/lisp/
Note: in recent beta XEmacs (since about 21.5)
it is recommended you place site LISP in
$prefix/share/xemacs/site-packages/lisp, not
$prefix/lib/xemacs/site-packages/lisp.
Conform with <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Automatically validated by PSGML