<?xml version="1.0"?>
-<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"dtd/docbook-xml/4.1.2/docbookx.dtd" [
<!ENTITY statuscodes_table SYSTEM "include/statuscodes.xml">
<!ENTITY command_list SYSTEM "include/commands.xml">
<!ENTITY priority_table SYSTEM "include/priorities.xml">
<!ENTITY type_table SYSTEM "include/types.xml">
+<!ENTITY % versiondata SYSTEM "include/version.xml"> %versiondata;
]>
<article>
<articleinfo>
<title>Configuration management</title>
- <subtitle>Protocol version 2</subtitle>
- <releaseinfo>Revision 7.0</releaseinfo>
+ <subtitle>Protocol version 2.1</subtitle>
+ <releaseinfo>Revision 7.1, Debian Policy &version;, &date;</releaseinfo>
<author>
- <firstname>
- Wichert
- </firstname>
- <surname>
- Akkerman
- </surname>
+ <firstname>Wichert</firstname>
+ <surname>Akkerman</surname>
<affiliation>
- <orgname>
- The Debian Project
- </orgname>
+ <orgname>The Debian Project</orgname>
<address><email>wakkerma@debian.org</email></address>
</affiliation>
</author>
<author>
- <firstname>
- Joey
- </firstname>
- <surname>
- Hess
- </surname>
+ <firstname>Joey</firstname>
+ <surname>Hess</surname>
<affiliation>
- <orgname>
- The Debian Project
- </orgname>
+ <orgname>The Debian Project</orgname>
<address><email>joeyh@debian.org</email></address>
</affiliation>
</author>
<copyright>
- <year>
- 1998
- </year>
- <year>
- 1999
- </year>
- <year>
- 2000
- </year>
- <holder>
- Wichert Akkerman and Joey Hess
- </holder>
+ <year>1998</year>
+ <year>1999</year>
+ <year>2000</year>
+ <holder>Wichert Akkerman and Joey Hess</holder>
</copyright>
<legalnotice>
<para>
</para>
</legalnotice>
</articleinfo>
-
+
<sect1>
<title>
Introduction
use a flat space, or divide its space further into
sub-hierarchies. If multiple packages share a common purpose they
may use a shared toplevel hierarchy, preferably with the same name
- as a shared (virtual) package name (for example, both
+ as a shared (virtual) package name (for example, both
<application>mutt</application> and <application>elm</application>
- can use <literal>mail-reader</literal>,
+ can use <literal>mail-reader</literal>,
<application>strn</application> and <application>nn</application>
could use <literal>news-reader</literal>). This
shared tree can also be used as a default, ie a variable
- <literal>news-reader/nntpserver</literal> can be used by
+ <literal>news-reader/nntpserver</literal> can be used by
<application>strn</application> if <literal>strn/nntpserver</literal>
does not exist.
</para>
</para>
</sect2>
</sect1>
-
+
<sect1>
<title>
Templates
So, what do we need to store in a variable template? Of course we
need a name to identify the template. Template names are made up of
components separated by the character `/' (slash).
- Each component is limited to alphanumerics and `+' `-' `.'
- (plus, minus, full stop).
+ Each component is limited to alphanumerics and `+' `-' `.' `_'
+ (plus, minus, full stop, underscore).
</para>
<para>
A type is also needed so data can be verified. Here is a table
</para>
<para>
This information is stored in a template file that consists of
- stanzas in a rfc-822 compliant format, separated by blank lines.
+ stanzas in a rfc-822 compliant format, separated by blank lines.
Here is an example:
<programlisting>
Template: hostname
something like "mycompany.com" or "myuniversity.edu".
</programlisting>
</para>
+ <para>
+ For localization, the description field (and also the choices
+ field of a select or multiselect type question, and the
+ default field of a string or password type question) can be
+ supplemented with versions for other languages. These are
+ named <emphasis>Description-ll</emphasis>,
+ <emphasis>Description-ll_LL</emphasis>,
+ <emphasis>Description-ll_LL.encoding</emphasis> and so on.
+ </para>
</sect2>
</sect1>
<sect1>
exactly one line.
</para>
<para>
- After sending each command to stdout, the client
+ After sending each command to stdout, the client
should read one line from stdin. This is the response to the command,
and it will be in the form of a number followed by whitespace and an
optional string of text. The number is the status code, while the
section on templates.
</para>
<para>
- The config-file contains a new element, which I call the configmodule.
- This is a program that will determine the configuration before the
- package is unpacked. This means it is run <emphasis>before</emphasis>
- the preinst, and before the package is unpacked! This is done to make
- sure that we can use the desired configuration in the preinst if
- necessary.
+ The config-file contains a new element, which I call the
+ configmodule. This is a program that will determine the
+ configuration before the package is unpacked. This means it is
+ usually run <emphasis>before</emphasis> the preinst, and before
+ the package is unpacked!
+ <note>
+ <simpara>Please see debconf-devel(7) for details.</simpara>
+ </note>
+ This is done to make sure that we can
+ use the desired configuration in the preinst if necessary.
</para>
<para>
How does the configmodule get its information? The configmodule