Hello Ladislav, On Sep 27 13:59 Ladislav Slezak wrote (excerpt):
Dne 27.9.2013 11:49, Johannes Meixner napsal(a):
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
I didn't mean automated installation of further needed software. I meant that it must be posible to run e.g. the installer's configuration step as some kind of stand-alone application independent of the rest of the whole installer (i.e. in particular independent of the installer's install step). It would be perfectly o.k. when the installer's configuration step that runs this way exits with a meaningful error message when whatever software is not installed that is needed to create a particular part of the configuration. But I wonder why the installer's configuration step needs e.g. whatever software for booting to be installed only to create the booting part of the configuration? Assume Grub1 is installed on the system where the installer's configuration step runs and one likes to create the booting part of the configuration for Grub2. I think it could mess up the the system where the installer's configuration step runs when then Grub2 must be installed into that system that is actually booted with Grub1. For me a crucial part of the whole separation idea is that the system where the installation configuration is created (as a file) and the system where the actual installation happens (by using that file) can be two different systems. Or do I misunderstand something here?
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...
With "It must work to install the installer on an already installed system and run only the installer's configuration step there" I only meant what I wrote - not more - that only plain running the installer's configuration step this way must work (e.g. it must not crash when it is run this way). With "The installer could be used as rescue/recovery tool" I also only meant what I wrote - not more - that it can be used as such a tool. I did not mean that running it this way must in any case successfully repair a messed up system. Running it this way can be only an attempt for a first recovery step. If that fails, the adminhe may try other recovery steps or he may have to re-install his messed up system from scratch.
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.
I think "run it one process" and "three fully separated programs" do not exclude each other. You can run separated "programs" in one same process as threads when you implement them as separated libraries plus separated /bin/program1 ... /bin/programN stubs to run those libraries also directly. What I meant with "fully separated programs" was not "fully separated at run time" (i.e. run in separated processes). What I meant with "fully separated programs" was "fully separated at development time" (i.e. fully separated program source files).
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!
Please tell me as soon as you have a first working installer plus a first working idea for its configuration file format. I would like to be really independent from the YaST core team so that I do not somehow use YaST internal knowledge or even YaST internal functionality for my own applications.
Clear separation and the config file open a lot of new possibilities...
Yes! Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org