On Friday 2023-10-20 10:26, Martin de Boer wrote:

This can easily be solved by having 2 flows: 1) A easy flow that selects all the defaults, where you only make choices about your language, keyboard layout, locale, timezone (mostly these 4 are related)

That's quite advanced. Not even contemporary yast asks for locale. In an *actually* easy flow, you just derive all four from the location (i.e. the timezone dialog with its pretty map).

And maybe a minimal install versus complete installation choice.

The last time I ever tried the "complete" was in SUSE 7.x or something, and it installed 6 CDs worth of packages of which I did not use 80% in the end. (So, no, nobody wants that.)

On Fri, Oct 20, 2023 at 08:26:17AM -0000, Martin de Boer wrote:

Dear Ancor Gonzalez Sosa,

Please don't go the route of the Anaconda installer. I have tried this several times (with an overview screen, then click on an icon to configure a certain part). This is not a pleasant experience.

The most straightforward is the regular flow with X number of screens. However in that case you will either: - hide the more advanced screens to not annoy beginning users, making it harder for more advanced users - show advanced screens, possibly confusing beginning users

This can easily be solved by having 2 flows: 1) A easy flow that selects all the defaults, where you only make choices about your language, keyboard layout, locale, timezone (mostly these 4 are related) and your favorite desktop environment. And maybe a minimal install versus complete installation choice. In this flow you will want to make partitioning as straightforward as possible. So dual boot vs. whipe everything is enough. 2) A advanced flow, that moves you through all possible configuration options like partitioning, selecting patterns (gaming, office, graphics, coding), preferences like rpm-based or mostly flatpak-based software, networking setup, et cetera. You can also start the advanced flow with an 'index' page where you select the configuration pages that you want to adjust. By not selecting a certain page, your installation will be configured conform the default settings.

The very concept of 'flow' is the problem. Ever tried to change network settings in the installer? Because it's at the start of the 'flow' you have to go back through all those screens that don't need changing. There is no one or two 'flows'. The 'flow' depends on your specific situation. Some things can be autodetected on your system so they don't need to figure in your 'flow' and some are special and they do. That varies from one installation to other. Thanks Michal

On 10/20/23 11:13, Simon Lees wrote:

So really what i'm leaning towards is in an ideal world we should have a new flag and we probably should just pick one pattern for each of the major desktops and another for "Server / GUI Less" setups. Sitting alongside that add a "Custom / Advanced" checkbox that adds everything that currently has the visible flag so that users who want can still do a detailed setup.

That sounds to me like a path worth exploring. How would that flag be implemented in the patterns? I know there is already a "visible" flag and I assume this will use a similar mechanism. 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. Cheers. [1] https://build.opensuse.org/package/show/openSUSE:Factory/patterns-base -- Ancor González Sosa YaST Team at SUSE Software Solutions

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

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 Agama configuration for Tumbleweed ================================== software: repository: - http://the.same.repos/oss - http://the.same.repos/update mandatory_patterns: - enhanced_base optional_patterns: # This would make Gnome the default desktop. Don't panic, # just as example. - installation_gnome patterns_configurable_by_user: true storage: transactional: false transactional_configurable_by_user: true The syntax in those examples is highly modified for easier understanding, but they actually reflect quite closely the kind of things that are configured by product at https://github.com/openSUSE/agama/blob/master/service/etc/agama.yaml Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions

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

On 11/2/23 00:07, Björn Bidar wrote:

Ancor Gonzalez Sosa <ancor@suse.de> writes:

...

[...]

The syntax in those examples is highly modified for easier understanding, but they actually reflect quite closely the kind of things that are configured by product at https://github.com/openSUSE/agama/blob/master/service/etc/agama.yaml

That sounds very good, it would also make it much easier for OEM's or organizations to modify the installer this way.

I found it difficult to configure such options such as repository in the current yast based installer.

I'm curious to know why. The Agama philosophy in that regard is quite similar to the YaST one (as a matter of fact, it's based on the very same concepts). Of course, Agama offers fewer options and uses Yaml instead of XML. But I'm curious to know what other factors you think make YaST hard to configure, just to avoid repeating errors in Agama. Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions

On 10/21/23 19:45, Christian Lanig via openSUSE Factory wrote:

Hi,

first and foremost, the preview in the provided ISO looks great, almost the way I would have dreamed it. :) - It looks really simple, getting the user straight into the new system.

My personal preference would be keeping roles visually in the installer though, being able to aggregate several patterns under a role, because this appears to provide the most functional and customizable experience based on the actual workload that will be run on the system. This way, a single selection done by a user can still include multiple patterns and a user could be allowed to deselect patterns based on their preferences. I always considered the role selection as a benefit compared with the competition and it is very function oriented.

If we are talking only about the selection of software, the same could be achieved just using patterns. A pattern can depend on other patterns. We just need to select a reduced list of high level patterns we want to display during system installation. As already proposed in other branches of this same thread, that could be achieved by implementing a new flag for patterns to indicate they are "installation roles" (and, of course, then keep that list consistent and small enough over time).

Except from the role "Generic Desktop", I consider the existing roles beneficial to address a broad audience. Instead of "Generic Desktop" though, which advanced users could still achieve with manual customization, I would prefer a role "Multimedia/Gaming" to specifically target additional audience, which might e.g. require a realtime kernel for media production or an improved experience in time critical 3D applications. This would allow targeting an audience which might currently be absorbed by distributions like Nobara Linux. > Reviews of Tumbleweed on youtube.com, such as https://www.youtube.com/watch?v=RSaUj_Okbnw&t=289s criticize that the current setup was not among the most user friendly ones. One reason is an overwhelming amount of options. As a result, it appears to be helpful having a reduced set of options, as provided by the roles and maybe even facilitating the selection of e.g. patterns, by providing symbolic images showing the corresponding applications/packages that are not installed if a pattern becomes deselected or the other way around, in case it gets selected. Judging from your preview on Agama, this is on a great track but might need to be improved from my perspective.

Well, the preview showed in the animation is intentionally rough around the edges. We wanted to first showcase the current structural problem (too many patterns and to inconsistent) before we jump into polishing small details in the UI. The final UI will likely be quite different.

Another way to facilitate the installation even more would be providing an installer that just installs a default system (specific role) by wiping the disk, providing a setup later after the first boot to configure the users etc. to simplify the pre-deployment of the operating system and providing an easy installation process for users with low experience. A candidate as a desktop environment chosen for such installation would be Gnome from my personal perspective, because it might suit well to generate a positive first impression due to it's simplicity and overall design by default.

That's actually a way we want to go with Agama as opposed to YaST. YaST is great but it takes cares of MANY things that could easily be customized or improved after the installation. And there are very good tools nowadays to customize an existing system. In a world where such tools exists and where deployment from images is becoming more common than traditional installation, it's debatable if the installer should go that far in tweaking all aspects of the system instead of just focusing on deploying a basic working system that can be customized afterward (that includes installing any package beyond a basic initial selection). So let me quote my own original mail: "[...] Agama to be simpler than with YaST. Even without any selection of packages to install. But quite some people expressed their desire of being able to customize the software selection while installing the operating system itself."

I would personally prefer the "System Role" instead of "Software". I am less interested in how big the installation will be than what will be installed, so if e.g. the Installer would preselect "Gnome" and write: "Gnome will be installed", I would be more happy. (Just because I am not lacking space on my disk... ;) )

Again, what you mention can equally be achieved with installation-related patterns. We don't need a different concept like system roles. Agama would just pre-select the "installation-gnome" pattern and you could enter the Software section to un-tick it, maybe in favor of ticking an "installation-plasma" pattern instead. Talking about defaults, that reopens the desktop war, but I don't care much. ;-) Maybe we should have a default like "no desktop" or "both Plasma and Gnome". YaST have had a strong requirement in the past of not encourage Plasma or Gnome over the other. :-) But I consider that as a minor detail.

Maybe I would not like to have games installed, so I would prefer to untick a games pattern in case I like to click on "System Role", or select another role, if I would want something else.

That could be done if the Software section would have an extra option to display all patterns and not only the ones with the new flag.

I would prefer to just boot Agama, wait a bit and then click on "Install", without even creating a user - and this would be the only thing that would be required to change in order to have a predeployment option without personalization.

That's actually the ideal goal. But we didn't find a reasonable option to skip the configuration of users. The administrator needs to set at least one password or SSH key. We don't want to create an installer that installs all systems with a publicly know password. :-)

Best regards, Christian Lanig

Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions

On 10/25/23 02:07, Ludwig Nussel wrote:

Ancor Gonzalez Sosa wrote:

...

[...]

That's a first implementation that shows we have WAY too many patterns that are WAY too arbitrarily organized.

If we want to use patterns as the main concept to allow software customization... What can we do? Organize the patterns better? Introduce some kind of flag to distinguish the patterns that make sense to offer during installation? Fix something in the way we categorize the patterns?

We feel this is not an UI problem, but an structural one.

Absolutely. Another visualization¹: https://paste.opensuse.org/pastes/00782284b9b9

IOW it's a mess. IMO 90% of patterns should just be dropped without replacement right away. Only keep the ones that define core operating system building blocks. Without apps and without using recommends. The visible attribute should be set only on leaf edges. So we end up with rather quick and small default installations rather than the Linux app showcase we have right now.

I'm going to disagree, at one point with Enlightenment I tried the approach of just shipping the desktop environment in the pattern with no other apps. The feedback I got very quickly was that our users want an install that works with everything they need out of the box even if it means having some apps they don't use. So I added a basic set of applications back to the pattern. I 've also spoken with other desktop maintainers who have seen similar, With a much smaller group of openSUSE users just wanting a minimal system. Those users have always been happy once pointed to the "Custom" role to choose what they actually want themselves. For this to work there needs to be some level of granularity in especially the Gnome and KDE patterns where you can't just zypper in gnome. I was giving a packaging workshop the other day and being able to start by saying just install the OBS Tools pattern was a big help similarly I always install autotools with patterns because otherwise I miss packages and get annoyed. At the end of the day patterns and having everything work out of the box are one of the key things that make openSUSE easy and welcoming to new users, which is why I started using openSUSE some 12 years back. Can we make it better probably, but can we also make it much worse then what we have now for most users? very easily.

The random collections of apps could be replaced by a tag system if someone bothers to implement it. Based on that the welcome wizard could then offer the user to optionally install e.g. a browser, office suite etc.

Pretty much all the patterns I find useful at the moment are a "Curated" set of apps rather then a "Random" set of apps and I don't think you could implement that curation with a tag system. At the same time i'm guessing there are probably some patterns that could be better curated and maybe even a few that no one finds useful so why don't we fix those rather then throwing everything out and starting again with an inferior system. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Hi Ancor, On Tue, 2023-11-21 at 15:42 +0100, Ancor Gonzalez Sosa wrote:

After studying the unveiled problems and challenges (like multi- product repositories) and taking a closer look to how system roles are being used nowadays at openSUSE (see [1]), we decided how to move forward in Agama.

Bear in mind this is an iterative development process, so nothing stops us from re-evaluating this decision in the future.

Thanks for reassuring on this. I think it's understood by most people, but somtimes being explicit about such things is a good thing.

Remember in Agama we already have the concept of "product". The only SUSE enterprise product we currently support is ALP Dolomite (SLE is out of the Agama scope). For openSUSE, the concept of product is currently used to distinguish between three possibilities: Tumbleweed, openSUSE MicroOS and a future ALP-based Leap.

With all that, we have decided to try this:

1) Agama is NOT introducing any concept analogous to the YaST's system roles.

Sounds fair - let's see how far we get with this (most complexity we had over time, like 'role implying network managing stack' or such, are gone.

2) The software selection will display a curated list of patterns per product, but the designation will not be based in any new flag in the patterns side. Instead, the list will be kept in the definition of the product itself (ie. in the Agama configuration file for each product). We still may need to improve some patterns or introduce new ones.

Seeing how often/seldom we introduced new 'roles', I think we can prefectly get away with this. Is the pattern description displayed the one from the pattern itself or is this 'just' a matching table?

3) The lists at the previous point (one list per product) will be kept short. As a consequence, the Agama pattern selection screen will be simplified.

Simplified is good - See GNOME :)

4) We are not forced to limit ourselves to the current list of products. We may break some of them into different products if we feel it's useful to present a particular use-case that implies a different mindset and should imply different installer options. For example, we could have five products instead of three with something like Tumbleweed, Transactional Tumbleweed, MicroOS, MicroOS Desktop and Leap-Next. I'm just making the list up. The exact partition (if any is needed) will be decided as we move.

Looking at the current roles in the standard TW installer, we already have some 'overlap' between MicroOS and Tumbleweed, namely Server-RO: that's pretty much the same I'd say (possibly with slighly larger package pre-selection applied)

On the following weeks we will come-up with a prototype and we can move from there. We may ask for help to create the lists of patterns or to improve/create patterns.

Absolutley looking forward to that! Cheers, Dominique