Mailinglist Archive: yast-devel (91 mails)

< Previous Next >
Re: [yast-devel] YaST installer - the future development (for 13.2/SLE12, aka "the new installer")

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...

"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).

"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...


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@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >