settings.conf

# SPDX-FileCopyrightText: no
# SPDX-License-Identifier: CC0-1.0
#
# Configuration file for Calamares
#
# This is the top-level configuration file for Calamares.
# It specifies what modules will be used, as well as some
# overall characteristics -- is this a setup program, or
# an installer. More specific configuration is devolved
# to the branding file (for the UI) and the individual
# module configuration files (for functionality).
---
# 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 these keys:
# - *module* name, which matches the module name from the module descriptor
#   (usually the name of the directory under `src/modules/`, but third-
#   party modules may diverge.
# - *id* (optional) an identifier to distinguish this instance from
#   all the others. If none is given, the name of the module is used.
#   Together, the module and id form an instance key (see below).
# - *config* (optional) a filename for the configuration. If none is
#   given, *module*`.conf` is used (e.g. `welcome.conf` for the welcome
#   module)
# - *weight* (optional) In the *exec* phase of the sequence, progress
#   is reported as jobs are completed. The jobs from a single module
#   together contribute the full weight of that module. The overall
#   progress (0 .. 100%) is divided up according to the weight of each
#   module. Give modules that take a lot of time to complete, a larger
#   weight to keep the overall progress moving along steadily. This
#   weight overrides a weight given in the module descriptor. If no weight
#   is given, uses the value from the module descriptor, or 1 if there
#   isn't one there either.
#
# 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.
# "packagechooserq@licenseq", where "packagechooserq" is the module name (for the packagechooserq
# viewmodule) and "licenseq" 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 may 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`. Specify a *config* for
# any module (also implicit instances) to change which file is used.
#
# 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:       licenseq
#  module:   packagechooserq
#  config:   licenseq.conf

instances:
- id:       softwares
  module:   netinstall
  config:   netinstall-software.conf

- id:       update
  module:   shellprocess
  config:   shellprocess-update.conf

- id:       final
  module:   shellprocess
  config:   shellprocess-final.conf

- id:       kstars_indi
  module:   packagechooserq
  config:   packagechooserq_kstars_indi.conf

- id:       gps
  module:   packagechooser
  config:   packagechooser_gps.conf

- id:       ftp
  module:   packagechooser
  config:   packagechooser_ftp.conf

- id:       bluetooth
  module:   packagechooser
  config:   packagechooser_bluetooth.conf

- id:       power
  module:   packagechooser
  config:   packagechooser_power.conf

- id:       readme
  module:   notesqml
  config:   readme.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
  - locale
  - keyboard
  - packagechooserq@kstars_indi
  - netinstall@softwares
  - packagechooser@gps
  - packagechooser@ftp
  - packagechooser@bluetooth
  - packagechooser@power
  - notesqml@readme
- exec:
  - locale
  - keyboard
  - localecfg
  - shellprocess@update
  - contextualprocess
  - packages
  - shellprocess@final
- 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: astroarch

# 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: 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: true

# 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, the "Next" and "Back" button will be hidden once
# you start the 'Installation'.
#
# Default is false, but Calamares will complain if this is not explicitly set.
#
# YAML: boolean.
hide-back-and-next-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