1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
|
# 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: pacman
#
# 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: false
update_system: false
# pacman specific options
#
# *num_retries* should be a positive integer which specifies the
# number of times the call to pacman will be retried in the event of a
# failure. If it is missing, it will be set to 0.
#
# *disable_download_timeout* is a boolean that, when true, includes
# the flag --disable-download-timeout on calls to pacman. When missing,
# false is assumed.
#
# *needed_only* is a boolean that includes the pacman argument --needed
# when set to true. If missing, false is assumed.
pacman:
num_retries: 0
disable_download_timeout: false
needed_only: 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:
- try_remove:
- plasma-framework
- kpmcore
- yaml-cpp
- mkinitcpio-archiso
- boost-libs
- ckbcomp
- hwinfo
- qt5-xmlpatterns
- squashfs-tools
- kconfig
- kcoreaddons
- kiconthemes
- ki18n
- kio
- solid
- qt5-svg
- calamares
|
