On 10/20/23 16:15, Dominique Leuenberger wrote:
On Fri, 2023-10-20 at 12:17 +0200, Ancor Gonzalez Sosa wrote:
[...]
As we are basically trying to mimmick 'system roles' (even though that concept went further, as it also allowed config changes, like e.g. Network managing stack and such to happen),
Indeed. System roles at YaST can go way beyond the selection of packages. They allow to modify the workflow of the installer introducing or removing steps. And they also allow to alter many aspects of the installer configuration (like partitioning setup, network system, security settings, etc.). They are so powerful they are used (and misused) for all kind of different things that are not really mutually exclusive or even related to each other, from enforcing certain security standards to making the system transactional or selecting the desktop to install. The goal for Agama is to simplify the current selection of software to install. To be honest, we didn't initially plan to offer a software selection at all at Agama. But if we are going to have one, it needs to be simple (not hundred of options) and without un-obvious consequences (like changes in partitioning). Mimicking the current YaST system roles is not necessarily a goal. It will be fine if we end up with a completely different list of options, when compared to the current selection of roles at YaST. First of all, take into account patterns don't have to be mutually exclusive, as roles at YaST are.
we could do something like:
Provides: sytem-role() (of course agama will likely want libzypp to parse that, and not do it on its own)
Whatever name fits. But I actually see no benefit in reusing the "system role" name.
The 'easy' ones would be the desktop patterns - they could all provide this symbol and Agama could use this to create the UI (Like for the current patterns list, we will want ordering to happen - probably the pattern-order is good enough for that)
Trickier are the other system roles we offer, like 'transactional server': this is not only the patterns that are relevant, but actually the FS layout (btrfs/ro) that matter here. Not sure if/how you plan on implementing this purely based on patterns.
I personally don't plan to. Being transactional or not is in my opinion a feature that could be enabled/disabled (eg. in the Storage section of Agama), not a role on its own right. Same applies to other roles like real-time, common-criteria or high-availability. Those are modeled as system roles only because that was the most convenient mechanism to modify the behavior of the installer without creating a fully separated product. Not because they really represent a different "role" for the system being installed.
But if I correctly understand the content of [1], the "visible" flag is currently used for the following patterns:
- Base System - Enhanced Base System - Minimal Appliance Base - 32-Bit Runtime Environment - AppArmor - SELinux - Tests for the Update Stack - A very basic desktop (previously part of x11 pattern) - Console Tools - Help and Support Documentation - FIPS 140-2 specific packages - Software Management - X Window System
Which looks like a pretty arbitrary selection to me. So I can only guess the content of the "visible" flag diluted over time.
That is certinaly an issue - visibility has never been enforced or even widely discussed. For most parts: once you create it, you want to show it. Or you'd not have created it. So, imho, the 'invisible' patterns are the odd ones in the game.
Well, if we get a new flag for "installer-related" patterns I actually don't care about the visible flag and its status. ;-) Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions