diff options
Diffstat (limited to 'app-misc/calamares-config-redcore/files/settings.conf')
| -rw-r--r-- | app-misc/calamares-config-redcore/files/settings.conf | 148 |
1 files changed, 1 insertions, 147 deletions
diff --git a/app-misc/calamares-config-redcore/files/settings.conf b/app-misc/calamares-config-redcore/files/settings.conf index 713af9e0..c17ae61c 100644 --- a/app-misc/calamares-config-redcore/files/settings.conf +++ b/app-misc/calamares-config-redcore/files/settings.conf @@ -1,89 +1,5 @@ -# 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: -# - 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 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 -# config: owncloud.conf - -# 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 -# immediately following exec phase, this job will not be executed. -# -# YAML: list of lists of strings. sequence: - show: - welcome @@ -115,73 +31,11 @@ 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. -# -# 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, 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 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. -# -# +hide-back-and-next-during-exec: false quit-at-end: false |