On Fri, 27 Sep 2013 10:04:04 -0400 Robert Schweikert <[email protected]> wrote:
> On 09/27/2013 09:41 AM, Josef Reidinger wrote: > > On Fri, 27 Sep 2013 09:37:50 -0400 > > Robert Schweikert <[email protected]> wrote: > > > >> Hi, > >> > >> On 09/26/2013 02:07 PM, Ladislav Slezak wrote: > >>> > >>> Hi all, > >>> > >>> The SUSE YaST team started developing some major YaST features for > >>> SUSE Linux Enterprise 12 (SLE12) installer and we would like to > >>> include these features in > >>> the next openSUSE-13.2 release. > >>> > >>> The features are mainly about making the installer easier and to > >>> simplify the > >>> installation workflow. > >>> > >>> We will not create a completely new installer from scratch (that > >>> would need too much > >>> time and manpower), we will reuse the existing functionality as > >>> much as possible, > >>> the current installation framework is quite flexible (e.g. the > >>> installation steps are > >>> defined in external control.xml file). > >>> > >>> > >>> Here is the summary of the main goals: > >>> > >>> - 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. > >>> > >>> - It should be possible to NOT install the Yast installer itself > >>> into the target > >>> system to make it smaller (except when firstboot or some > >>> complex AutoYast > >>> setup is used, then the installer will be needed). > >>> > >>> - Separate the installer into 3 basic steps (collect data, > >>> install, apply config), > >>> make the steps replaceable by 3rd party applications. > >>> > >>> - It should be possible to use the installer just for configuring > >>> the installation > >>> and exporting the setup into a file (without performing the > >>> actual installation). > >>> The exported file could be then used to install other > >>> system(s). (Like AutoYast > >>> does, the new installer will contain some AutoYast > >>> functionality). > >>> > >>> - It should be possible to alternatively deploy already existing > >>> appliance image > >>> (provided by user) instead of installing from RPMs. > >>> > >>> - Simplify the installation workflow, auto-configure what's > >>> possible, advanced > >>> setup (NIS, LDAP, Kerberos...) should be done in installed > >>> system. > >> > >> Hmm auto configuration is nice, but we should keep in mind that we > >> probably should not take away the opportunity to manually configure > >> things, such as the network for example. Today there is an > >> autoconfiguration for DHCP, but the user can set it to manual > >> configuration and set up the network as needed. > >> > >> Later, > >> Robert > >> > >> > > > > Well, when we discussing it, we agreed that for network if DHCP is > > find, then use it and if it is not find, then allow user to > > configure it. Usual work-flow is that DHCP is set and it is just > > used, so do not bother user with network configuration if we can > > use what dhcp gives us. > > But just because there is a DHCP server that does not necessarily > imply that for a particular install the user wants to use it. Yes, > one can argue that this is a corner case, but having a checkbox as it > is today that allows the user to set "configure the network manually" > is hardly "bothering the user", IMHO. > > Later, > Robert > > Well, we plan to involve designer into this part, so we can add it in some non-intrusive way ( I hope ). Josef -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
