Fwd: Re: d-i vs openSUSE's ancient installer
Hi,
an interesting read/idea from the debian-boot mailinglist. It started with
somebody describing OpenSuSEs installer
(http://lists.debian.org/87hb4vnzpa.fsf@sylvester.afaics.de) and this is the
reply:
Maybe this is something for Debian-Edu Wheezy?
---------- Forwarded Message ----------
Betreff: Re: d-i vs openSUSE's ancient installer
Datum: Samstag, 3. September 2011
Von: Christian PERRIER <bubulle@debian.org>
An: debian-boot@lists.debian.org
Quoting Harald Dunkel (harri@afaics.de):
> That was really exciting. No click-next-to-continue orgy just to accept
> the defaults. Within 2 minutes the basic configuration was done, even
> though the installer was new to me.
The main reason I thik this is something completely impossible to
apply to D-I is that options in D-I are dynamic and most of them
depend on the context. Just look, for instance, how the main menu
looks along an install (you have to do a medium priority install for
this). Options are added while the installation is being performed as
their need depends on choices made by users in previous steps.
This is what makes it IMHO impossible to apply the concept of a single
choices screen to be applied to D-I.
That screen would first have to be entirely dynamic : any change in
any choice would affect the content of other choices...or even add
more choices to the screen.
Not saying this is not doable....but IMHO not doable by still
preserving the versatility of D-I (graphical interface, dialog-based
interface, full text-mode installs, etc).
We even have a bug report for user-setup where it is suggested to have
only one screen for userlogin, real name and password....and where we
have valid objections against that...because each choice has an
influence on others. So imagine if we tried to only have one screen.
So, OpenSUSE installer is perfect for installing an i386/amd64
desktop, single-user machine? Fine. As others said, would that fit
with current choice of scalability we did for D-I. As others answered,
no.
Still, that doesn't indeed prevent anybody to develop a specific
component that could be run *before* D-I, then preseed D-I variables
so that it later runs completely unattended.
-------------------------------------------------------
Reply to: