+@cindex creating packages
+@heading Creating Packages:
+Creating a package from an existing Lisp library is not very difficult.
+
+In addition to the Lisp libraries themselves, you need a
+@file{package-info.in} file and a simple @file{Makefile}. The rest is
+done by @file{XEmacs.rules}, part of the packaging system
+infrastructure.
+
+@file{package-info.in} contains a single Lisp form like this:
+
+@example
+(name ; your package's name
+ (standards-version 1.1
+ version VERSION
+ author-version AUTHOR_VERSION
+ date DATE
+ build-date BUILD_DATE
+ maintainer MAINTAINER
+ distribution xemacs ; change to "mule" if MULE is needed
+ priority high
+ category CATEGORY
+ dump nil
+ description "DESCRIPTION" ; one-line period-terminated string
+ filename FILENAME
+ md5sum MD5SUM
+ size SIZE
+ provides (feature1 feature2) ; one for every `provides' form
+ requires (REQUIRES)
+ type regular
+))
+@end example
+
+You must fill in the four commented lines. The value of @code{name} is
+the name of your package as an unquoted symbol. Normally it is the name
+of the main Lisp file or principal feature provided. The allowed values
+for distribution are @code{xemacs} and @code{mule}. Write them as
+unquoted symbols. The @code{description} is a quoted Lisp string; use
+the usual conventions. The first letter should be capitalized, and the
+string should end in a period. It need not be a complete sentence
+grammatically. The value for @code{provides} is a list of feature
+symbols (written unquoted). All of the features provided by libraries
+in your package should be elements of this list. Implementing an
+automatic method for generating the @file{provides} line is desirable,
+but as yet undone.
+
+The variables in upper-case are references to variables set in the
+@file{Makefile} or automatically generated. Do not change them; they
+are automatically filled in by the build process.
+
+The remaining lines refer to implementation constants
+(@code{standards-version}), or features that are unimplemented or have
+been removed (@code{priority} and @code{dump}). The @code{type} line is
+not normally relevant to external maintainers; the alternate value is
+@code{single-file}, which refers to packages consed up out of a number
+of single-file libraries that are more or less thematically related. An
+example is @code{prog-modes}. Single-file packages are basically for
+administrative convenience, and new packages should generally be created
+as regular packages.
+
+The @file{Makefile} is quite stylized. The idea is similar to an
+@file{Imakefile} or an @code{automake} file: the complexity is hidden in
+generic rules files, in this case the @file{XEmacs.rules} include file
+in the top directory of the packages hierarchy. Although a number of
+facilities are available for complex libraries, most simple packages'
+@file{Makefile}s contain a copyright notice, a few variable definitions,
+an include for @file{XEmacs.rules}, and a couple of standard targets.
+
+The first few @code{make} variables defined are @code{VERSION},
+@code{AUTHOR_VERSION}, @code{MAINTAINER}, @code{PACKAGE},
+@code{PKG_TYPE}, @code{REQUIRES}, and @code{CATEGORY}. All but one were
+described in the description of @file{package-info.in}. The last is an
+administrative grouping. Current categories include @code{standard},
+and @code{mule}.
+
+Next, define the variable @code{ELCS}. This contains the list of the
+byte-compiled Lisp files used by the package. These files and their
+@file{.el} versions will be included in the binary package. If there
+are other files (such as extra Lisp sources or an upstream
+@file{Makefile}) that are normally placed in the installed Lisp
+directory, but not byte-compiled, they can be listed as the value of
+@code{EXTRA_SOURCES}.
+
+The include is simply
+@example
+include ../../XEmacs.rules
+@end example