Re: redesigning the debian installer
On Tue, 12 Sep 2000, Joey Hess wrote:
> The Installer UI
> ----------------
>
> Debconf (or rather, a smaller C implementation of the same specification)
> is the main UI framework for the installer. Using debconf, it should be
> possible to plug in new UI's with a minimum of difficulty.
>
Is there already any work about the smaller C implementation?
When I tried to look for some features in debconf some month ago and
realized I do not even understand such complex perl-code, I planed to
write such a thing myself but just lack the time to get it written myself
but would like to contribute, if someone or somegroup starts with it.
> The user's view
> ---------------
>
> Note that since debconf allows questions to be prioritized, it is possible
> that the install process will skip over any or all of the questions.
>
> The install begins with a bootloader. It is unlikely that this will change
> significantly from what is used now.
It would be very much convenient, if there would be a possibility to
install if from an client over the network without the need of an
boot-disk.
I think it would be on of the most bottom parts of the todo-list, and it
propably will not affect on the way the installation is done, but it would
be nice to have it on the todo-list and have a short look on it to ensure,
that it realy would work with the whole system.
> After the kernel boots up, the first thing the user will see is whatever UI
> is being used, configuring itself. This is equivalent to the current
> installer asking if the screen supports color, and keyboard configuration.
> It might also include language selection, mouse setup, etc. All up the
> individual UI.
How is determined which ui to use?
Could it be (additionaly to other ways) be choosen with an Env-Var on the
boot-up prompt.
Or would there be only one ui in the system, and the person making
the install-floppy/zip/cdrom choses which one to install?
> Once the UI is configured, the user will see a list of every step in the
> install process, with a proposed next step, and an alternate next step, at
> the top. This is very similar to how the installer works now. We have
> observed that this layout gives the user a great deal of flexibility, which
> is very useful if something goes wrong and they have to run steps out of
> order for some reason, or repeat a step.
I like this way ver much, too, and personally would not like to use
anything else. But I have seen people beeing disturbed and/or confused by
that many freedom. It should either be well tested, that you come to an
running system finally, when you wildly choose randomly. Or some question
before, if you want an more direct way. (With std-answer no and an
priority low enough.
> Once the last item is picked, the system will boot up into a full debian
> install, and the user will be prompted for additional information, much
> as base-config does now.
I think the user will get an debconf-frontend there, too, to ask the
questions. I think it would be nice, if the kind of ui in the
base-install could be committed to the full-install some kind.
(If you use some ui, that only askes some server all the questions, while
you are on some other continent, this would be very nice).
> Each item in the list is provided by an installer module. To create the
> list item, a module must only drop a control file with a unique name into
> /usr/lib/debian-installer/menu/. The control file is rfc-822 format, and
> should have the following fields:
> Priority: a number, which determines where the item appears on the menu
> Prog: the program to run if this item is selected
> TestProg: a program to run to determine if this menu item should be the
> default item
> Description: the text to appear on the menu
Perhaps when saying "no" when asked about the menu, there could be a
question about some script or so to start. (So that you can archive the
things in the menu also by without local interferance).
It would be a very easy to use tool for remote installing, when the menu
would be also debconf (or C-replacement ;-) and not programs would be
started and these values used to run some programs. But I think this would
not be possible as something like partionating the disk with such question
would most probably result in something windows-like system, where it
works or you have no chance at all.
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-boot-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: