Each entry in database is a separate file.
Every field starts with %% as the first character of line immediately
followed by field name and a colon. Then comes the contents of the
field. You can use newlines as you wish in the contents of a field,
but each field name should start at the left margin.
When we speak of a "list", use commas to separate items,
and put a newline after a comma wherever you feel that looks nice.
For dates, use DD MON YYYY, as in 5 Oct 1999.
Each entry must contain following fields:
name - name of package
short description - one-line description.
If necessary, you can use two lines.
full description -
full description, in plain text plus a basic set of HTML
formating tags. Tags
,
,
and are allowed. You can also use <, > and &.
Links (normally to GNU pages) are also allowed, but would only
be appropriate in unusual situations.
If you think some other HTML features should also be allowed here,
please suggest them to me.
category - category name(s). This is a list of high-importance keywords.
keywords - list of other keywords.
license - name of license, or the full license text
if it is an unusual license.
updated - Last updated date of this record
interface style - command-line, library, text interactive, console, or X.
programs - list of programs included in this package.
This should include all the shell command names
that become meaningful as a result of installing the package.
If there are programs that the user involves but in some
other way, it is good to mention them too.
Don't bother with this field if the only important program
has the same name as the package itself.
GNU - include this with contents "yes"
if the package is a GNU package.
web page - URL for web page describing the package.
support - One or more items of the form BASIS TYPE from {PHONE | URL}
or See also URL.
BASIS is either "free" or "paid".
TYPE is what kind of support is offered.
You can give more than one TYPE with "and" between.
You can give more than one instance of {PHONE | URL}
with "or" between.
For example, it could be
free user handholding from phone 1-617-555-1212
paid extension/consulting from http://www.wedoit.com/
Do not mention the help mailing list or help newsgroup here,
because that is redundant.
doc - One or more items of the form
[LANGUAGE] AUDIENCE TYPE [in FORMAT] [as MEDIUM]
[{at|from} LOCATION | included]
LANGUAGE is the language this documentation is written in.
Omit it if it is English.
AUDIENCE is the type of person it is addressed to
(typically "user" or "programmer" or "sysadmin").
TYPE is the kind of information and presentation
(typically "introduction" or "reference" or
"intro & reference" or "reference card").
FORMAT is the file format, for machine-readable publication
(typically "Postscript" or "DVI" or "Texinfo" or "HTML").
For documentation included in the package itself,
which is available or can be produced in various formats,
this is omitted.
You can list several formats with "and" between them.
MEDIUM is the publication medium (typically "book", "card"
or "CD-ROM"). For Internet distribution or distribution
with the package itself, MEDIUM is omitted.
You can list several formats with "and" between them.
LOCATION is the URL, either for the documentation itself
or for how to order a copy.
Use "at" if the URL contains the documentation itself.
Use "from" if it contains ordering information.
"included" means the doc is in the package itself.
For example, it could be
English user reference in HTML at http://www.gnu.org/doc/foo.html
Each separate work of documentation should be
given a separate item. If the work is included in
the package, mention that; otherwise, if it is available
on line in another way, mention that. Meanwhile, if it
is also available as a printed book or card, or as a CD-ROM,
mention that *also*.
developers - list of primary developers' names, each optionally followed by an
email address in <...>. For example, it could be
Richard Stallman
maintainer - list of names of current principal maintainers,
with optional email addresses
If this is the same as the developers, omit this field.
contributors - list of assisting developers' names, each optionally followed
by an email address in <...>.
sponsors - list of sponsoring institutions' names, each optionally followed
by an email address in <...>.
source - list of designators for where to obtain source.
A designator means a URL with * allowed as a wildcard.
It can also be a directory, followed by a | and a list of file names
*not* to use within that directory.
Debian package - designators for where to obtain Debian binary package.
Red Hat package - designators for where to obtain Red Hat binary package.
repository - HOSTNAME:DIRECTORY specifying the location of the CVS
repository, if the program has a publicly accessible repository.
related - related packages. List of names of related packages.
human languages - list of human languages that the program has been
internationalized for. Use the two-letter standard language
code, if the language has one.
supported languages - supported programing languages
(for a programming tool or library)
source languages - list of programming languages used in this package
use requirements - Prerequisites for using the executable
This might be a list of packages, or just names of programs.
build prerequisites - Prerequisites for building this package.
This might be a list of packages, or just names of programs,
that must be installed before you build this package.
weak prerequisites - Packages that are useful to install before building
this one, but not mandatory.
source prerequisites - Packages whose source code must be present
in order to build this package.
version - VERSION STATUS on DATE [for PLATFORMS] [Notes: NOTES]
This says which version the information about
and its status as of when the page was updated.
VERSION is the version number. Don't end it with a period!
STATUS is "alpha", "beta" or "released".
DATE is the release date.
PLATFORMS is a list of supported platforms
given as names of systems or standard GNU configuration names.
NOTES are the release notes.
announcement list - email list to which announcements are made
*Every* GNU package must have an announcement list.
announcement newsgroup - newsgroup on which announcements are made
help list - email list for asking for help
Do not give the maintainer's email address here!
That belongs in the %%maintainer: field.
If there is no list designated for people to ask for help,
omit this field.
help newsgroup - newsgroup for asking for help
bug report list - email list for reporting bugs
*Every* GNU package must have a bug report list.
Normally it should be bug-SOMETHING@xxxxxxx.
development list - email list for design discussion
development newsgroup - newsgroup for design discussion