@@ -0,0 +1,204 @@
+Specification of the user interaction configuration file
+========================================================
+
+:Version:
+ 1.0
+
+:Authors:
+ Martin Kolman <mkolman(a)redhat.com>
+
+This specification aims to establish a configuration file format, that can be used
+to communicate information about which installation screens have been seen by the user
+during the installation. Optionally the configuration file might also contain
information
+about which configuration options have been changed by the user and if the user has
+explicitly requested post installation setup tools to be disabled.
+
+While this configuration file is primarily meant to be read (and potentially changed)
+by *post* installation tools (such as for example Initial Setup and Gnome Initial
setup),
+Anaconda will take an existing configuration file into account at startup. This is
meant
+to accommodate tools that are run *before* Anaconda is started, such as a system-wide
+language selection tool that runs before Anaconda is started and which sets language
+for both Anaconda and a Live installation environment.
+
+
+Configuration file location
+---------------------------
+
+The user interaction configuration file is stored in: ``/etc/sysconfig/anaconda``
+
+
+General configuration file systax
+---------------------------------
+
+The configuration file is based on the INI file de-facto standard,
+eq.: key=value assignments and square bracket framed section headers.
+
+For Python programs this file format can be parsed and written by the ConfigParser[0]
module availabe
+from the standrad library. Comparable INI file parsing and writing modules are available
for
+most other programming languages.
+
+Example:
+
+::
+
+ top_level_key=some_value
+
+ [section_1]
+ key_a_in_section1=some_value
+ key_b_in_section1=some_value
+
+ [section_2]
+ key_a_in_section2=some_value
+
+Boolean values are marked with 1 for true and 0 for false.
+
+Example:
+
+::
+
+ true_key=1
+ false_key=0
+
+
+Toplevel namespace
+------------------
+
+The toplevel configuration file namespace can only contain the
+``post_install_tools_disabled`` key and section headers.
+
+The ``post_install_tools_disabled`` key corresponds to using ``firstboot --disable``
command in the
+installation kickstart, that requests the post installation setup tools to be skipped.
If this key is present
+and set to 1, then any post installation tools that parses the user interaction file
should make sure
+it won't be started again and then terminate immediately.
+
+Section headers each correspond to a spoke screen shown in Anaconda. Hubs are not
represented as section
+as there is nothing that can be directly set on a hub in Anaconda.
+All currently visible spokes in Anaconda will be enumerated as a section headers by
Anaconda in the
+configuration file. Note that this can include spokes provided by addons[1], if any
Anaconda addons that provide
+additional spokes are present during the installation run.
+
+
+Section naming
+--------------
+
+Section headers are named according to the Anaconda spoke class name. For example
``DatetimeSpoke``
+or ``KeyboardSpoke``.
+
+To get a list of all such spokes run the ``list_spokes`` script from the ``scripts``
directory in the Anaconda source
+code tree:
+
+::
+
+ git clone
https://github.com/rhinstaller/anaconda
+ cd anaconda/scripts
+ ./list_screens
+
+Note that this script only lists Anaconda spokes, not spokes provided by addons[1] or
Initial Setup.
+
+It is also possible to check for the *Entered spoke:* entries in the
``/tmp/anaconda.log`` file during an installation
+to correlate spokes on the screen to spoke names.
+
+
+Section namespace
+-----------------
+
+Each section *must* contain the ``visited`` key with a value of either 1 if the user has
visited
+the corresponding screen or 0 if not.
+
+Optionally each section can contain one or more keys with the ``changed_`` prefix which
track if the user
+has changed an option on the screen. If the option is changed by the user, the
corresponding key is set
+to 1. If the given option has not been changed by the user then the corresponding key
can either be
+omitted or set to 0.
+
+Example:
+
+::
+
+ [DatetimeSpoke]
+ visited=1
+ changed_timezone=1
+ changed_ntp=0
+ changed_timedate=1
+
+In this example the user has visited the date & time spoke and has changed the
timezone & time/date,
+but not the NTP settings. Note that the ``changed_ntp`` key could also be omitted as the
user has not changed
+the NTP options.
+
+Another example:
+
+::
+
+ [KeyboardSpoke]
+ visited=0
+
+Here the user has not visited the keyboard spoke and thus could not have changed any
options,
+so all ``changed_*`` keys (if any) have been omitted.
+
+Note that if a spoke section is missing, it should be assumed that the corresponding
screen has not been visited.
+On othe other hand, if a screen *has been visited*, the section *must* be present, with
the ``visited`` key being equal to 1.
+
+
+Full configuration file example
+-------------------------------
+
+::
+
+ post_install_tools_disabled=0
Yeah, that looks good - let's add a toplevel group to hold the
post_install_tools_disabled key (and possibly other such top-level keys if needed in the
future).
The only possible issue with this could be if a screen called "General" was
added somewhere in the installation process, so we need to assure that does not happen (or
use a different name for the toplevel section ?).
--
To view this pull request on github, visit