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
|
---
#
# Which package manager to use, options are:
# - packagekit - PackageKit CLI tool
# - zypp - Zypp RPM frontend
# - yum - Yum RPM frontend
# - dnf - DNF, the new RPM frontend
# - urpmi - Mandriva package manager
# - apt - APT frontend for DEB and RPM
# - pacman - Pacman
# - portage - Gentoo package manager
# - entropy - Sabayon package manager
# - apk = Alpine Linux package manager
# - dummy - Dummy manager, only logs
#
backend: portage
#
# 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
#
# 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:
- remove:
- app-admin/calamares
- app-misc/calamares-config-redcore
- app-misc/redcore-live
- x11-themes/redcore-artwork-calamares
|
