On 10/25/23 09:06, Dominique Leuenberger wrote:
On Tue, 2023-10-24 at 14:57 +0200, Ancor Gonzalez Sosa wrote:
On 10/24/23 14:14, Dominique Leuenberger wrote:
On Tue, 2023-10-24 at 13:23 +0200, Ancor Gonzalez Sosa wrote:
Well, if we get a new flag for "installer-related" patterns I actually don't care about the visible flag and its status. ;-)
Thge most tricky part about that is 'multi-product repositories' (e.g openSUSE:Factory) - currently we produce multiple product media (MicroOS, Tumbleweed) with their own respective roles - but software selection wise, they all have access to the 'one big repo'.
If Agama goes the route of * Selecting the product, which decides RO/RW * Selecting patterns to pick the install 'role'
Then MicroOS will offer exactly the same as Tumbleweed (the same underlying repositories, thus also the same patterns)
Yes and no.
If I correctly understood what the status quo is. That could easily be translated to something similar to this two product configurations:
Agama configuration for MicroOS ===============================
software: repository: - http://the.same.repos/oss - http://the.same.repos/update mandatory_patterns: - microos_base patterns_configurable_by_user: false storage: transactional: true transactional_configurable_by_user: false
How would you translate https://openqa.opensuse.org/tests/3671973#step/system_role/3
into this?
Well, those roles indeed go beyond the simple selection of software to install. To add context to the conversation, I'm adding at the end of the mail a (hopefully readable) summary of what each one of those roles mean in terms of modifying the YaST installation.
Assuming that those 'roles' are to be expressed as different patterns, we'd need to expose them. exposing them means the installer sees all the installer relevant patterns from the repo.
That's exactly why I said "the goal is to simplify the current selection of software to install" and "mimicking the current YaST system roles is not necessarily a goal" and "I see no benefit in reusing the system role name for the flag". So no, I don't think all current roles can be expressed in terms of different patterns. I'm also not sure if Agama will ever have something comparable to the roles since the approach is different from YaST regarding several things like: - installation wizard vs almost-one-click installer (when possible) - more integrated autoinstallation (roles don't exist in AutoYaST) - configure only what cannot be done after installation[*] [*] Remember we didn't even plan software selection to be part of Agama initially. So let's get back to your original question: How will Agama handle the selection of software in 'multi-product repositories'? I personally don't have a plan for that. Of course the new flag could go beyond saying if a pattern should be offered during installation or not and could specify for which product(s) it should be offered. But that sounds to me like too much unwanted coupling from the packages to the installer. Or we can swap the approach and, instead of using a flag in the patterns to decide whether they should be displayed in the installer, we could just add a configuration option to the Agama products to explicitly filter the patterns that will be displayed in the Software section (not so different from the already existing settings "mandatory_patterns" and "optional_patterns"). That would still require quite some work at packaging level. Right now would be almost impossible to come up with sensible lists. Opinions and ideas are welcome. And now, the summary of what each MicroOS role means in terms of YaST. Enjoy! micro_os_role ============= additional_dialog: inst_microos_role container_host_role =================== additional_dialog: inst_microos_role default_patterns: microos_base microos_base_zypper microos_defaults microos_hardware container_runtime micro_os_gnome_desktop_role =========================== additional_dialog: inst_microos_role globals: enable_kdump: false polkit_default_privs: easy readonly_language: false default_patterns: microos_base microos_base_zypper microos_defaults microos_hardware microos_gnome_desktop container_runtime partitioning: expert_partitioner_warning: true windows_delete_mode: all linux_delete_mode: all other_delete_mode: all volumes: [...] micro_os_kde_desktop_role ========================= additional_dialog: inst_microos_role inst_user_first globals: enable_kdump: false polkit_default_privs: easy readonly_language: false default_patterns: microos_base microos_base_zypper microos_defaults microos_hardware microos_kde_desktop container_runtime partitioning: expert_partitioner_warning: true windows_delete_mode: all linux_delete_mode: all other_delete_mode: all volumes: [...] micro_os_role_ra_agent ====================== additional_dialog: inst_microos_role default_patterns: microos_base microos_base_zypper microos_defaults microos_hardware microos_ra_agent micro_os_role_ra_verifier ========================= additional_dialog: inst_microos_role default_patterns: microos_base microos_base_zypper microos_defaults microos_hardware microos_ra_verifier -- Ancor González Sosa YaST Team at SUSE Software Solutions