New Installer: Roles
A role describes how the system is going to be used. More than one role can be used at the same time. It is supposed to be a software collection with (optional) additional configuration module. Thus it should be able to work with and understand:
- patterns
- rpms
- installer config
(described in
and separate document)
A role could be seen as a higher level of patterns with an additional configuration mechanism. A role could also be regarded as a package which knows about the software within a pattern or some arbitrarily chosen set of packages with a default configuration that is provided by a product/add-on.
-
role name
Role must have a unique name which the system can easily identify before/after installation. After the installer has finished installing patterns and packages, the system must track the role name together with role version.
Having a role- or role-sle or role-openSUSE- prefix should be enough to identify some role if its data are going to be stored in a shared repository, like rpm database. It could be similar to the existing openSUSE pattern metapackages like patterns-openSUSE-base-*.rpm .
-
role version
Role version should be independent of any product or add-on where they are being used. The system should be able to query easily the role version. Following the role requirements it is not allowed to have more than a single role version with a specific name installed.
-
role settings
A role can offer the user customization during installation workflow. Thus it can contain some configuration options which a user selects and which hide the complexity of software and its configuration dependencies in the background.
-
role summary
Some basic information about the role should be available to the customer during the installation process via the installer UI.
-
role features
Additional components which would be useful for the installer like icon, localizations, detailed description, etc.
As already described above the requirements say the role should be uniquely identified by name and version, it should keep its dependencies stored on the system together with the role configuration. Thus a candidate for a role container would be rpm package.
Alternatively we could leverage the existing implementation of patterns and extend it with the role behaviour as the patterns already fulfill most of the role requirements. Patterns have a visibility flag, roles can be implemented as hidden patterns which would not be displayed in the software manager together with regular patterns.
A role can modify the installation wizard (e.g., ask user) if selected during:
- installation wizard - selection of the role and its settings
- apply config - optional configuration of some system properties
- first boot
-
SLES
- physical, virtualized
-
openSUSE
- GNOME, KDE
-
generic
-
web server
Including software dependencies (nginx, apache, postgresql), software configuration (document root, database connection), system configuration (firewall settings) -
DNS server
-