Hi Johannes, Dne 27.9.2013 11:49, Johannes Meixner napsal(a): [...]
- Remove the second installation stage (started after reboot), configure the system completely just in one stage, after finishing the installer the freshly installed system must be ready to use.
I think the "configure the system completely" is wrong here. ( I assume you would not like to have e.g. printer, scanner, and all kind of system services configuration in the installer ;-)
Yeah, bad wording, with "completely" and meant rather "do not touch it later", instead of "configure everything possible".
I assume what is meant is:
- Remove the second installation stage (started after reboot), do the basic system configuration in one stage, after finishing the installer the freshly installed system must be ready for basic usage.
Yes, that's it.
When those steps should be replaceable by 3rd party applications with reasonable effort for those who make the 3rd party applications those steps must work fully independent from each other.
For example the installer's configuration step must not somehow have unexpected/hidden/private dependencies to the previous installer's install step (except the obvious "dependency" that the install step had acually installed the software).
Yes, the idea is to have a "communication" file, very likely similar to what AutoYaST uses (XML profile).
I.e. the installer's configuration step must be implemented so that it can run on any system regardless how that system was installed.
The configuration should know in advance what it needs and should ask the installer to install it in the config step. This is already done in current Yast, e.g. bootloader can ask the software selection to install Grub (or whatever else is chosen for booting) which is configured later after installation
It must work to install the installer on an already installed system and run only the installer's configuration step there. This would overwrite the existing system's basic configuration by a new system's basic configuration that is the same as if the system would have been installed from scratch.
Um, well, there might be additional config files not touched by installer but still important for configuration. Example: Yast can configure repositories, install packages, patches... etc, but libzypp uses zypp.conf config file which is completely ignored by Yast, so whatever user does wrong there Yast is unable to fix it.
If it works this way, you get a powerful feature for free: The installer could be used as rescue/recovery tool when a [...]
Um, maybe as a side effect it could be used this way, but it would not be 100% reliable (as I mentioned before). We already had a repair tool in Yast but it was basically unmaintainable. So I'm skeptic about such "magic repair" functionality for free... [...]
Probably it helps to implement the installer's 3 basic steps as three fully separated programs [...]
Yes, it was our idea, but the current decision is to run it one process if possible (to avoid unnecessary save/load steps, hardware reprobing...) and run a separate program only when asked to.
To help you a bit, I volunteer for implementing proof of concept 3rd party applications for the install and configure steps.
Yeah, great! That would be nice to have an independent implementation which we could check against!
That file's format must be stable (both syntax and values must be stable - i.e. only fully backward compatible changes are allowed) so that those 3rd party applications can be implemented with reasonable (maintenance) effort.
Yes, I agree, the backward compatibility with AutoYast and stability is a must.
Perhaps you should make it more clear that "configure the installation" here and "configure the system" above are fully separated things. [...] If that file contains a complete configuration of the installation, the installation of the other system can run unattended in a full automated way or it can run in an interactive mode where each value can be modified by a user for the actual installation.
Yes, exactly.
If that file does not contain a complete configuration of the installation, the installation of the other system can run either unattended in a full automated way by using fallback values or it can run in an interactive mode where missing values are requested from a user.
We basically grouped the values to these groups: - mandatory (if missing the installer will interactively ask, otherwise use the predefined value) - optional (use the value, if missing use a default, don't ask) And there will be a special "do not touch" value (i.e. keep the current value, was/will be set by a 3rd party program) The "do not touch" is useful if you change the install step by your application (like your proposed wget/tar) then you want to keep some values untouched because they might be already configured in the tar file and they would get overwritten. [...]
One could migrate an existing openSUSE 13.2 system onto a different hardware platform or onto a virtual machine or one could migrate an existing openSUSE 13.2 system into an openSUSE 13.3 system on different hardware and so on.
Yes, there are more possibilities related to the config file. One idea was to add support to SUSE Studio to export such config file as every Studio appliance actually contains the system configuration. Then you could have an appliance (for direct deployment) and a config file which could be used as installation template which would allow custom changes to the installation (compared to the appliance). Or you could use the appliance in the install step instead of installing from RPMs (using your own install step implementation). Clear separation and the config file open a lot of new possibilities... Ladislav -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org