New installation program(s)?
I realize one of the major discussions here is trashing the
existing installation system. What follows is an evaluation of
what would this task mean.
1: What do we want
a: more friendly interface
a.1: optional GUI install, if X|fb runs on the user's hardware
a.2: optional no-questions "auto" installation
a.3: optional networked installation
where "optional" means "the user may choose it"
b: more detection, less questions
b.1: use fsresize on the HD if needed
b.2: use the detection capabilities (ISA, PCI, PnP) of k2.2.x
b.3: if there is an "install server" running, fetch
configuration data from there instead of user
c: internationalization - without requiring a recompilation
c.1: language should be the _VERY FIRST_ question on install
These are, IMVHO, the steps of a multi-mode installation tool.
The first column is the "source" of the step; "---" means it's
something the program _does_ (as opposed to getting some
configuration information), and letters mean it gets config data
from some source. The order of the letters is the order tried.
N: Network (from a Debian Network Installation server that
stores config data; I'm going to call this DNI for the
purposes of this message)
D: Detection (perhaps MandrakeSoft's libdetect)
L: Leave it for later (ie, if all sources listed before "L"
fail, leave this unconfigured and ask again later)
--- boot from CD, floppy, bootp or tftp
NL network (try bootp; a DNI server serves bootp, so if not
we're going to need the network then bootp will work)
DNU video (card, monitor)
DN if install is going to use a "live" fs, where is it;
first try a CD, then DNI. Should try non-DNI NFS? This
would require asking the user for address, and, of course,
doing non-automatic configuration of the network if it
isn't configured yet)
NL if using DNI, "install mode" - see later for what's this -
is going to be "DNI", so we don't make any further
questions to the user (and don't even attempt graphic
mode). Perhaps the DNI protocol should have a provision to
"skip" info, so the server can not have info on one of the
steps and this one will be asked from the users - for
example, in some networks it may not be possible for the
server to know which partition layout should be used in
--- try to start X or framebuffer graphic mode. As soon as
graphic mode is up, display a dialog where user has to
click "Continue"; if this timeouts, close graphic mode,
assuming user isn't seeing the dialog (happens on SiS
boards if you try VGA mode).
--- if graphic mode didn't work, fall back on curses-ish
interface for the next step. In this case, mouse support is
a very important plus.
NU location (sets up language dialect, timezone and perhaps
some other things we think of later)
NU keyboard layout (is there some way to detect this?)
NU install mode. Options are "auto" or "custom"; "auto" means
choosing from one installation profile; then all things
from now on marked "U" are asked to the profile instead of
the user, with the exception of the partition layout. If
"auto" is chosen, then we ask _now_ for root's password, so
that the user may go get a coffe or something.
NDU partition layout. If we're using a profile, the thing gets
uglier; see after the list for my POV.
NDU lilo (to mbr or not to mbr, are there other systems, which
one is the default)
--- repartition, mkswap, swapon, mkfs, install "base" system
(which now includes kernel and X or fb), save some config
info including install mode and which client (GUI, text or
DNI non-interactive) is being used, lilo - but make linux
the default regardless of what the user chose)
--- BOOT into the install. This may require serious hacks if we
want a real "auto" mode, because we want to get into the
newly installed system, not the install (CD|floppy|...)
NDU drivers. Even in "U" mode, we should ask as little as
possible unless user said something like "expert" somewhere
NDU base system config (hmm, if we already have language,
timezone and network, what's missing? WM, if we have X?)
NU packages; first use "meta"-packages, then one of gnome-apt,
apt-find (when usable) or dselect. Or perhaps come up with
a "tree-like" structure - user either selects "GNOME" or
clicks somewhere to select packages within this meta-pkg
NU users (including root's password if "custom" mode, first
user - and set exim to send root's mail to this first
user? Or have this as a default but ask for confirmation?)
--- if user didn't select X packages and we're using X, get out
of it and proceed in text mode
--- install packages, remove installation programs, remove
packages that were part of the base system but user didn't
NU let dpkg configure packages - of course we need a way to
make this non-interactive, but this discussion is old :-)
Well, as of partition layout in "auto" mode (or "DNI" mode if
the server tells the client to ask):
IMVHO the very nice "fsresize" package is what we want if we
don't find free space. But then, even if the user already told
us to don't ask anything anymore, we will want to ask how much
space to cut off from the existing OS.
Hmm... I overdid it again :-) Well, different from other things
I designed in the past, this is not cheap talk or vapourware -
I'm being _paid_ to do that, so this will get done. Of course
I'm a Debian developer so I'd prefer to do it the way the
consensus prefer. But my job here is to make a "Debian for
dummies" sub-distro (the actual term we use internally is
"Debian for orangotangoes" and we're seriously thinking of using
a very-cute chimp as our logo), so I need this to be _easier_
than installing (RH|OpenLinux|Windows), even if all this ease
and beauty is optional (as an old-time Debian user I like the
idea of being able to get out of the "pretty" stuff and give the
options manually if I need to).
I am Lalo of deB-org. You will be freed.
Resistance is futile.
pgp key in the web page
Debian GNU/Linux -- http://www.debian.org