# SPDX-FileCopyrightText: no
# SPDX-License-Identifier: CC0-1.0
#
# The configuration for the package manager starts with the
# *backend* key, which picks one of the backends to use.
# In `main.py` there is a base class `PackageManager`.
# Implementations must subclass that and set a (class-level)
# property *backend* to the name of the backend (e.g. "dummy").
# That property is used to match against the *backend* key here.
#
# You will have to add such a class for your package manager.
# It is fairly simple Python code. The API is described in the
# abstract methods in class `PackageManager`. Mostly, the only
# trick is to figure out the correct commands to use, and in particular,
# whether additional switches are required or not. Some package managers
# have more installer-friendly defaults than others, e.g., DNF requires
# passing --disablerepo=* -C to allow removing packages without Internet
# connectivity, and it also returns an error exit code if the package did
# not exist to begin with.
---
#
# Which package manager to use, options are:
#  - apk         - Alpine Linux package manager
#  - apt         - APT frontend for DEB and RPM
#  - dnf         - DNF, the new RPM frontend
#  - entropy     - Sabayon package manager (is being deprecated)
#  - luet        - Sabayon package manager (next-gen)
#  - packagekit  - PackageKit CLI tool
#  - pacman      - Pacman
#  - pamac       - Manjaro package manager
#  - portage     - Gentoo package manager
#  - yum         - Yum RPM frontend
#  - zypp        - Zypp RPM frontend
#
# Not actually a package manager, but suitable for testing:
#  - dummy       - Dummy manager, only logs
#
backend: dummy

#
# Often package installation needs an internet connection.
# Since you may allow system installation without a connection
# and want to offer OPTIONAL package installation, it's
# possible to have no internet, yet have this packages module
# enabled in settings.
#
# You can skip the whole module when there is no internet
# by setting "skip_if_no_internet" to true.
#
# You can run a package-manager specific update procedure
# before installing packages (for instance, to update the
# list of packages and dependencies); this is done only if there
# is an internet connection.
#
# Set "update_db" to 'true' for refreshing the database on the
# target system. On target installations, which got installed by
# unsquashing, a full system update may be needed. Otherwise
# post-installing additional packages may result in conflicts.
# Therefore set also "update_system" to 'true'.
#
skip_if_no_internet: false
update_db: true
update_system: false

#
# List of maps with package operations such as install or remove.
# Distro developers can provide a list of packages to remove
# from the installed system (for instance packages meant only
# for the live system).
#
# A job implementing a distro specific logic to determine other
# packages that need to be installed or removed can run before
# this one. Distro developers may want to install locale packages
# or remove drivers not needed on the installed system.
# Such a job would populate a list of dictionaries in the global
# storage called "packageOperations" and that list is processed
# after the static list in the job configuration (i.e. the list
# that is in this configuration file).
#
# Allowed package operations are:
#  - *install*, *try_install*: will call the package manager to
#       install one or more packages. The install target will
#       abort the whole installation if package-installation
#       fails, while try_install carries on. Packages may be
#       listed as (localized) names, or as (localized) package-data.
#       See below for the description of the format.
# - *localInstall*: this is used to call the package manager
#       to install a package from a path-to-a-package. This is
#       useful if you have a static package archive on the install media.
#       The *pacman* package manager is the only one to specially support
#       this operation (all others treat this the same as *install*).
# - *remove*, *try_remove*: will call the package manager to
#       remove one or more packages. The remove target will
#       abort the whole installation if package-removal fails,
#       while try_remove carries on. Packages may be listed as
#       (localized) names.
# One additional key is recognized, to help netinstall out:
# - *source*: ignored, does get logged
# Any other key is ignored, and logged as a warning.
#
# There are two formats for naming packages: as a name or as package-data,
# which is an object notation providing package-name, as well as pre- and
# post-install scripts.
#
# Here are both formats, for installing vi. The first one just names the
# package for vi (using the naming of the installed package manager), while
# the second contains three data-items; the pre-script is run before invoking
# the package manager, and the post-script runs once it is done.
#
# - install
#   - vi
#   - package: vi
#     pre-script: touch /tmp/installing-vi
#     post-script: rm -f /tmp/installing-vi
#
# The pre- and post-scripts are optional, but you cannot leave both out
# if you do use the *package* key: using "package: vi" with neither script
# option will trick Calamares into trying to install a package named
# "package: vi", which is unlikely to work.
#
# The pre- and post-scripts are **not** executed by a shell unless you
# explicitly invoke `/bin/sh` in them. The command-lines are passed
# to exec(), which does not understand shell syntax. In other words:
#
#     pre-script: ls | wc -l
#
# Will fail, because `|` is passed as a command-line argument to ls,
# as are `wc`, and `-l`. No shell pipeline is set up, and ls is likely
# to complain. Invoke the shell explicitly:
#
#     pre-script: /bin/sh -c \"ls | wc -l\"
#
# The above note on shell-expansion applies to versions up-to-and-including
# Calamares 3.2.12, but will change in future.
#
# Any package name may be localized; this is used to install localization
# packages for software based on the selected system locale. By including
# the string `LOCALE` in the package name, the following happens:
#
# - if the system locale is English (any variety), then the package is not
#   installed at all,
# - otherwise `$LOCALE` or `${LOCALE}` is replaced by the 'lower-cased' BCP47
#   name of the 'language' part of the selected system locale (not the
#   country/region/dialect part), e.g. selecting "nl_BE" will use "nl"
#   here.
#
# Take care that just plain `LOCALE` will not be replaced, so `foo-LOCALE` will
# be left unchanged, while `foo-$LOCALE` will be changed. However, `foo-LOCALE`
# **will** be removed from the list of packages (i.e. not installed), if
# English is selected. If a non-English locale is selected, then `foo-LOCALE`
# will be installed, unchanged (no language-name-substitution occurs).
#
# The following installs localizations for vi, if they are relevant; if
# there is no localization, installation continues normally.
#
# - install
#   - vi-$LOCALE
#   - package: vi-${LOCALE}
#     pre-script: touch /tmp/installing-vi
#     post-script: rm -f /tmp/installing-vi
#
# When installing packages, Calamares will invoke the package manager
# with a list of package names if it can; package-data prevents this because
# of the scripts that need to run. In other words, this:
#
# - install:
#   - vi
#   - binutils
#   - package: wget
#     pre-script: touch /tmp/installing-wget
#
# This will invoke the package manager three times, once for each package,
# because not all of them are simple package names. You can speed up the
# process if you have only a few pre-scripts, by using multiple install targets:
#
# - install:
#   - vi
#   - binutils
# - install:
#   - package: wget
#     pre-script: touch /tmp/installing-wget
#
# This will call the package manager once with the package-names "vi" and
# "binutils", and then a second time for "wget". When installing large numbers
# of packages, this can lead to a considerable time savings.
#
operations:
  - install:
    - vi
    - vi-${LOCALE}
    - wget
    - binutils
  - remove:
    - vi
    - wget
    - binutils