Bug 1168490

IIUC, you are asking for new feature of the installer to:

1. Keep asking if updates should be already used during installation (No)
2. Store that information and disable update repositories
3. Make it configurable for the future (Start using updates now())

The use case at the end says that even selecting "Do not use updates" might
be too much. The whole use case basically says that GA version is often more 
stable than when updates are used.

This IMO shows that there are several solutions outside the Installer

- The best approach is to use staging in SUSE Manager or SMT/RMT, these
  products are here to maintain nodes from outside, it keeps that stable
  AND up-to-date

- Other solution could be a feature in SCC as these Updates channels are
  NOT exclusively maintained by YaST, but also, e.g., by zypper/libzypp

- Higher quality of released updates - if you say that patched products
  are NOT stable, then we have a problem there too

Can you PLS confirm the use case and / or add more info?

(In reply to Lukas Ocilka from comment #1)
> IIUC, you are asking for new feature of the installer to:

correct (and perhaps beyond)

> 1. Keep asking if updates should be already used during installation (No)

Honor the first choice of Y/N (after registering), but yes giving the option for each repo/channel/module/extension that is added during the installation.

> 2. Store that information and disable update repositories

Yes (still hoping to have them placed into the /etc/zypp/repos.d config space, but disable as per the flow/options)

> 3. Make it configurable for the future (Start using updates now())

Yes, anytime repos are modified, offer that choice (until the flag file-ish token goes away). Of course more of a challenge in post-install space, since this feature may also impact zypper/SUSEConnect/etc.

> The use case at the end says that even selecting "Do not use updates" might
> be too much. The whole use case basically says that GA version is often more 
> stable than when updates are used.

Apologies if this is what you inferred WRT stability. It is more about consistency of a known starting point to reproduce. Otherwise the foundation is potentially different each week (if updates are applied).

> This IMO shows that there are several solutions outside the Installer
> 
> - The best approach is to use staging in SUSE Manager or SMT/RMT, these
>   products are here to maintain nodes from outside, it keeps that stable
>   AND up-to-date

Indeed, those tools do offer a staged approach, which is quite viable to have a known "golden" starting point, but that does require a fair amount of coordination to match releases of more agile products update channels vs. just a time-based patch-cycle approach.

> - Other solution could be a feature in SCC as these Updates channels are
>   NOT exclusively maintained by YaST, but also, e.g., by zypper/libzypp

Good point and as above perhaps SUSEConnect as well. Not sure, but both SMT/RMT might need to not automatically mirror update repos with a product enablement (just like mirroring the SRPMs is a config opt-in).

> - Higher quality of released updates - if you say that patched products
>   are NOT stable, then we have a problem there too

Again, stability is not the issue at all with the updates. I am totally in favor of always applying updates. Yet it is more about the underlying version/APIs over the lifecycle. Think of it like kernel developers 


> Can you PLS confirm the use case and / or add more info?

Let me give a recent scenario:

Trying to deploy kubeflow on top of CaaS Platform, the former citing support for only the K8s version provided in the GA of the latter. In order to accomplish this, I had to:
- point to an RMT server with all of the necessary channels
- disable updates for SLE base (and not add any of the modules/extensions) during the install (so as not to inherent those updates)
- do not install those relevant add-ons during the install, since the updates would be enabled by default
- post install addition of the needed modules/extensions, then manually disable each of the update repos (and the core OS ones as well), before installing the needed patterns otherwise the new versions of container runtime/kubeadm/helm/k8s would have been installed

@Lukas: Requested info provided. Please evaluate whether it deserve to go into Jira.

This is indeed a complex request and often beyond YaST responsibilities.
It would need implementation in several layers (libzypp, zypper, YaST...)
Bryan, please, request it in JIRA.