diff options
Diffstat (limited to 'app-misc/calamares-config-redcore/files/settings.conf')
| -rw-r--r-- | app-misc/calamares-config-redcore/files/settings.conf | 192 |
1 files changed, 130 insertions, 62 deletions
diff --git a/app-misc/calamares-config-redcore/files/settings.conf b/app-misc/calamares-config-redcore/files/settings.conf index ba9e42b7..38726d6f 100644 --- a/app-misc/calamares-config-redcore/files/settings.conf +++ b/app-misc/calamares-config-redcore/files/settings.conf @@ -1,36 +1,62 @@ # Configuration file for Calamares # Syntax is YAML 1.2 --- -# Modules can be job modules (with different interfaces) and QtWidgets view 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 -# directory or the keyword "local". -# "local" means LIBDIR/calamares/modules with settings in SHARE/calamares/modules or -# /etc/calamares/modules. +# Modules can be job modules (with different interfaces) and QtWidgets view +# 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 directory or the keyword "local". +# +# "local" means: +# - modules in $LIBDIR/calamares/modules, with +# - settings in SHARE/calamares/modules or /etc/calamares/modules. +# In debug-mode (e.g. calamares -d) "local" also adds some paths +# that make sense from inside the build-directory, so that you +# can build-and-run with the latest modules immediately. +# +# Strings other than "local" are taken as paths and interpreted +# relative to wherever Calamares is started. It is therefore **strongly** +# recommended to use only absolute paths here. This is mostly useful +# if your distro has forks of standard Calamares modules, but also +# uses some form of upstream packaging which might overwrite those +# forked modules -- then you can keep modules somewhere outside of +# the "regular" module tree. +# +# # YAML: list of strings. modules-search: [ local ] -# Instances section. This section is optional, and it defines custom instances for -# modules of any kind. An instance entry has an instance name, a module name, and -# a configuration file name. -# The primary goal of this mechanism is to allow loading multiple instances of the -# same module, with different configuration. If you don't need this, the instances -# section can safely be 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" -# is the instance name, which loads a configuration file named "owncloud.conf" from -# any of the configuration file paths, including the webview module directory. -# This instance key can then be referenced in the sequence section. -# For all modules without a custom instance specification, a default instance is -# generated automatically by Calamares. Therefore a statement such as "webview" in -# the sequence section automatically implies an instance key of "webview@webview" -# even without explicitly defining this instance, and the 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. +# Instances section. This section is optional, and it defines custom instances +# for modules of any kind. An instance entry has an module name, an instance +# name, and a configuration file name. The primary goal of this mechanism is +# to allow loading multiple instances of the same module, with different +# configuration. If you don't need this, the instances section can safely be +# 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" is the instance name. In the *sequence* +# section below, use instance-keys to name instances (instead of just +# a module name, for modules which have only a single instance). +# +# Every module implicitly has an instance with the instance name equal +# to its module name, e.g. "welcome@welcome". In the *sequence* section, +# mentioning a module without a full instance key (e.g. "welcome") +# means that implicit module. +# +# An instance must specify its configuration file (e.g. `webview-home.conf`). +# The implicit instances all have configuration files named `<module>.conf`. +# This (implict) way matches the source examples, where the welcome +# module contains an example `welcome.conf`. +# +# For more information on running module instances, run Calamares in debug +# mode and check the Modules page in the Debug information interface. +# +# A module that is often used with instances is shellprocess, which will +# run shell commands specified in the configuration file. By configuring +# more than one instance of the module, multiple shell sessions can be run +# during install. +# # YAML: list of maps of string:string key-value pairs. - #instances: #- id: owncloud # module: webview @@ -38,27 +64,26 @@ modules-search: [ local ] # Sequence section. This section describes the sequence of modules, both # 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 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 -# instance key should not appear more than once per phase, and deployers should -# take notice that the global storage structure is persistent throughout the -# application lifetime, possibly influencing behavior across phases. -# A show phase defines a sequence of viewmodules (and therefore 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, -# and enqueues their jobs, as well as any other jobs from jobmodules, in the order -# defined in the current exec phase. -# 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 +# There is no limit to the number of show or exec phases. However, the same +# module instance key should not appear more than once per phase, and +# deployers should take notice that the global storage structure is persistent +# throughout the application lifetime, possibly influencing behavior across +# phases. A show phase defines a sequence of viewmodules (and therefore +# 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, and enqueues their jobs, as well as any other jobs +# from jobmodules, in the order defined in the current exec phase. +# +# 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. -# 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. -sequence: - show: - welcome - locale @@ -89,30 +114,73 @@ sequence: - show: - finished -# A branding component is a directory, either in SHARE/calamares/branding or in -# /etc/calamares/branding (the latter takes precedence). The directory must contain a -# YAML file branding.desc which may reference additional resources (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. -# Only the name of the branding component (directory) should be specified here, Calamares -# then takes care of finding it and loading the contents. +# A branding component is a directory, either in SHARE/calamares/branding or +# in /etc/calamares/branding (the latter takes precedence). The directory must +# contain a YAML file branding.desc which may reference additional resources +# (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. +# +# 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. branding: redcore_branding -# If this is set to true, Calamares will show an "Are you sure?" prompt right before -# each execution phase, i.e. at points of no return. If this is set to false, no prompt -# is shown. -# Default is false. +# If this is set to true, Calamares will show an "Are you sure?" prompt right +# before each execution phase, i.e. at points of no return. If this is set to +# false, no prompt is shown. Default is false, but Calamares will complain if +# this is not explicitly set. +# # YAML: boolean. prompt-install: true -# If this is set to true, Calamares will execute all target environment commands in the -# current environment, without chroot. This setting is considered experimental, and it -# should only be used when setting up Calamares as a post-install configuration tool, 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. -# Default is false. +# If this is set to true, Calamares will execute all target environment +# commands in the current environment, without chroot. This setting should +# only be used when setting up Calamares as a post-install configuration tool, +# as opposed to a full operating system installer. +# +# Some official Calamares modules are not expected to function with this +# 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), but Calamares will complain if +# this is not explicitly set. +# # YAML: boolean. dont-chroot: false + +# If this is set to true, Calamares refers to itself as a "setup program" +# rather than an "installer". Defaults to the value of dont-chroot, but +# Calamares will complain if this is not explicitly set. +oem-setup: false + +# If this is set to true, the "Cancel" button will be disabled entirely. +# The button is also hidden from view. +# +# This can be useful if when e.g. Calamares is used as a post-install +# configuration tool and you require the user to go through all the +# configuration steps. +# +# Default is false, but Calamares will complain if this is not explicitly set. +# +# YAML: boolean. +disable-cancel: false + +# If this is set to true, the "Cancel" button will be disabled once +# you start the 'Installation', meaning there won't be a way to cancel +# the Installation until it has finished or installation has failed. +# +# Default is false, but Calamares will complain if this is not explicitly set. +# +# YAML: boolean. +disable-cancel-during-exec: false + +# If this is set to true, then once the end of the sequence has +# been reached, the quit (done) button is clicked automatically +# and Calamares will close. Default is false: the user will see +# that the end of installation has been reached, and that things are ok. +# +# +quit-at-end: false |