And indeed that’s the nature of the roles mechanisms in the installer. A role can redefine basically everything in the installation process: the partitioning schema, the software selection, the sequence of steps in the installer… The Kubic animated gif shows how Kubic uses the very same roles mechanism to implement the kubeadm vs MicroOS thingy.

Using the roles as a mechanism to select the desktop is admittedly blending the original intention of the mechanism a little bit. So your concern is totally fair. In this old post we explained the reasons for starting to use roles in order to select the desktop instead of the old mechanism.

https://lizards.opensuse.org/2017/02/20/highlights-of-yast-development-sprint-31/

In short, using the roles mechanism for selecting the desktop allows openSUSE to take advantage of a mechanism that is powerful, actively maintained in the installer and that can be easily kept up-to-date without needing to touch the installer itself.

Am looking forward to viewing changes in the Kubic install, IMO up until now it has been a big obstacle to properly installing both because it looks so different from a normal install (seems to be addressed) and without guidance how to set up properly (remains to be seen).

Enabling the networking backend in installation will probably be a significant and well-received feature removing one more post-installation requirement (Hey, how about suggesting a “zypper up” as well for LDAP/SUSE but not necessarily TW?)