|[ < ]||[ > ]||[ << ]||[ Up ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]|
‘package-info.in’ contains information that gets injected into the
‘package-index’ file when
make bindist is run. Here is a
real world example from the xemacs-base package (a description of each
field follows the example):
(xemacs-base (standards-version 1.1 version VERSION author-version AUTHOR_VERSION date DATE build-date BUILD_DATE maintainer MAINTAINER distribution xemacs priority high category CATEGORY dump nil description "Fundamental XEmacs support, you almost certainly need this." filename FILENAME md5sum MD5SUM size SIZE provides (add-log advice-preload advice annotations assoc case-table chistory comint-xemacs comint compile debug ebuff-menu echistory edmacro ehelp electric enriched env facemenu ffap helper imenu iso-syntax macros novice outline passwd pp regexp-opt regi ring shell skeleton sort thing time-stamp timezone tq xbm-button xpm-button) requires (REQUIRES) type regular ))
The name of the package. In the case of the example it is ‘xemacs-base’.
Part of the internal package infrastructure, its value should always be ‘1.1’. Do not change this.
This is the XEmacs package version number of the package. It is set
from the ‘Makefile’ variable
VERSION. This is something
that the XEmacs Package Release Engineer deals with so there is no need
for a package maintainer to touch it. In ‘package-info.in’ just
put the place-marker, ‘VERSION’ here.
This is the package’s internal, or ‘upstream’ version number if it
has one. It is set from the ‘Makefile’ variable
This is the date of the last change made to the package. It is auto-generated at build time, taken from the package’s toplevel ‘ChangeLog’.
The date the package was built. It is auto-generated.
This is the name and email address of the package’s maintainer. It is
taken from the ‘Makefile’ variable
An unused field, leave as ‘xemacs’
An unused field, can be any of ‘high’, ‘medium’, or ‘low’.
The ‘category’ of the package. It is taken from the
CATEGORY and can be either
‘standard’ for non-Mule packages, or ‘mule’ for Mule
packages. The is also provision for ‘unsupported’ in this field
which would be for packages that XEmacs.org do not distribute.
N.B. As yet, the XEmacs Packaging System does not support this type of package. It will in the future.
Unused. Always ‘nil’
A free form short description of the package.
The file name of the package’s binary tarball. It is generated at build
The MD5 message digest of the package’s binary tarball. Generated at
build time by
The size in bytes of the package’s binary tarball. Generated at build time.
A whitespace separated list of all the features the package provides. Surround the list with parens.
Taken from the ‘Makefile’ variable
REQUIRES. It is a list
of all the package’s dependencies, including any macros and defstructs
that need to be inlined.
‘REQUIRES’ cannot be correctly computed from the calls to
require in the package’s library sources. ‘REQUIRES’ is
used to ensure that all macro and defstruct definitions used by the
package are available at build time. This is not merely a matter of
efficiency, to get the expansions inlined. In fact, it is
impossible to call a macro by name in byte-compiled Emacs Lisp
code. Thus, if the macro expansion is not inlined, the call will result
in an error at run-time! Thus, packages providing libraries that would
be loaded because of autoload definitions must also be included.
Can either be ‘regular’ for a regular package, or ‘single-file’ for a single file package.
N.B. This doesn’t refer to the number of lisp files in a package. A single-file package can have multiple lisp files in it. See section Libraries and Packages.
The fields in ‘package-info.in’ that need to be changed directly are:
Everything else is either set from the appropriate ‘Makefile’ variable, is auto-generated at build time, or is static.
|[ << ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]|
This document was generated by Aidan Kehoe on December 27, 2016 using texi2html 1.82.