197 lines
8.0 KiB
Plaintext
197 lines
8.0 KiB
Plaintext
# 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
|