napcok/calamares
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Documentation: reformat settings.conf

Browse Source 
- format for 80 columns
 - blank line between paragraphs
 - remove some outdated things
 - add more explanation for instances
This commit is contained in:
Adriaan de Groot 2017-12-19 16:11:51 -05:00
parent 55ed2ba4c0
commit d4acbb4374
1 changed files with 75 additions and 61 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

136
settings.conf
View File

@ -1,36 +1,43 @@
# Configuration file for Calamares # Configuration file for Calamares
# Syntax is YAML 1.2 # Syntax is YAML 1.2
--- ---
# Modules can be job modules (with different interfaces) and QtWidgets view modules. # Modules can be job modules (with different interfaces) and QtWidgets view
# They could all be placed in a number of different paths. # modules. They could all be placed in a number of different paths.
# "modules-search" is a list of strings, each of these can either be a full path to a # "modules-search" is a list of strings, each of these can either be a full
# directory or the keyword "local". # path to a directory or the keyword "local".
# "local" means LIBDIR/calamares/modules with settings in SHARE/calamares/modules or #
# /etc/calamares/modules. # "local" means:
# - modules in $LIBDIR/calamares/moduleswith
# - settings in SHARE/calamares/modules or /etc/calamares/modules.
#
# YAML: list of strings. # YAML: list of strings.
modules-search: [ local ] modules-search: [ local ]
# Instances section. This section is optional, and it defines custom instances for # Instances section. This section is optional, and it defines custom instances
# modules of any kind. An instance entry has an instance name, a module name, and # for modules of any kind. An instance entry has an instance name, a module
# a configuration file name. # name, and a configuration file name. The primary goal of this mechanism is
# The primary goal of this mechanism is to allow loading multiple instances of the # to allow loading multiple instances of the same module, with different
# same module, with different configuration. If you don't need this, the instances # configuration. If you don't need this, the instances section can safely be
# section can safely be left empty. # left empty.
# Module name plus instance name makes an instance key, e.g. "webview@owncloud", #
# where "webview" is the module name (for the webview viewmodule) and "owncloud" # Module name plus instance name makes an instance key, e.g.
# is the instance name, which loads a configuration file named "owncloud.conf" from # "webview@owncloud", where "webview" is the module name (for the webview
# any of the configuration file paths, including the webview module directory. # viewmodule) and "owncloud" is the instance name, which loads a configuration
# This instance key can then be referenced in the sequence section. # file named "owncloud.conf" from any of the configuration file paths,
# For all modules without a custom instance specification, a default instance is # including the webview module directory. This instance key can then be
# generated automatically by Calamares. Therefore a statement such as "webview" in # referenced in the sequence section.
# the sequence section automatically implies an instance key of "webview@webview" #
# even without explicitly defining this instance, and the configuration file for # For all modules without a custom instance specification, a default instance
# this default instance "<modulename>@<modulename>" is always assumed to be # is generated automatically by Calamares. Therefore a statement such as
# "<modulename>.conf". # "webview" in the sequence section automatically implies an instance key of
# For more information on running module instances, run Calamares in debug mode # "webview@webview" even without explicitly defining this instance, and the
# and check the Modules page in the Debug information interface. # configuration file for this default instance "<modulename>@<modulename>" is
# always assumed to be "<modulename>.conf".
#
# For more information on running module instances, run Calamares in debug
# mode and check the Modules page in the Debug information interface.
#
# YAML: list of maps of string:string key-value pairs. # YAML: list of maps of string:string key-value pairs.
#instances: #instances:
#- id: owncloud #- id: owncloud
# module: webview # module: webview
@ -38,25 +45,25 @@ modules-search: [ local ]
# Sequence section. This section describes the sequence of modules, both # Sequence section. This section describes the sequence of modules, both
# viewmodules and jobmodules, as they should appear and/or run. # viewmodules and jobmodules, as they should appear and/or run.
#
# A jobmodule instance key (or name) can only appear in an exec phase, whereas # A jobmodule instance key (or name) can only appear in an exec phase, whereas
# a viewmodule instance key (or name) can appear in both exec and show phases. # a viewmodule instance key (or name) can appear in both exec and show phases.
# There is no limit to the number of show or exec phases. However, the same module # There is no limit to the number of show or exec phases. However, the same
# instance key should not appear more than once per phase, and deployers should # module instance key should not appear more than once per phase, and
# take notice that the global storage structure is persistent throughout the # deployers should take notice that the global storage structure is persistent
# application lifetime, possibly influencing behavior across phases. # throughout the application lifetime, possibly influencing behavior across
# A show phase defines a sequence of viewmodules (and therefore pages). These # phases. A show phase defines a sequence of viewmodules (and therefore
# viewmodules can offer up jobs for the execution queue. # pages). These viewmodules can offer up jobs for the execution queue.
# An exec phase displays a progress page (with brandable slideshow). This progress #
# page iterates over the modules listed in the *immediately preceding* show phase, # An exec phase displays a progress page (with brandable slideshow). This
# and enqueues their jobs, as well as any other jobs from jobmodules, in the order # progress page iterates over the modules listed in the *immediately
# defined in the current exec phase. # preceding* show phase, and enqueues their jobs, as well as any other jobs
# It then executes the job queue and clears it. If a viewmodule offers up a job # from jobmodules, in the order defined in the current exec phase.
# for execution, but the module name (or instance key) isn't listed in the #
# It then executes the job queue and clears it. If a viewmodule offers up a
# job for execution, but the module name (or instance key) isn't listed in the
# immediately following exec phase, this job will not be executed. # immediately following exec phase, this job will not be executed.
# WARNING: when upgrading from Calamares 1.1, this section requires manual #
# intervention. There are no fixed prepare/install/postinstall phases any more,
# and all limitations on the number of phases, number of pages, and number of
# instances are lifted.
# YAML: list of lists of strings. # YAML: list of lists of strings.
sequence: sequence:
- show: - show:
@ -101,30 +108,37 @@ sequence:
# - webview@owncloud # - webview@owncloud
- finished - finished
# A branding component is a directory, either in SHARE/calamares/branding or in # A branding component is a directory, either in SHARE/calamares/branding or
# /etc/calamares/branding (the latter takes precedence). The directory must contain a # in /etc/calamares/branding (the latter takes precedence). The directory must
# YAML file branding.desc which may reference additional resources (such as images) as # contain a YAML file branding.desc which may reference additional resources
# paths relative to the current directory. # (such as images) as paths relative to the current directory.
# A branding component can also ship a QML slideshow for execution pages, along with #
# translation files. # A branding component can also ship a QML slideshow for execution pages,
# Only the name of the branding component (directory) should be specified here, Calamares # along with translation files.
# then takes care of finding it and loading the contents. #
# Only the name of the branding component (directory) should be specified
# here, Calamares then takes care of finding it and loading the contents.
#
# YAML: string. # YAML: string.
branding: default branding: default
# If this is set to true, Calamares will show an "Are you sure?" prompt right before # If this is set to true, Calamares will show an "Are you sure?" prompt right
# each execution phase, i.e. at points of no return. If this is set to false, no prompt # before each execution phase, i.e. at points of no return. If this is set to
# is shown. # false, no prompt is shown. Default is false.
# Default is false. #
# YAML: boolean. # YAML: boolean.
prompt-install: false prompt-install: false
# If this is set to true, Calamares will execute all target environment commands in the # If this is set to true, Calamares will execute all target environment
# current environment, without chroot. This setting is considered experimental, and it # commands in the current environment, without chroot. This setting should
# should only be used when setting up Calamares as a post-install configuration tool, as # only be used when setting up Calamares as a post-install configuration tool,
# opposed to a full operating system installer. # as opposed to a full operating system installer.
# Some official Calamares modules are not expected to function with this setting. #
# Packagers beware, here be dragons. # Some official Calamares modules are not expected to function with this
# Default is false. # setting. (e.g. partitioning seems like a bad idea, since that is expected to
# have been done already)
#
# Default is false (for a normal installer).
#
# YAML: boolean. # YAML: boolean.
dont-chroot: false dont-chroot: false