The file "categories" consists of records one on each line. Each record has four parts, the internal category name (used internally to build parent lines), the sibling-unique short URL name, the full name and parent category, in this way: categoryId %% short %% This is the Full Description %% parent Specification of records, each of which lives in a ".txt" file in this directory. If you change this README, please also change "template" in this directory too. ====================================================================== Each entry in the database is a separate file. Files that are writeups of packages have a .txt extension; other files do not. 1.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. Use newlines as you wish in the contents of a field, but each field name should start at column zero. 2.List"means a comma separated list unless otherwise noted. Put a newline after a comma wherever you feel it looks nice. 3.URLs and email addresses automatically become links in webpages. 4.It is acceptable to put email addresses in some non-canonical way for anti-spam purposes if the maintainer/developer so requests. 5.Each entry must contain following fields, but no one package (so far) has had all the fields filed in. Remember that this template must cover everything from large complex packages like gcc and Emacs to simple shell scripts. []'s indicate optional values. 6.A blank template is available at http://www.gnu.org/gnulist/template.txt or you can copy the one below and delete the explanatory text as you fill in each field. The template starts here. Include %%comments and everything after in the writeup. %%comments:
The copyright licensing notice below applies to this text. The software described in this text has its own copyright notice and license, which can usually be found in the distribution itself.
Copyright © 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
Permission is granted to copy, distribute, and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of this license is included in the file COPYING.DOC.
%%name: Name of package. How it's spelled here is how it will appear in the entry (some maintainers are picky about this). %%short-description: One-line description, two lines if *really* necessary. Try to keep this short, please! %%full-description: full description, in plain text plus a basic set of HTML formating tags. Tags, , ,
, are allowed. Other '<' and '>' signs will show up in the
webpages as such. tage is necessary for a paragraph break. Two or
three short paragraphs max.
%%category: category name(s). A program may belong to more than one
category. Comma separated lists.
%%license: name of license, or the full license text if it is an
unusual license. URL for the license text is also allowed after the
name if the license is too long to put the full text in the entry. Be
sure to put the URL for the license text, and not just the URL for the
home page of the package under which the license is issued.
%%license-verified-by: Name and of the person who
checked the license of each source code file to make sure there were
no non-free files and that therefore the program is acceptably free.
%%license-verified-on: Date (yyyy-mm-dd) the license was verified.
%%maintainer: Name and of the person, persons, or
group who is maintaing the program. An email address only can also be
used, ie .
%%updated: Date of last major change to the entry expected to be of
interest to the user community. If a file is updated, the change
triggers its appearance in the "Ten Most Recently Updated Packages"
list on the home page of the Directory. The changes include, but are
not necessarily limited to, new releases of the software, a major
change in the hosting site of the software, or a major modification to
the description of the software. Changes that would not be considered
"major" in this context are a change in the maintainer's email address,
typographical fixes, or a new IRC channel.
%%touched: Date of last minor modification of this entry (such as
typographical fix), or date when this entry was last examined by a
human for problems or inaccuracies. If a file is touched, the change
does *not* trigger its appearance in the "Ten Most Recently Updated
Packages" list on the home page of the Directory
%%entry-added: Date the entry was first added. This should be entered
when the package is first written up and never changed after that.
%%keywords: List of other keywords. This is useful for search
engines. You can put as many as you want in a comma separated
list. Proprietary programs that people might think of in relation to
this one (ie Quicken and Gnucash) should be listed here and nowhere
else. Be generous with keywords; the user won't see them, and a longer
list will increase the chances of a useable hit. The package name, any
possible alternate spellings of the name, the language it is written
in if that language is not C, and the category the package(s) is in
should always be included.
%%interface: One or more of: Command line, X Window System, daemon, Web,
console, library, (curses|terminal), email
%%programs: List of programs included in this package. Leave this
blank if the only important program has the same name as the package
itself.
%%GNU: "yes" if the package is a an official GNU package, "no"
otherwise. The package *must* have been officially dubbed a GNU
packages by Richard. Simply being GPL'd is not enough. This is the
only field with an uppercase name.
%%web-page: URL for web page describing the package.
%%support: BASIS TYPE from [phone PHONE | URL]
BASIS is either "free" or "paid".
TYPE is what kind of support is offered.
For example, it could be
free user handholding %from 1-617-555-1212
paid extension/consulting from http://www.wedoit.com/
There's a separate field for help mailing lists, IRC
channels, and newsgroups; don't include those here.
%%doc: AUDIENCE TYPE [in FORMAT, ...] [as MEDIUM]
[from LOCATION | included]
AUDIENCE is the type of person it is addressed to
(typically "user" or "programmer").
TYPE is the kind information and presentation
(typically "introduction" or "reference"
or "reference card").
FORMAT is the file format, for machine-readable publication
(typically "Postscript", "DVI", "Texinfo" or "HTML").
This is a comma separated list. Don't use the word
"and" in it, because the web page generating program
will insert it.
For documentation included in the package itself,
which is available or can be produced in various formats,
this is optional.
MEDIUM is the publication medium (typically "book", "card"
or "CD-ROM"). For Internet distribution it is omitted.
LOCATION is the URL, either for the documentation itself
or for how to order a copy.
"included" means the doc is in the package itself.
For example, it could be:
User reference in Texinfo, Postscript, HTML from
http://www.gnu.org/doc/foo.html
Do not link to proprietary documentation; we're not interesed
in that. The documentation must be under a free license.
%%developers: developers' names, optionally followed by an email
address in <...>. For example, it could be Richard Stallman
, Fu Bar (comma separated list). This field
is for developers actively working on the majority of the program.
%%contributors: assisting developers' names, optionally followed by an
email address in <...>. (comma separated list). This should be
developers actively working on a subset of the program, or developers
who have contributed substantially in the past but who are no longer
active in the development of the program.
%%sponsors: institution, company, or government agency name,
optionally followed by an email address in <...> or a URL. This is a
semicolon separated list; commas can be used within each institution
or company name. If a company lets a developer work on a project on
company time, or if a project is developed for a class at an academic
institution, that company or academic institution should be listed as
a sponsor. Also listed should be groups that gave grant money to
further the project.
%%source-tarball: URL for where to obtain source code of a specified
version number: ie http://www.gnu.org/foobar-1.1.1.tar.gz
%%source-info: URL for a page that gives information on how and where
to download the programs beyond just a specified version number: ie a
page with a list of mirrors, information on getting packages for
different distributions, information on getting older versions, etc.
%%source-template: URL that always goes to a specified version
(usually the latest) of the program: ie
http://www.gnu.org/foobar-latest.tar.gz
%%debian: URLs for where to obtain Debian binary packages.
%%rpm: URLs for where to obtain RPM packages.
%%repository: Command line version of where to find a CVS repository
with the program's files. Can also list a URL for cvsweb access to the
repository, or a URL for a page that gives general information about
how to get CVS access to the package.
ie :pserver: anoncvs@savannah.gnu.org.foobar:/home/foobar or a
variation of this
http://www.foobar.org/cvs/
%%related: Related packages in the GNU Free Software Directory. These
are packages that users of this packages might also be interest in: ie
if the current programs is a Web browser, this would have names of
other browsers. It should *not* include the names of prerequisite
packages. The names listed here should always be programs that are
already in the directory, and the name of the .txt file without the
.txt should be used. For example, if a program named Samba is to be
related, and is listed as saMbA.txt, the string "saMbA" should be
listed here.
%%related-outside-directory: Same as above but the packages are
not in the GNU Free Software Directory
%%source-language: Computer language in which the source code is
written. Can have more than one entry. This is *not* for human
languages; if a package is available in a large number of human
languages, it should be noted in the full-description field.
%%supported-languages: Supported programming languages (for a
programming tool or library). This field is for computer languages,
*not* human languages. If a package is available in a large number of
human languages, it should be noted in the full-description field.
%%use-requirements: Prerequisites for using the executable. qThe
developer should have made *all* requirements/prerequisites relatively
easy to find. If there are no requirements/prerequisites listed on the
package's Web site, and none listed in the distribution (particularly
the README or the INSTALL files), assume there are no requirements or
prerequisites.
%%build-prerequisites: Prerequisites for building this package. This
is a comma separated list of packages that must be installed before
building this package. If the build prerequisites are a a standard
part of a GNU/Linux system, it is acceptable to omit them. Do not list
a compiler *unless* the program compiles with only a specific
compiler/version.
%%weak-prerequisites: Packages that are useful but not mandatory to
install before building or using this one. Entries here can be either
a package that helps (but is not necessary to) the functioning of the
entire package, ot that are required for only part of the
package. Whenever possible, note what the weak-prerequisite is for in
parantheses. For example, Foo (helps speed up processing of entire
program) or Bar (required if you want to use a sound card with this
program).
%%source-prerequisites: Packages whose source code must be present in
order to build this package.
*** All the magic in this field has not yet been implemented (although
some of it . ***
%%version: VERSION [STATUS] released on DATE
Required Fields:
VERSION is the version number. If VERSION has spaces in it,
then it must be in quotes, such as: "2.1 beta 2"
DATE is the release date expressed as yyyy-mm-dd.
Optional Fields:
STATUS is "planning", "devel", "alpha", "beta" or
"stable". If it's "planning", then the word "released" is
supressed, and the date is optional. If it's absent,
stable is assumed.
Multiple version entries are permitted in this field, and must be
separated by a semicolon. For example, both stable and devel
versions,each with a specific version number and release date, is
acceptable (2.0 stable released 2003-02-01; 2.1 devel released
2003-03-05)
%%announce-list: EMAIL_ADDRESS is email list for announcements of new
versions and news about the package
EMAIL_ADDRESS SUBSCRIPTION_ADDRESS [LIST_URL]
SUBSCRIPTION_ADDRESS is the address, if there is one, to
which send subscription requests should be sent.
LIST_URL (optional) is a URL where list subscription can be
done, or where there is additional information about the
list, such as how to get to to the list archives.
*Every* GNU package must have an announcement list.
%%announce-news: newsgroup on which announcements are made
%%help-list: EMAIL_ADDRESS is email list for asking for help
EMAIL_ADDRESS SUBSCRIPTION_ADDRESS [LIST_URL]
mailing list for asking for help to use the package
SUBSCRIPTION_ADDRESS is the address, if there is one, to
which subscription requests should be sent.
LIST_URL (optional) is a URL where list subscription can be
done, or where there is additional information about the
list, such as how to get to to the list archives.
%%help-news: newsgroup for asking for help
%%help-irc-channel: SERVER(NETWORK):PORT CHANNEL [;SERVER(NETWORK):PORT CHANNEL;...]
IRC channel for questions about using the program. Use a
comma separated list if there is more than one channel.
Examples: irc.foo.com: #program-name
irc.foo.com: #foobar; irc.quux.net:4567 #blahblah
(NETWORK) is optional, but if included, it should be
the overall network where the channel exists (e.g.,
DalNet, EFNet, OpenProjects).
%%dev-list: EMAIL_ADDRESS is email list for design and development discussion
EMAIL_ADDRESS SUBSCRIPTION_ADDRESS [LIST_URL]
SUBSCRIPTION_ADDRESS is the address, if there is one, to
which subscription requests should be sent.
LIST_URL (optional) is a URL where list subscription can be
done, or where there is additional information about the
list, such as how to get to to the list archives.
%%dev-news: newsgroup for design and devel discussion
%%dev-irc-channel: SERVER(NETWORK):PORT CHANNEL [;SERVER(NETWORK):PORT CHANNEL;...]
IRC channel for discussing development. Use a comma separated
list if there is more than one channel.
Examples: irc.foo.com: #program-name
irc.foo.com: #foobar; irc.quux.net:4567 #blahblah
%%bug-list: EMAIL_ADDRESS is email list for reporting bugs
EMAIL_ADDRESS SUBSCRIPTION_ADDRESS [LIST_URL]
SUBSCRIPTION_ADDRESS is the address, if there is one, to
which subscription requests should be sent.
LIST_URL (optional) is a URL where list subscription can be
done, or where there is additional information about the
list, such as how to get to to the list archives.
*Every* GNU package must have a bug report list.
Normally it should be bug-SOMETHING@gnu.org.
%%bug-news: newsgroup for reporting bugs
%%bug-database: URL for browsing a database of bugs. Many projects
have a Web interface to their bug tracking systems; examples include
Mozilla and Debian.
%%entry-compiled-by: Name and of the person who wrote
up the entry (*not* the nmae of the person who
wrote the program).